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

Groups > linux.kernel > #1537173 > unrolled thread

[RFC v2 0/4] ACPI: SPCR: 32-bit access and non-standard baud rate

Back to article view | Back to linux.kernel

Contents

  [RFC v2 0/4] ACPI: SPCR: 32-bit access and non-standard baud rate Aleksey Makarov <aleksey.makarov@linaro.org> - 2016-12-06 19:00 +0100
    Re: [RFC v2 0/4] ACPI: SPCR: 32-bit access and non-standard baud rate Jon Masters <jcm@redhat.com> - 2016-12-06 19:30 +0100

#1537173 — [RFC v2 0/4] ACPI: SPCR: 32-bit access and non-standard baud rate

ACPI [SPCR] (Serial Port Console Redirection Table) specifies which console
should be used by system.  'ARM Server Base Boot Requirements' [SBBR] mentions
SPCR as a mandatory ACPI table.  Support for this table for Linux kernel
([SPCR v10]) was merged for 4.9 (patches 1/4-3/4) and 4.10 (patch 4/4).

It turns out that this approach does not work for all the existing hardware.
There are two problems with AppliedMicro X-Gene based boards
([discussion], [v1]):

1. Their console is a 16550 port that requires 32-bit access.  Now SPCR does not
   have any method to specify this.

2. Some of the boards don't use the "standard" 16550 clock rate so supplying
   a baud rate makes it change to a random baud rate.

Patch 1/4 uses 'Register Bit Width' field of the ACPI Generic Address
Structure that specifies the address of the UART registers to
decide if the driver should use "mmio32" access instead of "mmio".
This fixes problem 1 for existing hardware/firmware.

To fix problem 2, I suggest to introduce a new value '0' for the "Baud Rate"
field of SPCR (now this value is reserved).  I would like to discuss if this
could be added to SPCR spec and will fix the problem.

Patch 2/4 introduces a check for this value.  In this case the code does not
emit baud rate specification for initialization of the console.  This fixes
problem 2.

It was also suggested ([v1]) to add a new Microsoft Debug Port Table 2 ([DBG2])
(the table used to enumerate the various subtypes of serial port covered by the
SPCR) 16550 UART subtype that may be needed for some additional platforms,
such as those based upon AppliedMicro X-Gene ARMv8 SoCs.  This new subtype would
be 16550-compatible with 32-bit access.  There already exists 32-bit variant
ACPI_DBG2_ARM_SBSA_32BIT of SBSA console ACPI_DBG2_ARM_SBSA_GENERIC.

Patch 3/4 introduces this value for DBG2 table.

Patch 4/4 uses it.

RFC v2:
  - Add a fix for consoles with non-standard baud rate.
  - Introduce a new type of console that is 16550 with 32-bit access
  - Check for that type of console.

v1: [v1]

[SPCR]       https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
[DBG2]       http://go.microsoft.com/fwlink/p/?LinkId=234837
[SBBR]       http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[SPCR v10]   https://lkml.kernel.org/r/20160905123617.18775-1-aleksey.makarov@linaro.org
[discussion] https://lkml.kernel.org/r/7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com
[v1]         https://lkml.kernel.org/r/20161205130534.11080-1-aleksey.makarov@linaro.org

Aleksey Makarov (4):
  ACPI: SPCR: check bit width for the 16550 UART
  ACPI: SPCR: don't initialize baud rate
  ACPI: DBG2: add 16550 UART with 32-bit access
  ACPI: SPCR: support 16550 UART with 32-bit access

 drivers/acpi/spcr.c   | 29 ++++++++++++++++++++++-------
 include/acpi/actbl2.h |  1 +
 2 files changed, 23 insertions(+), 7 deletions(-)

-- 
2.10.2

[toc] | [next] | [standalone]

#1537195

Hi Aleksey,

On 12/06/2016 12:58 PM, Aleksey Makarov wrote:

> It turns out that this approach does not work for all the existing hardware.
> There are two problems with AppliedMicro X-Gene based boards
> ([discussion], [v1]):
> 
> 1. Their console is a 16550 port that requires 32-bit access.  Now SPCR does not
>    have any method to specify this.
> 
> 2. Some of the boards don't use the "standard" 16550 clock rate so supplying
>    a baud rate makes it change to a random baud rate.
> 
> Patch 1/4 uses 'Register Bit Width' field of the ACPI Generic Address
> Structure that specifies the address of the UART registers to
> decide if the driver should use "mmio32" access instead of "mmio".
> This fixes problem 1 for existing hardware/firmware.
> 
> To fix problem 2, I suggest to introduce a new value '0' for the "Baud Rate"
> field of SPCR (now this value is reserved).  I would like to discuss if this
> could be added to SPCR spec and will fix the problem.

Part 1 could well be solved in this way, provided it can be made part
of the mainstream specification. It seems fairly reasonable, however.

I'm not sure I subscribe to part 2 because there could be all manner
of havoc changing the interpretation of existing zero values. That is
why I personally favor an AppliedMicro SPCR subtype specific to them.

That all said, I did discuss exactly part 2 with the folks responsible
for the SPCR specification and they are thinking about their preferred
solution, which will likely either be a new subtype for Applied, or
perhaps allow for what you describe. I will followup when I know.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web