![](https://secure.gravatar.com/avatar/9242c35a230b47b8917a5ca0a7950406.jpg?s=120&d=mm&r=g)
On 13/10/2023 14:25, Andreas Kemnade wrote:
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.
To be honest I would be happier if we can just remove the whole omap2_mcbsp_set_clks_src() and leave the CLKS source selection outside of the driver. But omap3pandora is selecting external clock as parent (OMAP_MCBSP_SYSCLK_CLKS_EXT - in hw_params, so it actually works) and I don't know what happens if this functionality is removed. Likely going to break Pandora. That is fixable, but what worries me is this comment and code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/soun...
Which is added by me a long time ago: e386615c01d37 ("ASoC: omap-mcbsp: When closing the port select PRCM source for CLKS signal")
I'm not sure if this is possible to do in any other way.