From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "André Draszik" <andre.draszik@linaro.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Jiri Slaby <jirislaby@kernel.org>,
Peter Griffin <peter.griffin@linaro.org>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Will McVicker <willmcvicker@google.com>,
Sam Protsenko <semen.protsenko@linaro.org>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH] tty: serial: samsung: add clock comment for earlycon on gs101
Date: Wed, 10 Jul 2024 15:40:07 +0200 [thread overview]
Message-ID: <2024071030-gravy-backwater-88ec@gregkh> (raw)
In-Reply-To: <20240710-samsung_tty-gs101earlycon-v1-1-bd0f8481542a@linaro.org>
On Wed, Jul 10, 2024 at 02:33:29PM +0100, André Draszik wrote:
> As pointed out in [1] before, the hand-over between earlycon and serial
> console is fragile due to clocking issues:
>
> ... causing earlycon to stop to work sometime into the boot for two
> reasons:
> * peric0_top1_ipclk_0 requires its parent gout_cmu_peric0_ip to be
> running, but because earlycon doesn't deal with clocks that
> parent will be disabled when none of the other drivers that
> actually deal with clocks correctly require it to be running and
> the real serial driver (which does deal with clocks) hasn't taken
> over yet
>
> 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
> nothing 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 wait 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
> once the first consumer driver of an IP attached to cmu_peric0 has
> completed probing.
>
> ...
>
> If earlycon is not enabled in kernel command line, everything works
> fine, the kernel buffers its messages and once the real serial console
> driver starts, all messages since boot are being printed.
>
> As requested, add a comment to the code for posterity, so the
> information is not lost. The patch referenced in the comment can be
> found at [2].
That should also be in the comment in the .c file, right? Along with
the git id that you feel should be reverted?
thanks,
greg k-h
next prev parent reply other threads:[~2024-07-10 13:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 13:33 [PATCH] tty: serial: samsung: add clock comment for earlycon on gs101 André Draszik
2024-07-10 13:40 ` Greg Kroah-Hartman [this message]
2024-07-10 13:45 ` André Draszik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024071030-gravy-backwater-88ec@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=jirislaby@kernel.org \
--cc=kernel-team@android.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=semen.protsenko@linaro.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox