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.
>