On Wednesday 25 February 2009 22:25:59 ext George G. Davis wrote:

Hi,

On Tue, Nov 25, 2008 at 02:52:58PM +0000, Mark Brown wrote:

...

On Tue, Nov 25, 2008 at 01:21:20PM +0200, Jarkko Nikula wrote:

...

Or if those EVM's & SDP's can route TWL4030 audio connections more flexible than Beagle but somewhat similar manner, then probably have one single machine driver for all EVM's?

Otherwise it doesn't make very much sense to have n similar machine drivers where only functions and variable names differ.

Yes, it looks like a lot of these drivers could be redone along the lines of s3c24xx_uda134x.c with platform data specifying the differences between the boards.

Is someone working on updating ASoC drivers for OMAP TWL4030 based boards as recommended above? Just curious since I already made the mistake of creating my own OMAP3 EVM ASoC driver w/o checking the list first. : /

Well, I have checked the s3c24xx_uda134x.c and the corresponding uda134x.c codec driver. In case of the uda134x codec - since it does not have DAPM implementation, the board file does not need to deal with the output/input pins. In case of boards using the TWL4030 codec it is not that simple IMHO. You see TWL4030 has nine output 'pins' and six (plus 2x stereo digital mic) input 'pins'. So, yes it is doable, but will it make things cleaner and more manageable? Few things came to my mind, which needs to be addressed: 1. Who is the master (OMAP McBSP or TWL4030)? 2. What is the reference clock in the given board 3. Connected pins (or not connected pins) 4. I2S or TDM mode (this is not implemented yet, but it is coming at some point)

It easy to provide 1, 2 and 4. But when it comes to 3... One needs to build up the DAPM routes in the common board file for the supported boards, which again doable based on - for example - some model/board ID, but I think it will look ugly.

Or I might over complicate things ;)

-- Regards, George