Re: [PATCH] OMAP4: McBSP: Clear rx_irq at probe time

[Jarkko Nikula <jhnikula@gmail.com>]

On Wed, 18 May 2011 08:52:07 +0300
Peter Ujfalusi <peter.ujfalusi@ti.com> 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