On Friday 08 July 2011 16:28:05 Mark Brown wrote:
It's not that simple in this situation. We also have a PM dependency on the CODEC here too, it supplies our interface clock via the DAI so we have to be very careful how we interact with the ABE and CODEC. The critical thing here is the pop reduction and a subsequent ABE patch will also introduce some hard timing constraints here too.
This definitely feels like it needs sorting in a better way than just inserting random delays into drivers
I agree, there should be a better way to handle this.
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. BTW: what infrastructure you are suggesting?
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 we just insert random delays into the drivers the chances of anyone understanding what the code is supposed to be doing in the future seem low which isn't going to be nice when people do different designs.
Again: agreed. Unfortunately this cleanup work has to wait, since at least I'm going for a holiday.
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.