Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   Adam Ford <aford173@gmail.com>
Date:   Sun, 6 Aug 2023 18:03:51 -0500
Message-ID: <CAHCN7xKW3vvRUAaf1DvkPpOTeP9JbtDZxnU70+-fWEOao+V4WA@mail.gmail.com>
Subject: Possible regression from "arm64: dts: imx8mp: don't initialize audio
 clocks from CCM node"
To:     Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        Richard Cochran <richardcochran@gmail.com>,
        arm-soc <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Lucas Stach <l.stach@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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