[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DF25959.9060603@metafoo.de>
Date: Fri, 10 Jun 2011 19:50:17 +0200
From: Lars-Peter Clausen <lars@...afoo.de>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: Liam Girdwood <lrg@...com>, alsa-devel@...a-project.org,
Mike Frysinger <vapier@...too.org>,
linux-kernel@...r.kernel.org,
device-drivers-devel@...ckfin.uclinux.org,
uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: Blackfin: Add bf5xx-adau1701 machine
driver
On 06/10/2011 07:30 PM, Mark Brown wrote:
> On Fri, Jun 10, 2011 at 07:18:50PM +0200, Lars-Peter Clausen wrote:
>> Add a machine driver to support the ADAU1701 SigmaDSP processors on
>> Analog Devices BF5XX evaluation boards.
>
> So, I keep on complaining about the way these drivers are just generic
> to any random Blackfin plus CODEC combination rather than being board
> specific. It'd be good if we could improve this, even adding something
> into the driver name to make it clear these are for the EVB would help.
I think this is due, that the codecs them-self sit on an add-on board to the
bf5xx eval boards.
So you have two boards, the bf5xx eval board with has the codec eval board
connected to it. That's why it it is kept so generic. You could connect the
codec eval board to any of the bf5xx boards.
>
> But it's about the same as all the other drivers so...
>
>> +static struct snd_soc_dai_link bf5xx_adau1701_dai[] = {
>> + {
>> + .name = "adau1701",
>> + .stream_name = "adau1701",
>> + .cpu_dai_name = "bfin-i2s.0",
>> + .codec_dai_name = "adau1701",
>> + .platform_name = "bfin-i2s-pcm-audio",
>> + .codec_name = "adau1701.0-0034",
>> + .ops = &bf5xx_adau1701_ops,
>> + },
>> + {
>> + .name = "adau1701",
>> + .stream_name = "adau1701",
>> + .cpu_dai_name = "bfin-i2s.1",
>> + .codec_dai_name = "adau1701",
>> + .platform_name = "bfin-i2s-pcm-audio",
>> + .codec_name = "adau1701.0-0034",
>> + .ops = &bf5xx_adau1701_ops,
>> + },
>
> For example this mapping could vary between systems, and I guess there
> may be some possiblity that the CODEC I2C address could change.
The I2C address is specific to the add-on board and since there is only one
adau1701 eval board it should be static.
- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists