[alsa-devel] [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver

[Mark Brown]

On Fri, Jul 08, 2011 at 06:02:26PM +0300, Péter Ujfalusi wrote:
> On Friday 08 July 2011 16:28:05 Mark Brown wrote:

> > the clocking dependencies are far
> > from unique, for example, and would normally be managed by the machine
> > drivers with the current infrastructure.

> Sort of yes, but as soon as we have more devices, we will need either ways in 
> the core, or some common file to handle the clocking, startup, and other 
> dependencies between McPDM and the twl6040 - I'm completely ignoring the ABE 
> here.

Well, clearly the machine driver is the common place to handle the
interdependencies between the two devices.  After all either device
(particularly the OMAP) could potentially be used with different system
designs.  If there are many boards with identical setups then they
probably ought to be using the same machine driver anyway.

> BTW: what infrastructure you are suggesting?

I've got a few ideas but nothing comprehensive right now; the main thing
I can think we're missing at the minute is more fine grained hooks
around stream start in order to allow things to clock off the audio
stream.  Equally well none of the systems I've had to deal with have had
a particularly pressing problem here.

> > Right now it's all sounding
> > far too fragile due to the lack of any explicit indication of what's
> > going on and the fact that things are going to be spread over a bunch of
> > different drivers.

> Agreed, but... if we handle the McPDM stop start from the outside, will it 
> help? I mean we need to keep on eye what the twl6040 is doing, and do things 
> accordingly within the McPDM.

If the machine driver controls the system integration (as we're doing
for everything else) it's at least clear what's going on for this
particular system.  My main concern here is making the code actually say
what's going on.

> Another, not directly related thing is that with this driver in place at least 
> one can play audio on OMAP4 with upstream kernel (through McPDM, and without 
> ABE).

> This area is still work in progress, but I prefer to start from something, 
> which shows some sign of life.

Could we split the rewrite out from the delay thing so we can review it
separately?  This'd also be good from the point of view of documentation
of what's going on as the changelogs would provide a bit more details.