Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1306573

Re: [RFC PATCH] always probe UART HW when options are not specified

From Sebastian Frias <sf84@laposte.net>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] always probe UART HW when options are not specified
Date 2016-01-11 19:00 +0100
Message-ID <qPOV5-5Iz-7@gated-at.bofh.it> (permalink)
References (7 earlier) <qH4Pp-7gd-31@gated-at.bofh.it> <qIbYu-zb-11@gated-at.bofh.it> <qIzo5-70P-5@gated-at.bofh.it> <qPMgy-434-29@gated-at.bofh.it> <qPNmh-4Mf-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-11 16:10 +0100
  Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 17:20 +0100
    Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-11 19:00 +0100
      Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 20:10 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 21:00 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 21:30 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Mason <slash.tmp@free.fr> - 2016-01-12 10:40 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-12 15:30 +0100
            Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 20:50 +0100
              Re: [RFC PATCH] always probe UART HW when options are not specified Mason <slash.tmp@free.fr> - 2016-01-12 23:30 +0100
                Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 23:50 +0100
              Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-13 12:20 +0100
                Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-13 17:40 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-12 15:20 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 22:20 +0100

csiph-web