On Thu, 12 Oct 2023 17:41:34 +0300 Péter Ujfalusi peter.ujfalusi@gmail.com wrote:
On 07/10/2023 10:11, Andreas Kemnade wrote:
OK good to hear it works, I'll send out fixes for omap4 and 5, seems the runtime PM warning is something different.
omap-mcbsp 40124000.mcbsp: Runtime PM usage count underflow! # cat /sys/bus/platform/devices/40124000.mcbsp/power/runtime_status active
even with no sound.
Well, it is a regression caused by your fix. Without it (and not reverting the already applied ignore patch), runtime is properly suspended. Don't know why yet.
I guess it is because of the pm_runtime_put_sync() in the omap2_mcbsp_set_clks_src() around the fclk re-parenting. That is a bit dubious thing for sure. We need to disable the device to be able to re-parent the fclk but if we disable the device it is going to be powered down, right? I think we have appropriate context handling, so it might work, but it is certainly not a rock solid code... If you have a stream running already, you don't really want to kill the McBSP.
Ok, so if the device is powered of at omap2_mcbsp_set_clks_src() we get the usage count underflow, and the counter is incremented immediately again in the runtime put function. So things get out of balance... I'll check Tony's fix here.
The problem is that this mux is outside of the McBSP IP, so we need a system level (iow, clk API) way to change it runtime.
What is the machine driver where this happens? If you set the sysclk in hw_params of the machine driver, it will be OK, but if you do that in probe time then it is likely going to fail as you experienced
As you see in the other patches of this series, it is a simple-audio-card with a tlv320aic3x codec in combination with the mcbsp.
Regards, Andreas