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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
