From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753791AbbJUNx4 (ORCPT ); Wed, 21 Oct 2015 09:53:56 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:34696 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752365AbbJUNxy (ORCPT ); Wed, 21 Oct 2015 09:53:54 -0400 Subject: Re: console vs earlycon ? To: Arnd Bergmann , Masahiro Yamada References: <14202684.GgqlkWAZA0@wuerfel> <5490682.zH2vAEO2id@wuerfel> Cc: Linux Kernel Mailing List , Stefan Agner , linux-serial@vger.kernel.org, linux-arm-kernel From: Peter Hurley Message-ID: <562798EB.7060202@hurleysoftware.com> Date: Wed, 21 Oct 2015 09:53:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5490682.zH2vAEO2id@wuerfel> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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,[,]", 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