Re: [RFC PATCH] always probe UART HW when options are not specified
From: Sebastian Frias
Date: Mon Jan 11 2016 - 12:56:18 EST
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:
There is no support for this uart in 8250 earlycon; the registers
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
at the end of the file, trying to mimic commit
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.
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,