RE: [PATCH 2/6] ASoC: samsung: i2s: configure PSR from sound card

Padmanabhan Rajanbabu
2023-01-03T06:38:11Z

> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: 09 November 2022 11:09 PM
> To: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com>
> Cc: lgirdwood@gmail.com; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; s.nawrocki@samsung.com;
> perex@perex.cz; tiwai@suse.com; pankaj.dubey@samsung.com;
> alim.akhtar@samsung.com; rcsekar@samsung.com;
> aswani.reddy@samsung.com; alsa-devel@alsa-project.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org
> Subject: Re: [PATCH 2/6] ASoC: samsung: i2s: configure PSR from sound card
>
> On Tue, Nov 08, 2022 at 10:53:40AM +0530, Padmanabhan Rajanbabu wrote:
>
> > > > We can overcome this scenario to an extent if we can get a
> > > > flexibility to Configure both PSR as well as RFS.
>
> > > Why does it make sense for the machine driver to worry about this
> > > rather than having the I2S controller driver configure the clock tree?
>
> > _____ | __
> > |
> > | | | | \
> > |
> > |CMU| | | \
> > |
> > |FSD |- |---|-|--------->| \ _________ _________
> > |
> > |___ | | | |op_clk0| | | | |
> > | |
> > | | | |MUX|----| PSR |----| RFS
> > |--cdclk |
> > | | | | | |_______| |_______|
> > |
> > | | |--------->| /
> > |
> > | | op_clk1 | /
> > |
> > | | |_ /
> > |
> > | |___________________________________________|
> > |
> > |-----> To other FSD SoC Peripherals
>
> > In FSD I2S, the clock source is not an independent source but a common
> > clock source being shared by many IPs in the same domain.
>
> > Changing the clock tree will impact other IPs in the domain as they
> > are dependent on the same source for functionality.
>
> I'm not sure I follow. Perhaps your diagram is unclear but it looks like
PSR and
> RFS are both after a mux which appears to select which clock is going to
be
> used by the I2S controller? The usage by other clocks appears to be
> upstream of the mux and dividers.
>
> > We can understand your point to bring the PSR changes under the I2S
> > CPU DAI driver by adding a separate compatible and data for the FSD
> > SoC. But If we take the example of existing sound cards such as
> > sound/soc/samsung/tm2_wm5110.c, the op_clk is supplied via external
> > audio pll to the controller and PLL configuration is taken care by the
> > sound card. Since the configuration of PLL is more specific to the tm2
> > platform, it makes use of the flexibility of changing the RFS and BFS
> > using the sysclk and clkdiv hooks provided by exynos7-i2s CPU DAI
> > along with PLL tuning for precise sampling frequency.
>
> The big reason for the clocking control (and indeed having a custom
machine
> driver) with the WM5110 is that it has multiple clocks to control and a
good
> deal of flexibility with placing them in clock domains and so on which
have
> power and performance impacts. It's frankly a bit unclear to me if the
CPU
> I2S controller even needs the bitclock configuring given that the clocks
are
> being driven by the CODEC there, but regardless it's not clear to me why
the
> I2S controller would need anything other than the input clock to the block
> configuring?
>
> > Similar to the above example, the choice of clock source under
> > discussion is not a limitation of exynos7-i2s controller, but instead
> > is a limitation on the FSD SoC.
> > By using the proposed change, we can ensure that the exynos CPU DAI
> > driver is giving additional hooks similar to existing hooks for BFS,
> > RFS and CDCLK direction so that sound cards can use
> > snd_soc_dai_set_sysclk and snd_soc_dai_set_clkdiv to customize the
> > same.
>
> I'm still not seeing anything that articulates why pushing the
configuration of
> the dividers within the block into the machine driver solves a problem
here.
> Again, what's the upside to configuring clocks that are purely within the
> block?

Okay, I can understand the reason for de-linking these changes from the
machine
Driver. I'll post the v2 patches integrating the PSR changes into cpu dai
driver.

Thanks,
Padmanabhan R.