Messages in this thread | | | From | Adam Ford <> | Date | Sun, 6 Aug 2023 18:03:51 -0500 | 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
| |