| Message ID | 1424283959-16289-6-git-send-email-afaerber@suse.de |
|---|---|
| State | New |
| Headers | show |
On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: > static const struct of_device_id snow_of_match[] = { > + { .compatible = "google,snow-audio-max98089", }, > { .compatible = "google,snow-audio-max98090", }, > { .compatible = "google,snow-audio-max98091", }, > { .compatible = "google,snow-audio-max98095", }, Since we completely ignore the CODEC in the property might it not be better to just add a plain old snow-audio compatible and bind to that, that way we don't need these driver updates? Just the "snow" bit should be enough to know it's one of this class of machines.
Am 19.02.2015 um 10:44 schrieb Mark Brown: > On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: > >> static const struct of_device_id snow_of_match[] = { >> + { .compatible = "google,snow-audio-max98089", }, >> { .compatible = "google,snow-audio-max98090", }, >> { .compatible = "google,snow-audio-max98091", }, >> { .compatible = "google,snow-audio-max98095", }, > > Since we completely ignore the CODEC in the property might it not be > better to just add a plain old snow-audio compatible and bind to that, > that way we don't need these driver updates? Just the "snow" bit should > be enough to know it's one of this class of machines. Personally I don't mind either way, but I'd rather leave that decision to Google/Samsung people. With all those Tegra and Rockchip based Chromebooks popping up, are there any further Exynos based Chromebooks planned using this driver, or is it the last of its kind? Cheers, Andreas
Mark, On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@kernel.org> wrote: > On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: > >> static const struct of_device_id snow_of_match[] = { >> + { .compatible = "google,snow-audio-max98089", }, >> { .compatible = "google,snow-audio-max98090", }, >> { .compatible = "google,snow-audio-max98091", }, >> { .compatible = "google,snow-audio-max98095", }, > > Since we completely ignore the CODEC in the property might it not be > better to just add a plain old snow-audio compatible and bind to that, > that way we don't need these driver updates? Just the "snow" bit should > be enough to know it's one of this class of machines. I think what you're suggesting is that here we should add a new compatible string "google,snow-audio" instead of adding "google,snow-audio-max98089" here. Then the sound node in the spring DTS would look like: compatible = "google,snow-audio-max98089", "google,snow-audio"; That would allow us to later figure out that we're on a board with max98089 in case it became important but means that any other minor tweaks like this wouldn't need anything special. I haven't tried that to make sure that the fallback compatible string actually works in this case, but it seems like the right way to go... Sound good? -Doug
Am 19.02.2015 um 18:44 schrieb Doug Anderson: > On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@kernel.org> wrote: >> On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: >> >>> static const struct of_device_id snow_of_match[] = { >>> + { .compatible = "google,snow-audio-max98089", }, >>> { .compatible = "google,snow-audio-max98090", }, >>> { .compatible = "google,snow-audio-max98091", }, >>> { .compatible = "google,snow-audio-max98095", }, >> >> Since we completely ignore the CODEC in the property might it not be >> better to just add a plain old snow-audio compatible and bind to that, >> that way we don't need these driver updates? Just the "snow" bit should >> be enough to know it's one of this class of machines. > > I think what you're suggesting is that here we should add a new > compatible string "google,snow-audio" instead of adding > "google,snow-audio-max98089" here. Then the sound node in the spring > DTS would look like: > > compatible = "google,snow-audio-max98089", "google,snow-audio"; If we want to be specific just in case, was it an active decision not to use "google,peach-pi[t]-audio-max98..."? Again, either way works for me. Andreas
Andreas, On Thu, Feb 19, 2015 at 9:56 AM, Andreas Färber <afaerber@suse.de> wrote: > Am 19.02.2015 um 18:44 schrieb Doug Anderson: >> On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@kernel.org> wrote: >>> On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote: >>> >>>> static const struct of_device_id snow_of_match[] = { >>>> + { .compatible = "google,snow-audio-max98089", }, >>>> { .compatible = "google,snow-audio-max98090", }, >>>> { .compatible = "google,snow-audio-max98091", }, >>>> { .compatible = "google,snow-audio-max98095", }, >>> >>> Since we completely ignore the CODEC in the property might it not be >>> better to just add a plain old snow-audio compatible and bind to that, >>> that way we don't need these driver updates? Just the "snow" bit should >>> be enough to know it's one of this class of machines. >> >> I think what you're suggesting is that here we should add a new >> compatible string "google,snow-audio" instead of adding >> "google,snow-audio-max98089" here. Then the sound node in the spring >> DTS would look like: >> >> compatible = "google,snow-audio-max98089", "google,snow-audio"; > > If we want to be specific just in case, was it an active decision not to > use "google,peach-pi[t]-audio-max98..."? > > Again, either way works for me. I don't think it was an active decision, but I am certainly nowhere near an audio expert and I don't think I made that particular decision (I could be wrong). One could make the argument that "snow" describes the general hookup style of the hardware and then you list the actual codec after that, but that's a pretty weak argument... -Doug
On Thu, Feb 19, 2015 at 09:44:08AM -0800, Doug Anderson wrote: > On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@kernel.org> wrote: > I think what you're suggesting is that here we should add a new > compatible string "google,snow-audio" instead of adding > "google,snow-audio-max98089" here. Then the sound node in the spring > DTS would look like: > compatible = "google,snow-audio-max98089", "google,snow-audio"; Yes.
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 3cebf6ca03df..222181655e4f 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -214,6 +214,7 @@ config SND_SOC_LITTLEMILL config SND_SOC_SNOW tristate "Audio support for Google Snow boards" depends on SND_SOC_SAMSUNG && I2C + select SND_SOC_MAX98088 select SND_SOC_MAX98090 select SND_SOC_MAX98095 select SND_SAMSUNG_I2S diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c index 7651dc924161..89d7e39b206e 100644 --- a/sound/soc/samsung/snow.c +++ b/sound/soc/samsung/snow.c @@ -105,6 +105,7 @@ static int snow_probe(struct platform_device *pdev) } static const struct of_device_id snow_of_match[] = { + { .compatible = "google,snow-audio-max98089", }, { .compatible = "google,snow-audio-max98090", }, { .compatible = "google,snow-audio-max98091", }, { .compatible = "google,snow-audio-max98095", },
This is needed for Spring. Signed-off-by: Andreas Färber <afaerber@suse.de> --- sound/soc/samsung/Kconfig | 1 + sound/soc/samsung/snow.c | 1 + 2 files changed, 2 insertions(+)