On Mon, Dec 05, 2011 at 04:53:00PM +0200, Peter Ujfalusi wrote:
On 12/05/2011 03:46 PM, Mark Brown wrote:
Well, the pcm_mutex doesn't cover all of those anyway (trigger and pointer in particular) and we've no guarantee that anything will actually happen at the point where the core does the calls as there may be other things holding the device active.
It covers the soc_pcm_open, and soc_pcm_close sequences.
It's a pretty limited subset (and of course it won't cover the cases where one DAI is in two PCMs).
I don't understand how this could make the situation any worse than it is already - if nothing else this series will only make the region where we've got the device active slightly wider.
The ordering of the pm_runtime_get/put will be different. We will have the pm_runtime_put after all other parts of the audio system has been closed, turned off.
Hrm, yes. But that's much wider than just the issue with moving inside the pcm_lock - for example, the shutdown calls already come before the DAPM teardowns.
There's definitely an issue there, but it seems like it already exists and is orthogonal to this refactoring. The McPDM needs to hold a reference on the CODEC somehow while it is active it seems, either via DAPM or via the runtime_pm APIs.
Yes, this is the reason we do not have the BIAS_OFF support in twl6040 still. I'm working on to integrate the external fclk (bit clock from twl6040) for McPDM with pm_runtime so we are not going to have issues with missing clocks. But as I said at this time we do not have issues since the fclk for McPDM is always present. This change actually gives more incentive to do the pm_runtime support for the McPDM external fclk ;)
So it sounds like things are OK with the proposed patch then, though there's still some larger issues to work through?