On Wed, 18 May 2011 08:52:07 +0300 Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: > On Tuesday 17 May 2011 15:57:00 Tony Lindgren wrote: > > This file should be under drivers/ somewhere, can you > > guys please take care of that? > > Yeah, this has been discussed several times, and we have not reached agreement > where to move this very OMAP specific code. > One option was to move it under sound/soc/omap/ , since currently the only > user for mcbsp is audio. > But McBSP is really versatile beast, it can be used for other things (for > example it can handle SPI bus as well), so if we move it under ASoC, we are > going to limit/block other use of these pins. > We can not just cp arc/arm/plat-omap/mcbsp.c drivers/wherever... > If we do that, we need to move it under some framework, or create a new one > (bus driver?), which might be a bit tricky since we have special use of McBSP > from audio side, this does not really fit the bus mode. Other uses of McBSP > might be happy with the bus driver conversion, but we just do not have those. > > IMHO the only place we can move this is under sound/soc/omap/ , but who can > decide, that the McBSP can only be used for audio?? > I think we would need some higher level abstraction for this McBSP use model where the lowest level driver (here OMAP McBSP) is just used to configure the serial interface and a layer on top of that takes care of DMA transfer and protocol like SPI, I2S, etc. Why higher level abstraction? It's not only OMAP that has a general purpose serial interface. Also TI DaVinci has similar called McBSP/ASP and how about other SoCs, probably? What I looked once the DaVinci McBSP/ASP it wasn't compatible with OMAP McBSP but made me thinking that if these differences can be handled by a generic API. -- Jarkko -- 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
