From: Sebastian Frias <sf84@laposte.net>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
mason <slash.tmp@free.fr>, "Måns Rullgård" <mans@mansr.com>
Subject: Re: [RFC PATCH] always probe UART HW when options are not specified
Date: Mon, 11 Jan 2016 18:56:10 +0100 [thread overview]
Message-ID: <5693ECBA.50003@laposte.net> (raw)
In-Reply-To: <5693D41E.8050601@hurleysoftware.com>
Hi Peter,
On 01/11/2016 05:11 PM, Peter Hurley wrote:
> On 01/11/2016 07:07 AM, Sebastian Frias wrote:
>> On 12/22/2015 06:56 PM, Sebastian Frias wrote:
>>>
>>> OF_EARLYCON_DECLARE(rt2880, "ralink,rt2880-uart",
>>> early_serial8250_setup);
>
> There is no support for this uart in 8250 earlycon; the registers
> need remapped.
Ok, two questions then:
1) If the UART is not supported on 8250 earlycon, what is the
suggested/advised solution? Using just "earlyprintk"?
2) What would it take to make the "rt2880" work with the 8250 earlycon?
I mean, it is already pretty much supported in there, what would be
missing? (I don't see why it blocks on earlycon_map) And would it be
worth doing?
>
>>> at the end of the file, trying to mimic commit
>>> d05f15707bb7659d2b863fafa1a918f286d74a63
>>>
>>> I'm still trying to figure out the right bootargs, so that's why both
>>> "earlycon" and "console" are there. Suggestions welcome.
>
> Just 'earlycon' triggers the attempted registration of earlycon matching the
> compatible string of the stdout-path node.
>
> The empty 'console' in bootargs is doing nothing.
Ok, thanks.
So, just to recap.
We would like to understand what is the right way of doing this:
- we are using 8250 (rt288x variant) UART: CONFIG_SERIAL_8250_RT288X=y
- the UART hardware is setup prior to Linux boot
- we don't want Linux to change the UART settings, just to pick up
whatever settings the UART has and take over the UART.
There were two replies to that, one by Greg Kroah-Hartman
(http://www.spinics.net/lists/linux-serial/msg20278.html) and one by
you, where you suggested we use "console=uart", but as I reported
(http://www.spinics.net/lists/linux-serial/msg20307.html) it does not
work, you replied that iotype and mmio are not optional but mandatory
(http://www.spinics.net/lists/linux-serial/msg20310.html), and I
wondered if it was really necessary to duplicate data that is already on
the DT among other questions
(http://www.spinics.net/lists/linux-serial/msg20383.html), like how are
DT described drivers supposed to interact with the
"console="/"earlycon=" commandlines, or, the contradiction between
"console=ttyS0" means '9600n81' and "if unspecified [the uart options],
the h/w is not re-initialized"
So, for us, it is still not clear what is the recommended way of
achieving our goal above, and it seems it is not clear what does
"console=ttyS0" is supposed to do, hardcode ('9600n81') or probe ('the
h/w is not re-initialized')
Any help will be appreciated.
Thanks, best regards,
Sebastian
next prev parent reply other threads:[~2016-01-11 17:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5672D18E.8000301@laposte.net>
2015-12-17 15:23 ` [RFC PATCH] always probe UART HW when options are not specified Måns Rullgård
2015-12-17 16:29 ` Peter Hurley
2015-12-17 16:48 ` Sebastian Frias
2015-12-17 17:21 ` Greg Kroah-Hartman
2015-12-17 19:05 ` Sebastian Frias
2015-12-17 17:48 ` Peter Hurley
2015-12-17 18:21 ` Sebastian Frias
2015-12-17 20:09 ` Peter Hurley
2015-12-18 13:53 ` Sebastian Frias
2015-12-18 15:03 ` Peter Hurley
2015-12-21 16:50 ` Sebastian Frias
2015-12-22 17:56 ` Sebastian Frias
2016-01-11 15:07 ` Sebastian Frias
2016-01-11 16:11 ` Peter Hurley
2016-01-11 17:56 ` Sebastian Frias [this message]
2016-01-11 19:06 ` Peter Hurley
2016-01-11 19:57 ` Peter Hurley
2016-01-11 20:21 ` Peter Hurley
2016-01-12 9:37 ` Mason
2016-01-12 14:22 ` Sebastian Frias
2016-01-12 19:47 ` Peter Hurley
2016-01-12 22:26 ` Mason
2016-01-12 22:42 ` Peter Hurley
2016-01-13 11:14 ` Sebastian Frias
2016-01-13 16:34 ` Peter Hurley
2016-01-18 11:52 ` Sebastian Frias
2016-01-12 14:14 ` Sebastian Frias
2016-01-12 21:18 ` Peter Hurley
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=5693ECBA.50003@laposte.net \
--to=sf84@laposte.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mans@mansr.com \
--cc=peter@hurleysoftware.com \
--cc=slash.tmp@free.fr \
/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;
as well as URLs for NNTP newsgroup(s).