Patch "arm64: dts: imx8mp: Fix SDMA2/3 clocks" has been added to the 6.5-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    arm64: dts: imx8mp: Fix SDMA2/3 clocks

to the 6.5-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     arm64-dts-imx8mp-fix-sdma2-3-clocks.patch
and it can be found in the queue-6.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 5568c7f229e2652a573c7942d503902e7f4051bf
Author: Adam Ford <aford173@xxxxxxxxx>
Date:   Sat Aug 19 05:50:01 2023 -0500

    arm64: dts: imx8mp: Fix SDMA2/3 clocks
    
    [ Upstream commit b739681b3f8b2a7a684a71ddd048b9b6b5400011 ]
    
    Commit 16c984524862 ("arm64: dts: imx8mp: don't initialize audio clocks
    from CCM node") removed the Audio clocks from the main clock node, because
    the intent is to force people to setup the audio PLL clocks per board
    instead of having a common set of rates, since not all boards may use
    the various audio PLL clocks in the same way.
    
    Unfortunately, with this parenting removed, the SDMA2 and SDMA3
    clocks were slowed to 24MHz because the SDMA2/3 clocks are controlled
    via the audio_blk_ctrl which is clocked from IMX8MP_CLK_AUDIO_ROOT,
    and that clock is enabled by pgc_audio.
    
    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."
    
    Instead of cluttering the clock node, place the clock rate and parent
    information into the pgc_audio node.
    
    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 again.
    
    Fixes: 16c984524862 ("arm64: dts: imx8mp: don't initialize audio clocks from CCM node")
    Signed-off-by: Adam Ford <aford173@xxxxxxxxx>
    Reviewed-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
    Reviewed-by: Fabio Estevam <festevam@xxxxxxxxx>
    Signed-off-by: Shawn Guo <shawnguo@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index cc406bb338feb..587265395a9b4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -794,6 +794,12 @@ pgc_audio: power-domain@5 {
 						reg = <IMX8MP_POWER_DOMAIN_AUDIOMIX>;
 						clocks = <&clk IMX8MP_CLK_AUDIO_ROOT>,
 							 <&clk IMX8MP_CLK_AUDIO_AXI>;
+						assigned-clocks = <&clk IMX8MP_CLK_AUDIO_AHB>,
+								  <&clk IMX8MP_CLK_AUDIO_AXI_SRC>;
+						assigned-clock-parents =  <&clk IMX8MP_SYS_PLL1_800M>,
+									  <&clk IMX8MP_SYS_PLL1_800M>;
+						assigned-clock-rates = <400000000>,
+								       <600000000>;
 					};
 
 					pgc_gpu2d: power-domain@6 {



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux