public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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


  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