From: "Mark Brown" broonie@kernel.org Sent: Friday, 31 May, 2024 15:05:28
On Fri, May 31, 2024 at 08:46:55AM -0400, Elinor Montmasson wrote:
From: "Mark Brown" broonie@kernel.org
On Fri, May 17, 2024 at 05:05:35AM -0400, Elinor Montmasson wrote:
From: "Mark Brown" broonie@kernel.org
On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
struct clk *cpu_sysclk = clk_get(&pdev->dev, "cpu_sysclk");if (!IS_ERR(cpu_sysclk)) {priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(cpu_sysclk);priv->cpu_priv.sysclk_freq[RX] = priv->cpu_priv.sysclk_freq[TX];clk_put(cpu_sysclk);}I don't really understand the goal here - this is just reading whatever frequency happens to be set in the hardware when the driver starts up which if nothing else seems rather fragile?
The driver allow to set the sysclk frequency of the CPU DAI through `priv->cpu_priv.sysclk_freq` when calling `fsl_asoc_card_hw_params()`. Currently it is hard-coded per use-case in the driver.
My reasoning was that with a generic codec/compatible, there might be use-cases needing to use this parameter, so I exposed it here via DT.
Is it a bad idea to expose this parameter ? This is not a requirement for the driver to work, most of the current compatibles do not use this parameter. It is currently used only for `fsl,imx-audio-cs42888`. In that case I can remove this commit.
I'm having a hard time connecting your reply here with my comment. This isn't as far as I can see allowing the frequency to be explicitly configured, it's just using whatever value happens to be programmed in the clock when the driver starts.
In v3 I used parameters `cpu-sysclk-freq-rx/tx` to explicitly set the frequency. In its review Rob Herring said that the clock bindings should be used, so that's why I changed it to use this `cpu_sysclk` clock.
So you're trying to use this as the audio clock? There's no code that enables the clock which seems worrying, and I'd expect that if the device is using it's own clock the device would be querying it directly via the clock API rather than this. This all seems really confused.
It's not specifically the audio clock, I am merely using this in the machine driver to let the user the possibility to configure the CPU DAI sysclock frequency. The CPU DAI and codec drivers already manage their own clocks.
I agree it is confused, I am trying to expose a driver option for this generic compatible without really knowing a use case where it would be needed. With the S/PDIF it isn't needed, so I should probably remove this commit.