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
next prev parent 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.