[EXT] Re: i.MX8MM Clock errors and caam failure on 5.10-rc4
Adam Ford
aford173 at gmail.com
Tue Dec 1 08:22:48 EST 2020
On Mon, Nov 30, 2020 at 8:44 PM Andy Duan <fugang.duan at nxp.com> wrote:
>
> From: Adam Ford <aford173 at gmail.com> Sent: Monday, November 30, 2020 7:29 PM
> > On Mon, Nov 30, 2020 at 2:32 AM Aisheng Dong <aisheng.dong at nxp.com>
> > wrote:
> > >
> > > Hi Fugang & Horia,
> > >
> > > > From: Adam Ford <aford173 at gmail.com>
> > > > Sent: Sunday, November 22, 2020 6:43 AM
> > > >
> > > > I have a board which uses Bluetooth on UART1 similar to the 8mm-evk.
> > > > The serial port for the BT needs to run at 80MHz because I have the
> > > > baud rate of the serial part set to 4M.
> > > >
> > > > I thought I'd give the 5.10-RC's a try. I found some issues that
> > > > concern me, but before I go back to bisect, I thought I'd ask if
> > > > people are aware of it and/or have ideas. The BT is failing to
> > > > operate as is the caam engine, and it seems to be related to some clocking
> > issues.
> > > >
> > > > Failed to get clock for /timer at 306a0000
> > > > Failed to initialize '/timer at 306a0000': -22
> > > > clk: failed to reparent uart1 to sys_pll1_80m: -16
> > > > clk: failed to reparent uart3 to sys_pll1_80m: -16
> > > > caam 30900000.caam: Failed to get clk 'ipg': -2
> > > > caam 30900000.caam: Failed to request all necessary clocks
> > > > caam: probe of 30900000.caam failed with error -2
> > > >
> >
> > I upgraded my version of ATF to the imx_5.4.47_2.2.0 release and the latest
> > upstream U-Boot. With those updates, the timer and caam errors went away,
> > however I am still seeing the following:
> >
> > clk: failed to reparent uart1 to sys_pll1_80m: -16
> > clk: failed to reparent uart3 to sys_pll1_80m: -16
> >
> > Is there something else missing?
>
> Adam, below patch prevent enabled leaf clock to be parented.
> So you should keep uart clock is disabled during clock scan and init in of_clk_init().
How do I do this? I am selecting the clock parent in the device tree,
because I need an 80MHz clock in order to run the UART at 4Mbps. Is
there some mechanism for the device tree to keep it disabled during
the clock scan and of_cl_init? It seems to me like clock parent
selection should happen in the driver before the initialization of the
clock.
> You can refer to the fixes at imx/clk.c:
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0
>
> commit 9461f7b33d11cbbf5ce79c3c03d0da9d42dfce92
> Author: Jerome Brunet <jbrunet at baylibre.com>
> Date: Tue Jun 19 15:40:51 2018 +0200
>
> clk: fix CLK_SET_RATE_GATE with clock rate protection
>
> CLK_SET_RATE_GATE should prevent any operation which may result in a rate
> change or glitch while the clock is prepared/enabled.
>
> IOW, the following sequence is not allowed anymore with CLK_SET_RATE_GATE:
> * clk_get()
> * clk_prepare_enable()
> * clk_get_rate()
> * clk_set_rate()
>
> At the moment this is enforced on the leaf clock of the operation, not
> along the tree. This problematic because, if a PLL has the CLK_RATE_GATE,
> it won't be enforced if the clk_set_rate() is called on its child clocks.
>
> Using clock rate protection, we can now enforce CLK_SET_RATE_GATE along the
> clock tree
>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> Tested-by: Quentin Schulz <quentin.schulz at free-electrons.com>
> Tested-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Signed-off-by: Jerome Brunet <jbrunet at baylibre.com>
> Signed-off-by: Michael Turquette <mturquette at baylibre.com>
> Link: lkml.kernel.org/r/20180619134051.16726-3-jbrunet at baylibre.com
>
> >
> > > > I jumped ahead to linux-next to see if there were any upstream fixes
> > > > implemented but it throws the same errors.
> > > >
> > > > If anyone has any ideas, I'd like to try them. If not, I'll spend
> > > > some time bisecting.
> > >
> > > Are you aware of this issue?
> > > Any suggestions?
> > >
> > > Regards
> > > Aisheng
> > >
> > > >
> > > > adam
More information about the linux-arm-kernel
mailing list