[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1970074.VYjjbDuVRv@diego>
Date: Thu, 15 Feb 2018 22:01:52 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>,
Shawn Guo <shawnguo@...nel.org>,
Dong Aisheng <aisheng.dong@....com>
Subject: Re: [PATCH v2 4/8] clk: migrate the count of orphaned clocks at init
Am Mittwoch, 14. Februar 2018, 14:43:36 CET schrieb Jerome Brunet:
> The orphan clocks reparents should migrate any existing count from the
> orphan clock to its new acestor clocks, otherwise we may have
> inconsistent counts in the tree and end-up with gated critical clocks
>
> Assuming we have two clocks, A and B.
> * Clock A has CLK_IS_CRITICAL flag set.
> * Clock B is an ancestor of A which can gate. Clock B gate is left
> enabled by the bootloader.
>
> Step 1: Clock A is registered. Since it is a critical clock, it is
> enabled. The clock being still an orphan, no parent are enabled.
>
> Step 2: Clock B is registered and reparented to clock A (potentially
> through several other clocks). We are now in situation where the enable
> count of clock A is 1 while the enable count of its ancestors is 0, which
> is not good.
>
> Step 3: in lateinit, clk_disable_unused() is called, the enable_count of
> clock B being 0, clock B is gated and and critical clock A actually gets
> disabled.
>
> This situation was found while adding fdiv_clk gates to the meson8b
> platform. These clocks parent clk81 critical clock, which is the mother
> of all peripheral clocks in this system. Because of the issue described
> here, the system is crashing when clk_disable_unused() is called.
>
> The situation is solved by reverting
> commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
> registration"). To avoid breaking again the situation described in this
> commit
> description, enabling critical clock should be done before walking the
> orphan list. This way, a parent critical clock may not be accidentally
> disabled due to the CLK_OPS_PARENT_ENABLE mechanism.
>
> Fixes: f8f8f1d04494 ("clk: Don't touch hardware when reparenting during
> registration") Cc: Stephen Boyd <sboyd@...eaurora.org>
> Cc: Shawn Guo <shawnguo@...nel.org>
> Cc: Dong Aisheng <aisheng.dong@....com>
> Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
On a rk3288-veyron Chromebook
Tested-by: Heiko Stuebner <heiko@...ech.de>
This made the hdmi on the machine work again with 4.16-rc1 .
(hdmi-cec clock is sourced from the i2c connected pmic which provides
the 32kHz clock needed)
So it would be really cool if this could make it into 4.16-rc :-)
Heiko
Powered by blists - more mailing lists