From: Mark Salter <msalter@redhat.com>
To: Jon Masters <jcm@redhat.com>, Duc Dang <dhdang@apm.com>
Cc: Rafael Wysocki <rafael@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
patches <patches@apm.com>,
Aleksey Makarov <aleksey.makarov@linaro.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Grant Likely <grant.likely@hpe.com>
Subject: Re: [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART
Date: Sat, 03 Dec 2016 12:15:08 -0500 [thread overview]
Message-ID: <1480785308.4751.41.camel@redhat.com> (raw)
In-Reply-To: <7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com>
On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:
> 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 <jcm@redhat.com> 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.
Linaro has a kernel patch which looks at the bit_width field of the
port address:
Author: Aleksey Makarov <aleksey.makarov@linaro.org>
Date: Thu Apr 28 19:52:38 2016 +0300
serial: SPCR: check bit width for the 16550 UART
The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
above patch, I don't need to use console=. But HP firmware on m400 sets
bit width to 8 so that needs a firmware fix to work with above.
>
> 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.
>
next prev parent reply other threads:[~2016-12-03 17:15 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 23:42 [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller Duc Dang
2016-12-01 15:08 ` Mark Salter
2016-12-01 19:17 ` Jon Masters
2016-12-01 19:58 ` Duc Dang
2016-12-01 18:33 ` Bjorn Helgaas
2016-12-01 19:20 ` Mark Salter
2016-12-01 19:26 ` Jon Masters
2016-12-01 19:41 ` Bjorn Helgaas
2016-12-01 22:10 ` Duc Dang
2016-12-01 22:31 ` Jon Masters
2016-12-01 23:07 ` Bjorn Helgaas
2016-12-01 23:22 ` Duc Dang
2016-12-02 4:08 ` Jon Masters
2016-12-02 6:31 ` Jon Masters
2016-12-02 7:34 ` Duc Dang
2016-12-02 8:08 ` Jon Masters
2016-12-02 23:39 ` Bjorn Helgaas
2016-12-03 0:33 ` Jon Masters
2016-12-05 21:21 ` Bjorn Helgaas
2016-12-06 19:46 ` Jon Masters
2016-12-06 20:18 ` Bjorn Helgaas
2016-12-06 20:23 ` Jon Masters
2016-12-13 21:35 ` Jon Masters
2016-12-03 7:06 ` Duc Dang
2016-12-05 21:20 ` Bjorn Helgaas
2016-12-05 21:40 ` Duc Dang
2016-12-05 23:31 ` Jon Masters
2016-12-02 2:27 ` [PATCH v4 1/1] " Duc Dang
2016-12-02 7:12 ` Jon Masters
2016-12-02 7:36 ` Duc Dang
2016-12-02 8:11 ` Jon Masters
2016-12-02 19:39 ` Duc Dang
2016-12-02 19:59 ` Jon Masters
2016-12-03 10:06 ` [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART Jon Masters
2016-12-03 17:11 ` Graeme Gregory
2016-12-03 17:15 ` Mark Salter [this message]
2016-12-03 20:33 ` Jon Masters
2016-12-04 10:35 ` Duc Dang
2016-12-02 11:36 ` [PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller Graeme Gregory
2016-12-02 2:52 ` [PATCH v3] " Duc Dang
2016-12-05 21:53 ` Bjorn Helgaas
2016-12-05 22:09 ` Duc Dang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1480785308.4751.41.camel@redhat.com \
--to=msalter@redhat.com \
--cc=aleksey.makarov@linaro.org \
--cc=arnd@arndb.de \
--cc=dhdang@apm.com \
--cc=grant.likely@hpe.com \
--cc=jcm@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@apm.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).