[alsa-devel] [PATCH] OMAP general SOC driver.

[David Brownell]

On Wednesday 26 November 2008, Mark Brown wrote:
> > I'm told that the ASoC stuff "should" go in a separate ASoC
> > area for some reason.  That still makes no good sense to me,
> > so if there's a brief explanation as to why it's done that
> > way, please fling me a URL.  :)
> 
> The move is in the direction you want but we're not there yet.  The fact
> that things are now decomposed enough for us to be able to think about
> it is a good sign here.
> 
> The biggest part of it is that the degree of coupling between the
> various ASoC components is high - this is particularly obvious with v1
> where the entire card is probed at once.  This includes coupling between
> the drivers and the core where the degree of churn is very high right
> now due to v2 merging.  It doesn't feel right to give architectures an
> API that they can't rely on from one merge window to the next yet,

OK, that seems to be the key point.  And it makes a lot of sense;
I wouldn't call the driver structure here "simple", so it deserves
some iteration on multiple disparate hardware platforms just to make
sure the interfaces is adequate to the problem.

Let me insert a minor plug from the PM perspective that it would be
good to find a way that the codecs can sit in the proper places in
the driver model tree.  Example with twl4030:  it's an I2C device
and thus should be a child of something like

   /sys/devices/platform/i2c_omap.1/i2c-adapter/i2c-1/1-0049

to guarantee that for example nothing touches that codec after its
parent I2C controller gets suspended.

- Dave


> partly from the point of view of isolating the code for review purposes
> and also due to the merge issues which would doubtless crop up.
> 
> Another part of it is that some machine drivers can get involved enough
> to sit on or cross the boundary from platform data to being drivers for
> substantial distinct hardware but that's very much not the case for
> everything.
> 
> I've been spending time this week working on getting the ability to load
> platform and codec drivers independantly merged.  That will at least
> allow the instantiation of the ASoC drivers for those to be pushed out
> into the architecture code, which is a start and should substantially
> reduce the size of most machine drivers.  At the point where that's been
> done it's probably worth looking again at the simpler machine drivers.
>