On Wed, 2010-12-29 at 12:44 +0200, Felipe Balbi wrote: > Hi, > > On Wed, Dec 29, 2010 at 10:35:31AM +0000, Liam Girdwood wrote: > >> Even though the driver will never work with those other archs, compile > >> testing with several of them isn't bad at all. > > > >This seems unnecessary since this driver is for the OMAP platform only > >and also means maintainers will have to waste time fixing any build > >issues for this driver on irrelevant architectures. The costs here > >outweigh any benefits.... > > If that's the case, what's the use for linux-next, then ? Drivers should > be arch independent as much as possible, no ? Isn't that why we don't > want drivers using branches to things such as machine_is_omap4_panda() > or similar ? > 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. 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 ? 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. > But the whole audio part on OMAP is still in a bad shape anyway, e.g. > mcbsp exports omap-only functions for drivers to use, so this will only > be yet another driver to the pile :-p > In this case though the other McBSP user afaik is DaVinci, so in this case it does make sense to make this driver support both. > >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. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
