All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.