linux-kernel - Possible regression from "arm64: dts: imx8mp: don't initialize audio clocks from CCM node"

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>] [day] [month] [year] [list]

Date:   Sun, 6 Aug 2023 18:03:51 -0500
From:   Adam Ford <aford173@...il.com>
To:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Richard Cochran <richardcochran@...il.com>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Possible regression from "arm64: dts: imx8mp: don't initialize audio
 clocks from CCM node"

Lucas,

I can't find the original e-mail or I would have replied to that, so
my apologies.

This patch removed the clock configurations for AUDIO_PLL1 and PLL2,
but it went beyond just that by also removing the clock parenting for
IMX8MP_CLK_AUDIO_AHB, and IMX8MP_CLK_AUDIO_AXI_SRC which are tied into
the SDMA2/3 systems.

With this parenting removed, the SDMA2 and SDMA3 clocks are slowed to 24MHz.
Per the TRM, "The SDMA2/3 target frequency is 400MHz IPG and 400MHz
AHB, always 1:1 mode, to make sure there is enough throughput for all
the audio use cases."

With the parenting and clock rates restored for  IMX8MP_CLK_AUDIO_AHB,
and IMX8MP_CLK_AUDIO_AXI_SRC, it appears the SDMA2 and SDMA3 run at
400MHz.

This also matches the NXP downstream kernel.

Any objections if I partially revert your patch so
IMX8MP_CLK_AUDIO_AHB and IMX8MP_CLK_AUDIO_AXI_SRC return to their
previous condition? If you don't like it on the clk node, we could
move the clock-parenting and rate setting to the audio_blk_ctrl node
since the sdma2 and sdma3 both reference these clocks.  It just needs
to be set somewhere before the clocks are turned on or we cannot
reparent them.  I won't plan to revert the Audio_PLL1 or AUDIO_PLL2
clock stuff as that is board specific, but I would like to fix
16c984524862 ("arm64: dts: imx8mp: don't initialize audio clocks from
CCM node")

Let me know your thoughts.

thanks,

adam