All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Agner <stefan@agner.ch>,
	linux-serial@vger.kernel.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Peter Hurley <peter@hurleysoftware.com>
Subject: Re: console vs earlycon ?
Date: Wed, 21 Oct 2015 12:36:45 +0200	[thread overview]
Message-ID: <5490682.zH2vAEO2id@wuerfel> (raw)
In-Reply-To: <CAK7LNATniscPQ_vLMg91PWbMVSdoXtJYGL9nicsn49=ULQ-oAw@mail.gmail.com>

On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
> >
> >> I am trying to implement OF_EARLYCON_DECLARE() for that.
> >>
> >> I was just wondering if console_initcall() should work as well.
> >>
> >>
> >> As I said, I noticed the console_initcall() in 8250_core.c
> >> only works on very limited platforms.
> >
> > It works with all those that use of_serial.c, right?
> 
> I doubt it.
> 
> 
> I have a board with a pure 8250-compat device working.
> (  compatible = "ns16550a")
> It uses of_serial.c, of course.
> 
> 
> As far as I tested, it would never enable the console at console_init().

Ok, that sounds like a bug. Peter and others have changed that code
a lot in the last year. I wonder if this has never worked then or
if it has regressed.

> The console is enabled when the UART driver is probed.
> (or earlycon if "earlycon" is specified in the kernel-parameter.)

Got it. Let me know if you think this interpretation is correct:

* univ8250_console_match() looks for the earlycon argument format like
  "console=uart[8250],io|mmio|mmio32,<addr>[,<options>]", and that
  would work, but we don't want to have to pass all that data when
  the information should already be there.

* univ8250_console_setup() looks for ports that have been added by
  one of several other methods (including earlycon) already, but
  we don't do that on ARM without earlycon being enabled.

* arch/powerpc/kernel/legacy_serial.c does everything we need, but
  does not live in architecture independent code and does a few
  things that we probably don't need or want there. It relies
  on scanning the device tree for known UART device nodes before
  the platform devices are added.

* for console_initcall() to do the right thing, we want both the
  ttyS devices to get added early for console=ttyS1 to work, as well
  as having the preferred console work based on the stdout-property.

* we parse the /chosen/stdout-path property in drivers/of/base and
  store the device node pointer in the global 'of_stdout' variable,
  but do not use it until the uart is added by the tty driver
  and calls of_console_check() to add the default console device.
 
	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: console vs earlycon ?
Date: Wed, 21 Oct 2015 12:36:45 +0200	[thread overview]
Message-ID: <5490682.zH2vAEO2id@wuerfel> (raw)
In-Reply-To: <CAK7LNATniscPQ_vLMg91PWbMVSdoXtJYGL9nicsn49=ULQ-oAw@mail.gmail.com>

On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
> >
> >> I am trying to implement OF_EARLYCON_DECLARE() for that.
> >>
> >> I was just wondering if console_initcall() should work as well.
> >>
> >>
> >> As I said, I noticed the console_initcall() in 8250_core.c
> >> only works on very limited platforms.
> >
> > It works with all those that use of_serial.c, right?
> 
> I doubt it.
> 
> 
> I have a board with a pure 8250-compat device working.
> (  compatible = "ns16550a")
> It uses of_serial.c, of course.
> 
> 
> As far as I tested, it would never enable the console at console_init().

Ok, that sounds like a bug. Peter and others have changed that code
a lot in the last year. I wonder if this has never worked then or
if it has regressed.

> The console is enabled when the UART driver is probed.
> (or earlycon if "earlycon" is specified in the kernel-parameter.)

Got it. Let me know if you think this interpretation is correct:

* univ8250_console_match() looks for the earlycon argument format like
  "console=uart[8250],io|mmio|mmio32,<addr>[,<options>]", and that
  would work, but we don't want to have to pass all that data when
  the information should already be there.

* univ8250_console_setup() looks for ports that have been added by
  one of several other methods (including earlycon) already, but
  we don't do that on ARM without earlycon being enabled.

* arch/powerpc/kernel/legacy_serial.c does everything we need, but
  does not live in architecture independent code and does a few
  things that we probably don't need or want there. It relies
  on scanning the device tree for known UART device nodes before
  the platform devices are added.

* for console_initcall() to do the right thing, we want both the
  ttyS devices to get added early for console=ttyS1 to work, as well
  as having the preferred console work based on the stdout-property.

* we parse the /chosen/stdout-path property in drivers/of/base and
  store the device node pointer in the global 'of_stdout' variable,
  but do not use it until the uart is added by the tty driver
  and calls of_console_check() to add the default console device.
 
	Arnd

  reply	other threads:[~2015-10-21 10:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-21  8:21 console vs earlycon ? Masahiro Yamada
2015-10-21  8:21 ` Masahiro Yamada
2015-10-21  8:57 ` Arnd Bergmann
2015-10-21  8:57   ` Arnd Bergmann
2015-10-21  9:09   ` Masahiro Yamada
2015-10-21  9:09     ` Masahiro Yamada
2015-10-21  9:19     ` Arnd Bergmann
2015-10-21  9:19       ` Arnd Bergmann
2015-10-21  9:30       ` Masahiro Yamada
2015-10-21  9:30         ` Masahiro Yamada
2015-10-21 10:36         ` Arnd Bergmann [this message]
2015-10-21 10:36           ` Arnd Bergmann
2015-10-21 13:53           ` Peter Hurley
2015-10-21 13:53             ` Peter Hurley
2015-10-21 14:13             ` Arnd Bergmann
2015-10-21 14:13               ` Arnd Bergmann
2015-10-21 15:32               ` Peter Hurley
2015-10-21 15:32                 ` Peter Hurley
2015-10-21 19:00                 ` Arnd Bergmann
2015-10-21 19:00                   ` Arnd Bergmann
2015-10-21 19:24                   ` Peter Hurley
2015-10-21 19:24                     ` Peter Hurley
2015-10-21 22:54                     ` Arnd Bergmann
2015-10-21 22:54                       ` Arnd Bergmann
2015-10-21 13:20 ` Peter Hurley
2015-10-21 13:20   ` Peter Hurley
2015-10-22  4:47   ` Masahiro Yamada
2015-10-22  4:47     ` Masahiro Yamada

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=5490682.zH2vAEO2id@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=stefan@agner.ch \
    --cc=yamada.masahiro@socionext.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.