On Thu, Jul 07, 2011 at 08:55:16PM +0100, Liam Girdwood wrote:
On 07/07/11 17:53, Mark Brown wrote:
My comment was more that the changelog should say why it's not suitable given that it involves a near total rewrite of the driver which is a pretty big step, I'm fine with the actual change. I guess that the current McPDM driver configures some things that should be moved to the DMA driver?
I cant think of anything thing atm that could be moved to DMA driver, McPDM mostly uses ABE for moving PCM data around.
Well, I'm just guessing here since the changelog was so uninformative :)
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 - the clocking dependencies are far from unique, for example, and would normally be managed by the machine drivers with the current infrastructure. 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.
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.