[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <562798EB.7060202@hurleysoftware.com>
Date: Wed, 21 Oct 2015 09:53:47 -0400
From: Peter Hurley <peter@...leysoftware.com>
To: Arnd Bergmann <arnd@...db.de>,
Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stefan Agner <stefan@...er.ch>, linux-serial@...r.kernel.org,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: console vs earlycon ?
On 10/21/2015 06:36 AM, Arnd Bergmann wrote:
> 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.
No, not a bug. console_init() is only for legacy platforms, not for
probed drivers.
>> 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.
This only works at console_init() time for legacy platforms that
have already initialized the 8250 port table.
> * univ8250_console_setup() looks for ports that have been added by
> one of several other methods (including earlycon) already
8250 earlycon doesn't add ports.
> , 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.
I'm assuming the issue with trying to get console_init() working
is because the dummy color console causes the earlycon to be disabled?
I fixed that once before for stdout-path but there were some regressions
on PPC platforms; maybe I can revisit that.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists