Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751635AbcLCKGm (ORCPT ); Sat, 3 Dec 2016 05:06:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39452 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbcLCKGj (ORCPT ); Sat, 3 Dec 2016 05:06:39 -0500 Subject: [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART To: Duc Dang References: <20161201183350.GF30746@bhelgaas-glaptop.roam.corp.google.com> <6d593615-e97f-8738-42be-1f8f4906d2f4@redhat.com> <175F32B0-C73F-4250-9E60-3CE7409F0B0C@redhat.com> Cc: Rafael Wysocki , Arnd Bergmann , Mark Salter , linux-arm , Linux Kernel Mailing List , patches , Aleksey Makarov , "linux-acpi@vger.kernel.org" , Grant Likely From: Jon Masters Message-ID: <7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com> Date: Sat, 3 Dec 2016 05:06:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Sat, 03 Dec 2016 10:06:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3682 Lines: 85 Hi Duc, all, (and changing the subject and trimming/adjusting the CC) On 12/02/2016 02:39 PM, Duc Dang wrote: > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters wrote: >> You're welcome. >> >> (Unrelated) Note that I added a console= and earlycon in my test (and >> got the baud rate wrong for the console but nevermind...was ssh'd in >> after the earlycon output I cared about anyway) because of some other >> cleanup work for the SPCR parsing that apparently is still not quite >> fixed for upstream, or rather, there is a need to match on the 32-bit >> access required for the UART and that isn't happening so it's not >> getting setup. Folks are tracking that one and fixing it though. > I don't see this console issue on X-Gene1 (Mustang board). I tried > with X-Gene 2 as well. I used both console=ttyS0,115200 and > earlycon=uart8250,mmio32,0x1c020000. Are you setting baudrate to > 115200 or something else? Let me clarify. What I meant above is that when I generated the boot log, I had specified earlycon and console parameters, but had fat fingered the baud rate (m400 uses 9600, mustang uses 115200 baud). That's what I was referring to in the original text above. HOWEVER... There is a broader problem with X-Gene SPCR support. The problem is that the 16550 UART in X-Gene requires the 32-bit access quirk (the iotype is set to UPIO_MEM32 for the APMC0D08 device). This means that when univ8250_console_match runs later, it will compare the iotype (MEM32) with the type previously registered with the kernel when the earlycon setup the preferred console. The earlycon preferred console will parse the SPCR and find: iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ? "mmio" : "io"; Which sets it to "mmio" (not "mmio32"). There is a DBG2 (the table referenced by the SPCR that provides the actual port types for all modern revisions of the SPCR with revision2+, as required by Linux) port subtype for non-compliant SBSA ARM Generic UARTs that require 32-bit accesses, and this is ACPI_DBG2_ARM_SBSA_32BIT (type 0xd). However that only applies for "pl011" devices, and doesn't provide for 16550 UARTs that require 32-bit accessors. So you'll end up with Linux thinking it's registering a non-32-bit mmio preferred console during earlycon setup and then never match against that later in the 8250_core/8250_dw match function by virtue of the fact that these differ. There are a couple of possibilities: 1). Perhaps (for some reason) the IP actually does support sub-32-bit access and the iotype simply needs to be changed to reflect this. That would be the easiest option. But it's been this way for a long time in various codebases, so I would be pleasantly surprised if this were the case. Let me/us know :) 2). We find some way during SPCR setup to quirk for X-Gene as a non standard 16550 and set it up as an mmio32 iotype. 3). We get the DBG2 table updated to add a subtype of the 16650 called something like "(deprecated) 16550 subset supporting only 32-bit accesses". Then we add this to Linux and get the firmware updated on systems to switch to this type. We would probably still want to quirk for existing machines. Perhaps I'm missing something. I would love for that to be true, but I don't think it is. I think we need a subtype of the 16550 defined that encapsulates this mmio32 requirement properly. To that end, I've preemptively asked some friends at MS for a favor to look into adding a new subtype for this. Let me know what you think is the best path... :) Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop