On Wed, 2010-12-29 at 14:04 +0200, Felipe Balbi wrote:

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 ?

That's fine, but this is not the case atm for this particular DMIC IP and we can only justify effort for OMAP atm.

...

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.

Ok, I now think you meant other "ARM architectures" here than other Linux architectures in general. It does make a more sense for ARM distribution deployment, but I still think guaranteeing successful build for this driver on all non ARM architectures atm just to give us satisfaction that the driver is "well written" is unnecessary effort.

...

...

...

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.

In a lot of cases drivers under drivers/* and sound/* must touch plat/* and mach/* headers for runtime access to hardware IP. I've just grepped and the list is quite long for drivers/*

Liam