console vs earlycon ?
peter at hurleysoftware.com
Wed Oct 21 08:32:15 PDT 2015
On 10/21/2015 10:13 AM, Arnd Bergmann wrote:
> On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
>> 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.
> Ah, I had no idea we were moving in this direction.
I would not say this was a conscious design decision, but rather an
outcome of getting-something-working-without-breaking-existing-usage.
My main focus with earlycon/console has been to try to reduce and
generalize the existing code.
> So I guess the idea
> is not to add another for_each_compatible_node() loop when we already have
> two places (earlycon and tty) in the code that do this?
I wouldn't want to do that just because, but rather only to enable some
functionality that doesn't work now.
FWIW, console_init() is basically a hack. The dummy color console
registration is a good example of the gymnastics made necessary by
OTOH, I don't like the reverse-linkage that exists now between
serial core and OF (ie., of_console_check()). And now ACPI wants to
recapitulate that design. :/
>>> * 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 don't think so.
> My line of thinking was more about usability: earlycon requires that
> you edit the kernel command line at the moment, while console_init()
> doesn't require any user interaction and just uses the stdout-path.
> I guess we could enable earlycon using a Kconfig symbol if we want
> to, or make it a per-architecture decision whether it's enabled even
> in the absence of the command line flag.
Ah, I see. You want to start the stdout-path console at console_init()
More information about the linux-arm-kernel