On Monday 29 August 2011 11:16:04 Mark Brown wrote:
That's not what you said before... I did post the sequence I was suggesting and you seemed fine with it. Please try to be clear about what you're trying to do here - previously you'd just said that you needed to make sure the CODEC was powered down prior to the CPU being stopped but now you're adding additional stuff here.
Hrm, yes i did agreed with your sequence until I started to look at the other implications. However at least I was consistent in the commit messages about the sequence requirements (OMAP4 McPDM should be stopped after the codec's DAC/ADC).
Could you please clarify what exactly the system looks like here and what you need to do? I'm struggling to understand how you've got PDM output links providing clocks back into the CPU - usually a PDM output is two wires going in one direction.
McPDM uses 5 wires. clks is coming from the codec, and this signal is used within OMAP4 McPDM as functional clock (we have frame sync, ul data, dl data, and clock loopback wires). Chapter 23.6.2.2 of OMAP4430_ES2.x_PUBLIC_TRM_vW.pdf
The sequence I'm looking for is: 1. pcm_trigger: stop DMA 2. DAPM sequence starts 3. DAC is turned off on the codec side 4. OMAP4 McPDM can be stopped - stop it 5. DAPM finishes up 6. codec can be turned off
I also don't entirely understand why your current approach will be robust, though it should be an improvement on the original change to just put a delay in the shutdown. You can't rely on pmdown_time happening at all as it's user configurable and only happens for some cases even when it's there.
I'm not relaying on the pmdown_time but I'm relying on DAPM to handle the power down of the cpu_dai. The pmdown_time does not matter anymore. I do not remember saying that it is robust, but I might meant that this approach needs small amount of code, and it is handled by a well tested/proven piece of code (DAPM).
Like I say I'm not convinced I understand what you need to do yet. It would be easier if we could merge the updated McPDM driver and worry about this separately; I don't understand why you can't just inline the event into the regular teardown (it will be noisy but it should at least run).
OK, let's take this part out for now.
I'll send a single patch for replacing the legacy driver with the new one, but without the pop avoiding delay magic.
-- Péter