A couple of patches to build on the SPCR quirks support already upstreamed.
1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
HPe specific headers so extend quirk to understand those too.
2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
situation where the clock is unknown. We want these machines to boot with
console initialised from SPCR before I die of old age so use the previous
quirk handling to also handle the clock problem as well.
Thanks
Graeme
xgene v1/v2 8250 UARTs don't run at the standard clock rate expected by
the driver and there is no information on clocking available from the
SPCR table. As there has been no progress on relevant vendors updating
DBG2/SPCR specifications to fix this work around this using the previous
xgene quirk handling to avoid setting a baud rate and therefore using
the UART as configured by firmware.
Signed-off-by: Graeme Gregory <[email protected]>
---
drivers/acpi/spcr.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 1457ef0b0fd5..a57e2698df39 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -156,11 +156,19 @@ int __init parse_spcr(bool earlycon)
if (qdf2400_erratum_44_present(&table->header))
uart = "qdf2400_e44";
- if (xgene_8250_erratum_present(table))
+ if (xgene_8250_erratum_present(table)) {
iotype = "mmio32";
- snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
- table->serial_port.address, baud_rate);
+ /* for xgene v1 and v2 we don't know the clock rate of the
+ * UART so don't attempt to change to the baud rate state
+ * in the table because driver cannot calculate the dividers
+ */
+ snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
+ table->serial_port.address);
+ } else {
+ snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
+ table->serial_port.address, baud_rate);
+ }
pr_info("console: %s\n", opts);
--
2.13.4
xgene v1/v2 chips are also used on moonshot cartridges that have
different table headers to the ones on Mustang. Extend the quirk
so it also recognises the Moonshot M400 variant too.
Signed-off-by: Graeme Gregory <[email protected]>
---
drivers/acpi/spcr.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 4ac3e06b41d8..1457ef0b0fd5 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -43,17 +43,24 @@ static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
*/
static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
{
+ bool xgene_8250 = false;
+
if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
return false;
- if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE))
+ if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+ memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
return false;
if (!memcmp(tb->header.oem_table_id, "XGENESPC",
ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
- return true;
+ xgene_8250 = true;
- return false;
+ if (!memcmp(tb->header.oem_table_id, "ProLiant",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
+ xgene_8250 = true;
+
+ return xgene_8250;
}
/**
--
2.13.4
On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
<[email protected]> wrote:
> A couple of patches to build on the SPCR quirks support already upstreamed.
>
> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
> HPe specific headers so extend quirk to understand those too.
>
> 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
> situation where the clock is unknown. We want these machines to boot with
> console initialised from SPCR before I die of old age so use the previous
> quirk handling to also handle the clock problem as well.
It increasingly seems to me that spcr.c firmly belongs in
drivers/acpi/arm64/. Any chance to move it in there and then mess up
with it further?
Thanks,
Rafael
On 4 August 2017 at 23:51, Rafael J. Wysocki <[email protected]> wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> <[email protected]> wrote:
>> A couple of patches to build on the SPCR quirks support already upstreamed.
>>
>> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
>> HPe specific headers so extend quirk to understand those too.
>>
>> 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
>> situation where the clock is unknown. We want these machines to boot with
>> console initialised from SPCR before I die of old age so use the previous
>> quirk handling to also handle the clock problem as well.
>
> It increasingly seems to me that spcr.c firmly belongs in
> drivers/acpi/arm64/. Any chance to move it in there and then mess up
> with it further?
>
Apparently x86 machines exist with SPCR table.
But if that is your wish I can certainly add that to series.
Graeme
On Sat, Aug 5, 2017 at 9:25 AM, Graeme Gregory
<[email protected]> wrote:
> On 4 August 2017 at 23:51, Rafael J. Wysocki <[email protected]> wrote:
>> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
>> <[email protected]> wrote:
>>> A couple of patches to build on the SPCR quirks support already upstreamed.
>>>
>>> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
>>> HPe specific headers so extend quirk to understand those too.
>>>
>>> 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
>>> situation where the clock is unknown. We want these machines to boot with
>>> console initialised from SPCR before I die of old age so use the previous
>>> quirk handling to also handle the clock problem as well.
>>
>> It increasingly seems to me that spcr.c firmly belongs in
>> drivers/acpi/arm64/. Any chance to move it in there and then mess up
>> with it further?
>>
> Apparently x86 machines exist with SPCR table.
OK then.
On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
<[email protected]> wrote:
> A couple of patches to build on the SPCR quirks support already upstreamed.
>
> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
> HPe specific headers so extend quirk to understand those too.
>
> 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
> situation where the clock is unknown. We want these machines to boot with
> console initialised from SPCR before I die of old age so use the previous
> quirk handling to also handle the clock problem as well.
Anyone any objections against this series?
On Fri, 2017-08-04 at 22:49 +0100, Graeme Gregory wrote:
> A couple of patches to build on the SPCR quirks support already upstreamed.
>
> 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
> HPe specific headers so extend quirk to understand those too.
>
> 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
> situation where the clock is unknown. We want these machines to boot with
> console initialised from SPCR before I die of old age so use the previous
> quirk handling to also handle the clock problem as well.
>
> Thanks
>
> Graeme
For the series:
Tested-by: Mark Salter <[email protected]>
Reviewed-by: Mark Salter <[email protected]>
On Saturday, August 5, 2017 2:32:33 PM CEST Rafael J. Wysocki wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> <[email protected]> wrote:
> > A couple of patches to build on the SPCR quirks support already upstreamed.
> >
> > 1 - Moonshot m400 cartridge has the same soc but ACPI tables have different
> > HPe specific headers so extend quirk to understand those too.
> >
> > 2 - Relevant vendors do not seem to be working on DBG2/SPCR update for
> > situation where the clock is unknown. We want these machines to boot with
> > console initialised from SPCR before I die of old age so use the previous
> > quirk handling to also handle the clock problem as well.
>
> Anyone any objections against this series?
OK
Applied now, thanks!