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. > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
