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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 3 Jan 2023 10:25:02 +0530
From:   "Padmanabhan Rajanbabu" <p.rajanbabu@...sung.com>
To:     "'Mark Brown'" <broonie@...nel.org>
Cc:     <lgirdwood@...il.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <s.nawrocki@...sung.com>,
        <perex@...ex.cz>, <tiwai@...e.com>, <pankaj.dubey@...sung.com>,
        <alim.akhtar@...sung.com>, <rcsekar@...sung.com>,
        <aswani.reddy@...sung.com>, <alsa-devel@...a-project.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-samsung-soc@...r.kernel.org>
Subject: RE: [PATCH 2/6] ASoC: samsung: i2s: configure PSR from sound card



> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nel.org]
> Sent: 09 November 2022 11:09 PM
> To: Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>
> Cc: lgirdwood@...il.com; robh+dt@...nel.org;
> krzysztof.kozlowski+dt@...aro.org; s.nawrocki@...sung.com;
> perex@...ex.cz; tiwai@...e.com; pankaj.dubey@...sung.com;
> alim.akhtar@...sung.com; rcsekar@...sung.com;
> aswani.reddy@...sung.com; alsa-devel@...a-project.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; linux-samsung-
> soc@...r.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.