[alsa-devel] [PATCH v3 2/3] ASoC: soc-dapm: API to attach DAPM_SUPPLY to be used for dai

[Péter Ujfalusi]

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