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.