Message-ID: <56950A47.1070708@laposte.net>
Date:	Tue, 12 Jan 2016 15:14:31 +0100
From:	Sebastian Frias <sf84@...oste.net>
To:	Peter Hurley <peter@...leysoftware.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	mason <slash.tmp@...e.fr>,
	Måns Rullgård <mans@...sr.com>
Subject: Re: [RFC PATCH] always probe UART HW when options are not specified

Hi Peter,

On 01/11/2016 08:06 PM, Peter Hurley wrote:
> On 01/11/2016 09:56 AM, Sebastian Frias wrote:
>> 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"?
>
> I don't have enough information to suggest what you "should" use
> here.
>
> Is this going to be a shipping product?
> Is it single-core?
> etc.
>
> And what is your purpose for outputting early boot information
> before loading the serial driver which does provide console output?
>

No, it is not for production, just for debug, but we would like to 
understand if there is a standard way of doing so, so that whenever 
somebody ask us for "early print", we can provide with the good way.
I know we can always provide with hacks, I'm just wondering if there's a 
"standard way".

>
>> 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?
>
> The rt2880 does not have the same register locations as a 8250.
> The 8250 port driver remaps all register accesses with a LUT.
>
> Adding support would be trivial.

Ok, I will see if I can find some commit that does something similar to 
get some inspiration.

>
>>>>> 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
>
> At the time, I didn't know you were describing your h/w with DT.

Oh, sorry for the inconvenience then.

>
> If you use the console command line (console= or earlycon=) to start
> an earlycon, then the uart address and iotype are mandatory.
> For this usage, earlycon matching is attempted with every EARLYCON_DECLARE().
>
> If you use plain "earlycon" on the command line, that will attempt to
> register the uart described by stdout-path in DT. For this usage,
> earlycon matching is attempted with the compatible string of every
> OF_EARLYCON_DECLARE().

I see, and since rt288x variant is not fully supported (no 
OF_EARLYCON_DECLARE) "earlycon" fails.

>
>> (http://www.spinics.net/lists/linux-serial/msg20383.html), like how
>> are DT described drivers supposed to interact with the
>> "console="/"earlycon=" commandlines
>
> They don't; those are orthogonal.

Ok.

>
>> , or, the contradiction between
>> "console=ttyS0" means '9600n81' and "if unspecified [the uart
>> options], the h/w is not re-initialized">
>
> I thought I was clear on that: "console=ttyS0" initializes the h/w
> to 9600n81 *because there are already existing users that must not break*.
>
> "console=uart,..." probes the h/w
> *because there are already existing users that must not break *

Thanks, I had misunderstood.

>
>> 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')
>
> The DT way will be simplest at this point because you won't
> have to write console handover matching for "console=rt288x,..."
>
> With DT (ie, stdout-path) earlycon, when a serial driver loads,
> an attempt is made to cross-reference any existing console with
> the node that is loading and will do a console takeover from
> a running earlycon for a matching uart node.
>
> There is a bug with DT earlycon though.
> If you have a dummy console that loads, the DT earlycon is
> disabled at that point because boot consoles are disabled when
> "real" consoles load.

I'm sorry for my ignorance, but what is a "dummy console"? Under what 
circumstances would it load and this bug be seen?

Regards,

Sebastian

Powered by blists - more mailing lists