[alsa-devel] [Uclinux-dist-devel] [PATCH 2/2] ASoC: Blackfin AD1836/AD1938 machine drivers: require SPI master

[Mike Frysinger]

On Tue, Oct 6, 2009 at 06:39, Mark Brown wrote:
> On Tue, Oct 06, 2009 at 06:00:23AM -0400, Mike Frysinger wrote:
>> On Tue, Oct 6, 2009 at 05:50, Mark Brown wrote:
>> > These are board-specific drivers to hook things up on a given system
>> > (presumably various eval boards), they're the non-generic part of the
>> > system that says how the generic DAI and CODEC drivers have been hooked
>> > up.
>>
>> except the Blackfin machine drivers are written in such a way that
>> they arent specific to a board.  they'll work on any system with a
>> SPORT and a SPI/I2C bus.
>
> That's not 100% clear - some of the drivers say they're specific to
> particular designs (either in the help text or by having board-specific
> GPIO setup).  It's certainly the intention of the API that the board
> hookups be fixed at run time rather than at compile time, and that
> things like using multiple CPU DAIs should be possible.
>
> The other option here is to make the CODEC drivers build without their
> control buses, which keeps the people doing random configurations happy.

yes, there are many descriptions which are way more specific than they
should be.  the issue stems from people developing with a narrow focus
rather than keeping the big picture in their head.  they test one
specific configuration and then just bang out the name/info with that.
   ive been trying to stem the flow and clean up existing code, but it
doesnt always work out.

AD1836 is an example of this -- the Kconfig text says "BF5xx", but
that's useless because that covers all Blackfin parts.  "STAMP/EZKIT"
is a lie -- there is no dependency on these base board designs.  the
machine driver only needs a SPORT (TDM) for transport and the codec
needs SPI for configuration.  every Blackfin part has at least one
SPORT.  but the core SPORT handling is the crux of the matter -- as i
mentioned in another thread, our implementation is severely limited in
terms of multiple instances and is in need of restructuring.

the GPIO handling is made "generic" by putting it into the Kconfig.
so the machine-specific aspect is now in the .config file instead of
the machine driver.  really this needs to get pushed out into the
board resources (another bad habit that we've been reigning in --
encoding flexible resources in Kconfig).

back to the original issue.  the AD1836/AD1938 have their registers
programed via SPI, but they dont care what SPI bus they're connected
to.  that is specified in the board resources.  because of the way the
Kconfig options are handled (machine drivers select codecs), the
SPI_MASTER dependency cannot be added to the codec Kconfigs in
codecs/Kconfig.  so even though the SPI dependency is only in the
codec and not the machine driver, the machine driver needs to declare
the SPI_MASTER dependency to prevent incorrect config selections and
link failures.
-mike