Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver

Felipe Balbi
2010-12-29T12:04:48Z

Hi,

On Wed, Dec 29, 2010 at 11:52:51AM +0000, Liam Girdwood wrote:
>I agree that drivers should be arch independent when possible, but in
>this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
>i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found
>on OMAP silicon.

Let's imagine this IP is sourced from someone else and not created by
TI, what prevents company XYZ from sourcing the same IP and end up
re-using the driver ?

>I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but
>what happens when the driver builds fine for OMAP but breaks the PXA,
>MIPS, SuperH build ? Who will spend time to fix and test it ?

You forgetting about other ARMs. This won't compile on DaVinci either.

>My main problem here is cost benefit. No one benefits directly by having
>this driver available for the above platforms but it costs me time
>fixing it when it breaks.

Of course there's people benefitting: OMAP audio driver writers would
know their driver is well written and doesn't break build for anybody.

Ok, let me put it this way:

What happens when you want have one kernel image for OMAP and DaVinci ?
Granted, that's not possible today anyway but e.g. Linaro is pushing for
it and IMO should be the way to go for us to be able to have a
distro-like kernel for ARM-based systems too.

>> >It also seems inconsistent with the other OMAP system headers in
>> >plat-omap too.
>>
>> Other than a few drivers which still need converting (and are on their
>> way) I can only see really arch-specific bits and pieces under plat/.
>>
>> Not sure what's your point here.
>>
>
>The point is that David had split the DMIC headers into two files, one
>for plat specific registers and bit definitions and the other for audio
>definitions (for the machine drivers) and is/was consistent with the
>current OMAP platform headers.

You forgot to mention that plat/ headers are supposed to be used by
plat-* and mach-* code only to setup the correct state for the driver.
Just recently one of the musb glue layers got broken because it was
mistakenly using <plat/control.h> and that got moved.

That's actually my point and why I think drivers should not touch plat/*
and mach/* headers.

--
balbi