Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1704233 > unrolled thread

[PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang Graeme Gregory <graeme.gregory@linaro.org> - 2017-08-04 23:50 +0200
    [PATCH 2/2] ACPI: SPCR: work around clock issue on xgene UART Graeme Gregory <graeme.gregory@linaro.org> - 2017-08-05 00:00 +0200
    [PATCH 1/2] ACPI: SPCR: extend XGENE 8250 workaround to m400 Graeme Gregory <graeme.gregory@linaro.org> - 2017-08-05 00:00 +0200
    Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang "Rafael J. Wysocki" <rafael@kernel.org> - 2017-08-05 01:00 +0200
      Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang Graeme Gregory <graeme.gregory@linaro.org> - 2017-08-05 09:30 +0200
        Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang "Rafael J. Wysocki" <rafael@kernel.org> - 2017-08-05 14:30 +0200
    Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang "Rafael J. Wysocki" <rafael@kernel.org> - 2017-08-05 14:40 +0200
      Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-11 01:20 +0200
    Re: [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang Mark Salter <msalter@redhat.com> - 2017-08-06 04:30 +0200

#1704233 — [PATCH 0/2] Updated SPCR quirks for Moonshot/Mustang

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

[toc] | [next] | [standalone]

#1704239 — [PATCH 2/2] ACPI: SPCR: work around clock issue on xgene UART

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 <graeme.gregory@linaro.org>
---
 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

[toc] | [prev] | [next] | [standalone]

#1704241 — [PATCH 1/2] ACPI: SPCR: extend XGENE 8250 workaround to m400

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 <graeme.gregory@linaro.org>
---
 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

[toc] | [prev] | [next] | [standalone]

#1704266

On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
<graeme.gregory@linaro.org> 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

[toc] | [prev] | [next] | [standalone]

#1704599

On 4 August 2017 at 23:51, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
> <graeme.gregory@linaro.org> 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

[toc] | [prev] | [next] | [standalone]

#1704637

On Sat, Aug 5, 2017 at 9:25 AM, Graeme Gregory
<graeme.gregory@linaro.org> wrote:
> On 4 August 2017 at 23:51, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
>> <graeme.gregory@linaro.org> 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.

[toc] | [prev] | [next] | [standalone]

#1704639

On Fri, Aug 4, 2017 at 11:49 PM, Graeme Gregory
<graeme.gregory@linaro.org> 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?

[toc] | [prev] | [next] | [standalone]

#1709094

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
> <graeme.gregory@linaro.org> 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!

[toc] | [prev] | [next] | [standalone]

#1704730

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 <msalter@redhat.com>
Reviewed-by: Mark Salter <msalter@redhat.com>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web