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