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

[Adam Ford]

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