[alsa-devel] [Device-drivers-devel] [PATCH 2/3] ASoC: Blackfin: Add bf5xx-adau1701 machine driver

Mike Frysinger vapier at gentoo.org
Fri Jun 10 20:13:05 CEST 2011


On Fri, Jun 10, 2011 at 14:01, Mark Brown wrote:
> On Fri, Jun 10, 2011 at 01:47:34PM -0400, Mike Frysinger wrote:
>> On Fri, Jun 10, 2011 at 13:30, Mark Brown wrote:
>> > 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 know you keep complaining, but i honestly dont understand why this
>> is undesirable.  connecting a codec to a Blackfin is pretty much
>> always the same.  you pick a SPORT # and that's about it.
>
> Only if you're looking at very basic boards - as soon as you start
> adding any external components on the boards like speaker amps, start
> handling jacks (with detection or without) or start dealing with more
> flexible CODEC devices with a wider range of connection possibilities
> the number of possibilities expands dramatically.

often times, people do have just basic needs, but i see what you mean.
 i want the base driver to be flexible enough to handle all the base
changes (diff SPORT num and perhaps addresses), but anything beyond
that i'd expect someone to write a custom driver.  perhaps renaming
the Kconfig description to be like "Basic Blackfin connection to XXX
Codec" would be sufficient ?  and then add a few more details to the
help text ?

>> the spi cs and i2c address could differ (so maybe make that a field
>> for the platform resources), but otherwise i dont see why people
>> should have to copy & paste the same code to change all of 4 bytes.
>
> Reusing code where there's similiarities is fine - Tegra is doing that
> for WM8903 based systems in a fairly tasteful fashion - but that's not
> really what this stuff feels like it is doing.  For example, the SPORT
> selection and reset GPIO selection should be platform data not Kconfig
> options and drivers that explicitly say they're for a particular board
> in Kconfig should probably say so in code also.

i absolutely agree with this 100%.  i keep banging on our guys to get
all Kconfig knobs thrown out and moved to proper resources, and some
of it has, but not all of it just yet.
-mike


More information about the Alsa-devel mailing list