Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2021-01-20 15:18:49
Also in:
linux-clk, lkml
Hi Abel, On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote:
On 21-01-18 08:00:43, Adam Ford wrote:quoted
On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa [off-list ref] wrote:quoted
On 21-01-15 12:29:08, Adam Ford wrote: ...quoted
diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c index a66cabfbf94f..66192fe0a898 100644 --- a/drivers/clk/imx/clk-imx25.c +++ b/drivers/clk/imx/clk-imx25.c@@ -73,16 +73,6 @@ enum mx25_clks { static struct clk *clk[clk_max]; -static struct clk ** const uart_clks[] __initconst = { - &clk[uart_ipg_per], - &clk[uart1_ipg], - &clk[uart2_ipg], - &clk[uart3_ipg], - &clk[uart4_ipg], - &clk[uart5_ipg], - NULL -}; -I'm assuming there is another patch that updates the dts files. Right ?I have only been able to test this on an i.MX8M Mini. I need to set the parent clock of the i.MX8M Mini to an 80 MHz clock in order to run the UART at 4Mbps. With this patch, I can stop enabling the all the UART clocks early and allow the clock parent configuration to occur. From what I can tell, the remaining clocks should get activated as they are needed, because I was able to use Bluetooth connected to UART1 running at 4MBps using a 80MHz clock source with this patch, and the clk_summary shows the clock is running at the proper speed. Without this patch, the UART fails to re-parent, so I'm stuck at lower speeds and that means choppy Bluetooth audio. The Kernel that NXP hosts on Code Aurora that they use for Yocto attempts scan through stdout to only enable those clocks [1]. I attempted to push it upstream, but it was rejected [2]. Sascha suggested creating an array which could be filled when the clocks are enabled and that array would be used to deactivate the clocks at shutdown. That's what I attempted to do here. I don't have older imx boards to know if their device trees are configured in such a way without modifications to the device tree or not, but since it appears to work for NXP in [2], I assumed it would work here. [1] - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Fcommit%2Fdrivers%2Fclk%2Fimx%2Fclk.c%3Fh%3Dimx_5.4.47_2.2.0%26id%3D754ae82cc55b7445545fc2f092a70e0f490e9c1b&data=04%7C01%7Cabel.vesa%40nxp.com%7Cf8922e76fa85485b86c508d8bbb97c47%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637465752633257569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bVmPaM1nN7Sm%2BISVvlIBoWYozfJE96fHpw431IEuggk%3D&reserved=0 [2] - https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F20201229145130.2680442-1-aford173%40gmail.com%2F&data=04%7C01%7Cabel.vesa%40nxp.com%7Cf8922e76fa85485b86c508d8bbb97c47%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637465752633257569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=226HwbeVhZUW%2FJ3hsCSaVIxghOsPBH9EWeF8vFxaTWE%3D&reserved=0quoted
TBH, I'm against the idea of having to call consumer API from a clock provider driver. I'm still investigating a way of moving the uart clock control calls in drivers/serial/imx, where they belong.That makes sense.Just a thought. The uart clock used for console remains on from u-boot, so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to all the uart root clocks and remove the prepare/enable calls for uart clocks for good. I don't really have a way to test it right now, but maybe you could give it a try.
That would mean that UART clocks will never be disabled, regardless of whether they are used for console or not. That doesn't sound very appealing. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel