[alsa-devel] [Device-drivers-devel] [PATCH 2/3] ASoC: Blackfin: Add bf5xx-adau1701 machine driver
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.
More information about the Alsa-devel