diff mbox series

[PATCHv4,7/9] ASoC: fsl-asoc-card: add DT clock "cpu_sysclk" with generic codec

Message ID 20240515135411.343333-8-elinor.montmasson@savoirfairelinux.com (mailing list archive)
State New, archived
Headers show
Series [PATCHv4,1/9] ASoC: fsl-asoc-card: add support for dai links with multiple codecs | expand

Commit Message

Elinor Montmasson May 15, 2024, 1:54 p.m. UTC
Add an optional DT clock "cpu_sysclk" to get the CPU DAI system-clock
frequency when using the generic codec.
It is set for both Tx and Rx.
The way the frequency value is used is up to the CPU DAI driver
implementation.

Signed-off-by: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
---
 sound/soc/fsl/fsl-asoc-card.c | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Mark Brown May 16, 2024, 12:13 p.m. UTC | #1
On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:

> Add an optional DT clock "cpu_sysclk" to get the CPU DAI system-clock
> frequency when using the generic codec.
> It is set for both Tx and Rx.
> The way the frequency value is used is up to the CPU DAI driver
> implementation.

> +		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?
Elinor Montmasson May 17, 2024, 9:05 a.m. UTC | #2
From: "Mark Brown" <broonie@kernel.org>
Sent: Thursday, 16 May, 2024 14:13:19
> On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
> 
>> Add an optional DT clock "cpu_sysclk" to get the CPU DAI system-clock
>> frequency when using the generic codec.
>> It is set for both Tx and Rx.
>> The way the frequency value is used is up to the CPU DAI driver
>> implementation.
> 
>> +		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.

Best regards,
Elinor Montmasson
Mark Brown May 17, 2024, 11:17 a.m. UTC | #3
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.
Elinor Montmasson May 31, 2024, 12:46 p.m. UTC | #4
From: "Mark Brown" <broonie@kernel.org>
Sent: Friday, 17 May, 2024 13:17:20
> 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.
Mark Brown May 31, 2024, 1:05 p.m. UTC | #5
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.
Elinor Montmasson May 31, 2024, 2:48 p.m. UTC | #6
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.
Mark Brown May 31, 2024, 4:55 p.m. UTC | #7
On Fri, May 31, 2024 at 10:48:12AM -0400, Elinor Montmasson wrote:
> From: "Mark Brown" <broonie@kernel.org>

> > 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 would expect that if the clocks used by the devices are configured via
the clock API then the drivers for those devices will configure
themselves via the clock API.  I still don't understand what this change
is intended to accomplish.
diff mbox series

Patch

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 9aca8ad15372..c7fc9c16f761 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -754,6 +754,12 @@  static int fsl_asoc_card_probe(struct platform_device *pdev)
 		snd_soc_of_parse_tdm_slot(np, NULL, NULL,
 						&priv->cpu_priv.slot_num,
 						&priv->cpu_priv.slot_width);
+		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);
+		}
 	} else {
 		dev_err(&pdev->dev, "unknown Device Tree compatible\n");
 		ret = -EINVAL;