Received-SPF: pass (google.com: domain of linux-kernel+bounces-42927-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <d45de3b2bb6b48653842cf1f74e58889ed6783ae.camel@linaro.org>
Subject: Re: [PATCH 5/5] clk: samsung: gs101: don't mark non-essential
 clocks as critical
From: =?ISO-8859-1?Q?Andr=E9?= Draszik <andre.draszik@linaro.org>
To: Sam Protsenko <semen.protsenko@linaro.org>
Cc: peter.griffin@linaro.org, robh+dt@kernel.org, 
 krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, 
 linux-kernel@vger.kernel.org, kernel-team@android.com,
 tudor.ambarus@linaro.org,  willmcvicker@google.com,
 alim.akhtar@samsung.com, s.nawrocki@samsung.com,  tomasz.figa@gmail.com,
 cw00.choi@samsung.com, mturquette@baylibre.com,  sboyd@kernel.org,
 linux-arm-kernel@lists.infradead.org,  linux-samsung-soc@vger.kernel.org,
 linux-clk@vger.kernel.org,  devicetree@vger.kernel.org
Date: Mon, 29 Jan 2024 14:37:52 +0000
In-Reply-To: <CAPLW+4mL1gb_R8PhKaMhwOUTa0GDqat_9W=348ScYj+hBarQJg@mail.gmail.com>
References: <20240127003607.501086-1-andre.draszik@linaro.org>
	 <20240127003607.501086-6-andre.draszik@linaro.org>
	 <CAPLW+4mL1gb_R8PhKaMhwOUTa0GDqat_9W=348ScYj+hBarQJg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.1-1 
Precedence: bulk
MIME-Version: 1.0

Hi Sam,

On Fri, 2024-01-26 at 21:30 -0600, Sam Protsenko wrote:
> On Fri, Jan 26, 2024 at 6:37=E2=80=AFPM Andr=C3=A9 Draszik <andre.draszik=
@linaro.org> wrote:
>=20
> >=20
> > Note that this commit has the side-effect of causing earlycon to stop
> > to work sometime into the boot for two reasons:
> > =C2=A0=C2=A0=C2=A0 * peric0_top1_ipclk_0 requires its parent gout_cmu_p=
eric0_ip to be
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 running, but because earlycon doesn't de=
al with clocks that
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parent will be disabled when none of the=
 other drivers that
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 actually deal with clocks correctly requ=
ire it to be running and
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the real serial driver (which does deal =
with clocks) hasn't taken
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over yet
>=20
> That's weird. Doesn't your bootloader setup serial clocks properly?
> AFAIU, earlycon should rely on everything already configured in
> bootloader.

I tried to explain that above, but let me try again...

The console UART, and I2C bus 8 are on the same cmu_peric0 controller, and
that cmu_peric0 has two clocks coming from cmu_top, ip and bus. For I2C8 & =
UART
to work, both of these clocks from cmu_top need to to be on as they are the
parent of the i2c8-(ip|pclk) and uart-(ip|pclk) each.

The bootloader leaves those clocks running, yes. So earlycon works (for a
while).

At some point into the boot, one of two things happens:
1) Linux will load the i2c driver. That driver does clock handling
(correctly), it will initialise and then it has nothing to do, therefore it
disables cmu_peric0's i2c8 ip and pclk clocks. Because at that stage nothin=
g
appears to be using the cmu_peric0's ip clock (the real serial driver hasn'=
t
initialised yet), Linux decides to also disable the parent ip clock coming
from cmu_top.

At this stage, the earlycon driver stops working, as the parent ip clock of
the uart ip clock is not running any more. No serial output can be observed
from this stage onwards. I think what is probably happening is that the
console uart FIFO doesn't get emptied anymore, and earlycon will simply wai=
t
forever for space to become available in the FIFO (but I didn't debug this)=
.

Anyway, the boot doesn't progress, the system appears to hang. In any case =
it's
not usable as we have no other means of using it at this stage (network /
usb / display etc.).

2) Alternatively, the UART driver will load at this stage. Again, it will
tweak the clocks and after probe it will leave its clocks disabled. The
serial console driver hasn't taken over at this stage and earlycon is still
active. Again, the system will hang, because IP and PCLK have been disabled
by the UART driver. Once the serial console is enabled, clocks are being
enabled again, but because earlycon is still waiting for progress, the
boot doesn't progress past disabling ip and pclk. It never gets to enabling
the serial console (re-enabling the clocks).

So in both cases we get some output from earlycon, but the system hangs onc=
e
the first consumer driver of an IP attached to cmu_peric0 has completed
probing.


> > =C2=A0=C2=A0=C2=A0 * hand-over between earlycon and serial driver appea=
rs to be
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fragile and clocks get enabled and disab=
led a few times, which
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 also causes register access to hang whil=
e earlycon is still
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 active
> > Nonetheless we shouldn't keep these clocks running unconditionally just
> > for earlycon. Clocks should be disabled where possible. If earlycon is
> > required in the future, e.g. for debug, this commit can simply be
> > reverted (locally!).
>=20
> That sounds... not ideal. The ability to enable earlycon just by
> adding some string to bootargs can be very useful for developers.
> Maybe just make those clocks CLK_IGNORE_UNUSED, if that keeps earlycon
> functional? With corresponding comments of course.

CLK_IGNORE_UNUSED doesn't help in this case, the i2c and uart drivers will =
load
and probe before earlycon gets disabled and as part of their probing disabl=
e
the cmu_top ip clock going to cmu_peric0

If earlycon is not enabled in kernel command line, everything works fine, t=
he
kernel buffers its messages and once the real serial console driver starts,
all messages since boot are being printed.

Other than keeping it as CLK_IS_CRITICAL, there is no way that I can see to
way to make the hand-over from earlycon to the real serial driver work in
all cases.

They are not critical clocks for the system, though, so it's wrong to alway=
s
keep them running unconditionally.

We are past a stage where earlycon is generally required.

If it's required for some local development, people can revert this patch l=
ocally.


BTW, downstream doesn't suffer from this problem because downstream uses AC=
G
throughout and clocks are enabled automatically in hardware as required.


Cheers,
Andre'