diff for duplicates of <1480785308.4751.41.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index eea5fe3..caadbd1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -39,9 +39,9 @@ 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 +Date:???Thu Apr 28 19:52:38 2016 +0300 - serial: SPCR: check bit width for the 16550 UART +????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 @@ -51,8 +51,8 @@ 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"; +> ????????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 @@ -71,19 +71,19 @@ bit width to 8 so that needs a firmware fix to work with above. > 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 :) +> ????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. +> ????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. +> ????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 diff --git a/a/content_digest b/N1/content_digest index a6b9a25..25e9ccc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,19 +5,10 @@ "ref\0175F32B0-C73F-4250-9E60-3CE7409F0B0C@redhat.com\0" "ref\0CADaLNDmWRn+UKzF8PH2LmYCSF+NhHaw26RTN+QoaByh1wS7jfQ@mail.gmail.com\0" "ref\07fa523de-3fbb-1566-f521-927143f73d1e@redhat.com\0" - "From\0Mark Salter <msalter@redhat.com>\0" - "Subject\0Re: [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART\0" + "From\0msalter@redhat.com (Mark Salter)\0" + "Subject\0[SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART\0" "Date\0Sat, 03 Dec 2016 12:15:08 -0500\0" - "To\0Jon Masters <jcm@redhat.com>" - " Duc Dang <dhdang@apm.com>\0" - "Cc\0Rafael 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>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:\n" @@ -61,9 +52,9 @@ "port address:\n" "\n" "Author: Aleksey Makarov <aleksey.makarov@linaro.org>\n" - "Date:\302\240\302\240\302\240Thu Apr 28 19:52:38 2016 +0300\n" + "Date:???Thu Apr 28 19:52:38 2016 +0300\n" "\n" - "\302\240\302\240\302\240\302\240serial: SPCR: check bit width for the 16550 UART\n" + "????serial: SPCR: check bit width for the 16550 UART\n" "\n" "The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the\n" "above patch, I don't need to use console=. But HP firmware on m400 sets\n" @@ -73,8 +64,8 @@ "> \n" "> The earlycon preferred console will parse the SPCR and find:\n" "> \n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\"mmio\" : \"io\";\n" + "> ????????iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?\n" + "> ????????????????????????\"mmio\" : \"io\";\n" "> \n" "> Which sets it to \"mmio\" (not \"mmio32\"). There is a DBG2 (the table\n" "> referenced by the SPCR that provides the actual port types for all\n" @@ -93,19 +84,19 @@ "> There are a couple of possibilities:\n" "> \n" "> 1). Perhaps (for some reason) the IP actually does support sub-32-bit\n" - "> \302\240\302\240\302\240\302\240access and the iotype simply needs to be changed to reflect this.\n" - "> \302\240\302\240\302\240\302\240That would be the easiest option. But it's been this way for a\n" - "> \302\240\302\240\302\240\302\240long time in various codebases, so I would be pleasantly\n" - "> \302\240\302\240\302\240\302\240surprised if this were the case. Let me/us know :)\n" + "> ????access and the iotype simply needs to be changed to reflect this.\n" + "> ????That would be the easiest option. But it's been this way for a\n" + "> ????long time in various codebases, so I would be pleasantly\n" + "> ????surprised if this were the case. Let me/us know :)\n" "> \n" "> 2). We find some way during SPCR setup to quirk for X-Gene as a non\n" - "> \302\240\302\240\302\240\302\240standard 16550 and set it up as an mmio32 iotype.\n" + "> ????standard 16550 and set it up as an mmio32 iotype.\n" "> \n" "> 3). We get the DBG2 table updated to add a subtype of the 16650\n" - "> \302\240\302\240\302\240\302\240called something like \"(deprecated) 16550 subset supporting\n" - "> \302\240\302\240\302\240\302\240only 32-bit accesses\". Then we add this to Linux and get\n" - "> \302\240\302\240\302\240\302\240the firmware updated on systems to switch to this type. We\n" - "> \302\240\302\240\302\240\302\240would probably still want to quirk for existing machines.\n" + "> ????called something like \"(deprecated) 16550 subset supporting\n" + "> ????only 32-bit accesses\". Then we add this to Linux and get\n" + "> ????the firmware updated on systems to switch to this type. We\n" + "> ????would probably still want to quirk for existing machines.\n" "> \n" "> Perhaps I'm missing something. I would love for that to be true,\n" "> but I don't think it is. I think we need a subtype of the 16550\n" @@ -120,4 +111,4 @@ "> Jon.\n" > -5f85b8f678c58b0629906bf9e52048fdb6eb521a9859022e5f200b0de3f5f318 +8fe89b57f920fa1de33109548648451b75fd8438f46631dd2aba8012b672710f
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.