drivers: PL011: add ARM SBSA Generic UART support

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---
 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 ++
 drivers/tty/serial/amba-pl011.c                    |  154 ++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt new file +9 -0

new file mode 100644
index 0000000..21d211f
@@ -0,0 +1,9 @@
+* ARM SBSA defined generic UART
+This UART uses a subset of the PL011 registers and consequently lives
+in the PL011 driver. It's baudrate and other communication parameters
+cannot be adjusted at runtime, so it lacks a clock specifier here.
+
+Required properties:
+- compatible: must be "arm,sbsa-uart"
+- reg: exactly one register range
+- interrupts: exactly one interrupt specifier

drivers/tty/serial/amba-pl011.c +0 -0

index a1c929f..596e641 100644

Quoted 47 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---
 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 ++
 drivers/tty/serial/amba-pl011.c                    |  154 ++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt new file +9 -0

new file mode 100644
index 0000000..21d211f
@@ -0,0 +1,9 @@
+* ARM SBSA defined generic UART
+This UART uses a subset of the PL011 registers and consequently lives
+in the PL011 driver. It's baudrate and other communication parameters
+cannot be adjusted at runtime, so it lacks a clock specifier here.
+
+Required properties:
+- compatible: must be "arm,sbsa-uart"
+- reg: exactly one register range
+- interrupts: exactly one interrupt specifier

drivers/tty/serial/amba-pl011.c +0 -0

index a1c929f..596e641 100644
@@ -101,6 +101,14 @@ static struct vendor_data vendor_arm = {
 	.get_fifosize		= get_fifosize_arm,
 };
 

drivers/tty/serial/amba-pl011.c static struct vendor_data vendor_arm = { · line 110

Quoted 7 lines

drivers/tty/serial/amba-pl011.c +7 -0

+static struct vendor_data vendor_sbsa = {
+	.oversampling		= false,
+	.dma_threshold		= false,
+	.cts_event_workaround	= false,
+	.always_enabled		= true,
+	.fixed_options		= "115200n8",
+};

Is this configuration mandated by the SBSA? If so, please mandate it in the binding document.

If the rate and so on are not mandated, they should probably be described by the binding so software has a chance of getting the real configuration details.

Hi Mark,

Quoted 48 lines · Mark Rutland

Quoted 47 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---
 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 ++
 drivers/tty/serial/amba-pl011.c                    |  154 ++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt new file +9 -0

new file mode 100644
index 0000000..21d211f
@@ -0,0 +1,9 @@
+* ARM SBSA defined generic UART
+This UART uses a subset of the PL011 registers and consequently lives
+in the PL011 driver. It's baudrate and other communication parameters
+cannot be adjusted at runtime, so it lacks a clock specifier here.
+
+Required properties:
+- compatible: must be "arm,sbsa-uart"
+- reg: exactly one register range
+- interrupts: exactly one interrupt specifier

drivers/tty/serial/amba-pl011.c +0 -0

index a1c929f..596e641 100644
@@ -101,6 +101,14 @@ static struct vendor_data vendor_arm = {
 	.get_fifosize		= get_fifosize_arm,
 };
 

Quoted 10 lines

drivers/tty/serial/amba-pl011.c static struct vendor_data vendor_arm = { · line 110

Quoted 7 lines

drivers/tty/serial/amba-pl011.c +7 -0

+static struct vendor_data vendor_sbsa = {
+	.oversampling		= false,
+	.dma_threshold		= false,
+	.cts_event_workaround	= false,
+	.always_enabled		= true,
+	.fixed_options		= "115200n8",
+};

Is this configuration mandated by the SBSA? If so, please mandate it in the binding document.

No, actually it is just a placeholder. The driver needs some values to avoid querying the device and to make the upper levels happy, so I went with those. Actually 38400 would make more sense here, since that is some kind of Linux serial default value.

Quoted 3 lines

If the rate and so on are not mandated, they should probably be described by the binding so software has a chance of getting the real configuration details.

What the actual settings are is actually totally up to the firmware. By definition software cannot learn these settings and it shouldn't care, as the SBSA UART is just "meant to work(TM)". Though from userland it looks like one can change the baudrate and the other parameters, the driver totally ignores those settings (though it reflects it back).

Quoted 62 lines · Andre Przywara

Hi Mark,

Quoted 48 lines · Mark Rutland

Quoted 47 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---
 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 ++
 drivers/tty/serial/amba-pl011.c                    |  154 ++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt new file +9 -0

new file mode 100644
index 0000000..21d211f
@@ -0,0 +1,9 @@
+* ARM SBSA defined generic UART
+This UART uses a subset of the PL011 registers and consequently lives
+in the PL011 driver. It's baudrate and other communication parameters
+cannot be adjusted at runtime, so it lacks a clock specifier here.
+
+Required properties:
+- compatible: must be "arm,sbsa-uart"
+- reg: exactly one register range
+- interrupts: exactly one interrupt specifier

drivers/tty/serial/amba-pl011.c +0 -0

index a1c929f..596e641 100644
@@ -101,6 +101,14 @@ static struct vendor_data vendor_arm = {
 	.get_fifosize		= get_fifosize_arm,
 };
 

Quoted 10 lines

drivers/tty/serial/amba-pl011.c static struct vendor_data vendor_arm = { · line 110

Quoted 7 lines

drivers/tty/serial/amba-pl011.c +7 -0

+static struct vendor_data vendor_sbsa = {
+	.oversampling		= false,
+	.dma_threshold		= false,
+	.cts_event_workaround	= false,
+	.always_enabled		= true,
+	.fixed_options		= "115200n8",
+};

Is this configuration mandated by the SBSA? If so, please mandate it in the binding document.

Quoted 4 lines

No, actually it is just a placeholder. The driver needs some values to avoid querying the device and to make the upper levels happy, so I went with those. Actually 38400 would make more sense here, since that is some kind of Linux serial default value.

Please let's have the real values rather than something made up.

If I ask my UART how it's configured, I expect it to tell me the truth. It's nice to know before I connect something to the other end of the line.

Quoted 9 lines

Quoted 3 lines

If the rate and so on are not mandated, they should probably be described by the binding so software has a chance of getting the real configuration details.

What the actual settings are is actually totally up to the firmware. By definition software cannot learn these settings and it shouldn't care, as the SBSA UART is just "meant to work(TM)". Though from userland it looks like one can change the baudrate and the other parameters, the driver totally ignores those settings (though it reflects it back).

The fact that we cannot reconfigure it is orthogonal.

Given that all we should need is baud-rate, parity, and bits, it should be relatively easy to describe and handle.

Mark.

Hi Mark,

Quoted 68 lines · Mark Rutland

Quoted 66 lines · Andre Przywara

Hi Mark,

Quoted 48 lines · Mark Rutland

Quoted 47 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---
 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 ++
 drivers/tty/serial/amba-pl011.c                    |  154 ++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt new file +9 -0

new file mode 100644
index 0000000..21d211f
@@ -0,0 +1,9 @@
+* ARM SBSA defined generic UART
+This UART uses a subset of the PL011 registers and consequently lives
+in the PL011 driver. It's baudrate and other communication parameters
+cannot be adjusted at runtime, so it lacks a clock specifier here.
+
+Required properties:
+- compatible: must be "arm,sbsa-uart"
+- reg: exactly one register range
+- interrupts: exactly one interrupt specifier

drivers/tty/serial/amba-pl011.c +0 -0

index a1c929f..596e641 100644
@@ -101,6 +101,14 @@ static struct vendor_data vendor_arm = {
 	.get_fifosize		= get_fifosize_arm,
 };
 

Quoted 10 lines

drivers/tty/serial/amba-pl011.c static struct vendor_data vendor_arm = { · line 110

Quoted 7 lines

drivers/tty/serial/amba-pl011.c +7 -0

+static struct vendor_data vendor_sbsa = {
+	.oversampling		= false,
+	.dma_threshold		= false,
+	.cts_event_workaround	= false,
+	.always_enabled		= true,
+	.fixed_options		= "115200n8",
+};

Is this configuration mandated by the SBSA? If so, please mandate it in the binding document.

No, actually it is just a placeholder. The driver needs some values to avoid querying the device and to make the upper levels happy, so I went with those. Actually 38400 would make more sense here, since that is some kind of Linux serial default value.

Quoted 5 lines

Please let's have the real values rather than something made up.

If I ask my UART how it's configured, I expect it to tell me the truth. It's nice to know before I connect something to the other end of the line.

So you mean that the firmware (or the vendor) inserts the actual values here, which the kernel and eventually userland can read?

Makes some sense, so what about:
-----------------------
Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier

Optional properties:
- current-speed : the current active speed of the UART
- fifo-size : always 32 as per the SBSA specification
- word-size : the number of payload bits per word
- parity : used parity method, can be:
"n": no parity
"e": even parity
"o": odd parity
"m": always mark (logical 1)
"s": always space (logical 0)
- stop-bits : the number of stop bits after the payload

The vendor or the firmware should set these values to match the actual configuration of the UART. The SBSA spec does not provide ways of changing those values.
----------------------------
While I copied the first two of the optional properties from of-serial.txt, I made up the rest. Does they make sense?

Cheers,
Andre.

Quoted 17 lines

Quoted 9 lines

Quoted 3 lines

If the rate and so on are not mandated, they should probably be described by the binding so software has a chance of getting the real configuration details.

What the actual settings are is actually totally up to the firmware. By definition software cannot learn these settings and it shouldn't care, as the SBSA UART is just "meant to work(TM)". Though from userland it looks like one can change the baudrate and the other parameters, the driver totally ignores those settings (though it reflects it back).

The fact that we cannot reconfigure it is orthogonal.

Given that all we should need is baud-rate, parity, and bits, it should be relatively easy to describe and handle.

Mark.

Quoted 8 lines

Makes some sense, so what about:
-----------------------
Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier

Quoted 11 lines

Optional properties:
- current-speed : the current active speed of the UART
- fifo-size : always 32 as per the SBSA specification
- word-size : the number of payload bits per word
- parity : used parity method, can be:
"n": no parity
"e": even parity
"o": odd parity
"m": always mark (logical 1)
"s": always space (logical 0)
- stop-bits : the number of stop bits after the payload

Generally those look fine, though someone more familiar with serial should take a look.

We can drop fifo-size given it's fixed. Anything that we know outright doesn't need to be described.

We might want to make them mandatory. I don't see any value in not knowing.

Quoted 20 lines · On Friday 16 January 2015 18:37:17 Mark Rutland wrote:

Quoted 8 lines

Makes some sense, so what about:
-----------------------
Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier

Quoted 11 lines

Optional properties:
- current-speed : the current active speed of the UART
- fifo-size : always 32 as per the SBSA specification
- word-size : the number of payload bits per word
- parity : used parity method, can be:
"n": no parity
"e": even parity
"o": odd parity
"m": always mark (logical 1)
"s": always space (logical 0)
- stop-bits : the number of stop bits after the payload

Quoted 8 lines

Generally those look fine, though someone more familiar with serial should take a look.

We can drop fifo-size given it's fixed. Anything that we know outright doesn't need to be described.

We might want to make them mandatory. I don't see any value in not knowing.

I think making them optional is useless, so either make them mandatory or drop them if we can avoid it. Unfortunately, LCR is not part of SBSA, that would let us drop the properties and still report the correct settings.

Would we be better off documenting that 8-n-1 is the only allowed settting? I can't think of a reason why anyone would use something else.

Quoted 3 lines

Would we be better off documenting that 8-n-1 is the only allowed settting? I can't think of a reason why anyone would use something else.

Reading the spec again I see that 8-bit word len is mandated:
"The generic UART uses 8-bit words, equivalent to UARTLCR_H.WLEN == b11." So given this I guess anything other than (8)n1 is pretty useless and wouldn't probably be used anyways. This means that we can get rid of the optional properties altogether and just add "current-speed" to the list of required ones. I am about to implement this.

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---

Quoted 11 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

Quoted 8 lines

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---

<snip>

Andre,

I'm a little late to address this patchset, but the SBSA defines all the Generic UART registers 32-bit wide. However, the amba-pl011 driver uses 16-bit accessors. How will you be handling that? Can the ARM PL011 hardware handle 32-bit access?

Quoted 21 lines · Philip Elcan

Quoted 11 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.
We use the recent refactoring the build a new struct uart_ops variable which points to some new functions avoiding access to the missing registers. We reuse as much existing PL011 code as possible.

Quoted 8 lines

In contrast to the PL011 the SBSA UART does not define any AMBA or PrimeCell relations, so we go a pretty generic probe function which only uses platform device functions.
A DT binding is provided, but other systems can easily attach to it, too (hint, hint!).

Signed-off-by Andre Przywara <[email protected]>

---

Quoted 8 lines

<snip>

Andre,

I'm a little late to address this patchset, but the SBSA defines all the Generic UART registers 32-bit wide. However, the amba-pl011 driver uses 16-bit accessors. How will you be handling that? Can the ARM PL011 hardware handle 32-bit access?

Interesting question. The PL011 TRM [1] specifies only a 16-bit-wide APB bus interface, but does not say that 32-bit accesses won't work.

I suspect that 32-bit accesses will work on all or most PL011s -- if that looks too risky or we can't find enough test platforms to be sure of this, then we could maybe abstract the register access size as a quirk.

Andre may already have an answer on this.

Philip,

sorry for the late reply, that was stuck in my Drafts folder :-(

Quoted 1 line · Dave P Martin

On Tue, Feb 17, 2015 at 10:55:35AM -0500, Philip Elcan wrote:

Quoted 8 lines

Quoted 4 lines

I'm a little late to address this patchset, but the SBSA defines all the Generic UART registers 32-bit wide. However, the amba-pl011 driver uses 16-bit accessors. How will you be handling that? Can the ARM PL011 hardware handle 32-bit access?

Interesting question. The PL011 TRM [1] specifies only a 16-bit-wide APB bus interface, but does not say that 32-bit accesses won't work.

Quoted 6 lines

I suspect that 32-bit accesses will work on all or most PL011s -- if that looks too risky or we can't find enough test platforms to be sure of this, then we could maybe abstract the register access size as a quirk.

Andre may already have an answer on this.

I am not sure if the 32-bit register _width_ mentioned in the spec really mandates 32-bit accesses, also the width may be just a spec bug. Since the SBSA states that an ARM PL011r1p5 is a valid SBSA-UART implementation, I wonder how this goes together. Also the highest non-reserved bit in the registers is bit 15 in PL011 and bit 11 in the SBSA subset.

I fear the actual bus connection is an implementation detail. Given the fact that all existing PL011 hardware so far works with the 16bit accesses, I don't dare to change this.

So I'd suggest to keep it as readw/writew for now and the revisit this topic if some SBSA UART users complain. That makes it easier to justify the rather invasive change to all MMIO accessors (which I already tried on one machine for now without problems, btw).

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

Quoted 7 lines · On Friday 16 January 2015 17:22:56 Andre Przywara wrote:

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

Given that all other approaches that have been tried have failed, this seems like the best way forward. I don't know enough about the driver to do a detailed review, but all patches looked good to me as far as I could tell.

One question: How does the name space and minor number allocation work if you have both sbsa-uart and real pl011 in the same system? Do they share the ttyAMA name space without collisions?

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

Cheers,
Andre

[1] ARM-DEN-0029 Server Base System Architecture, available (click- thru...) from http://infocenter.arm.com
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315248.html
[3] http://www.linux-arm.org/git?p=linux-ap.git
git://linux-arm.org/linux-ap.git

Andre Przywara (10):
drivers: PL011: avoid potential unregister_driver call
drivers: PL011: refactor pl011_startup()
drivers: PL011: refactor pl011_shutdown()
drivers: PL011: refactor pl011_set_termios()
drivers: PL011: refactor pl011_probe()
drivers: PL011: replace UART_MIS reading with _RIS & _IMSC
drivers: PL011: move cts_event workaround into separate function
drivers: PL011: allow avoiding UART enabling/disabling
drivers: PL011: allow to supply fixed option string
drivers: PL011: add support for the ARM SBSA generic UART

 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 +
 drivers/tty/serial/amba-pl011.c                    |  510 ++++++++++++++------
 2 files changed, 381 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Signature · 7 lines

1.7.9.5


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 34 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

Quoted 4 lines

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

This occurs with both OE based FS from linaro and debian ubstable FS.

My FVP is version 5602

Graeme

Quoted 34 lines

Cheers,
Andre

[1] ARM-DEN-0029 Server Base System Architecture, available (click- thru...) from http://infocenter.arm.com
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315248.html
[3] http://www.linux-arm.org/git?p=linux-ap.git
git://linux-arm.org/linux-ap.git

Andre Przywara (10):
drivers: PL011: avoid potential unregister_driver call
drivers: PL011: refactor pl011_startup()
drivers: PL011: refactor pl011_shutdown()
drivers: PL011: refactor pl011_set_termios()
drivers: PL011: refactor pl011_probe()
drivers: PL011: replace UART_MIS reading with _RIS & _IMSC
drivers: PL011: move cts_event workaround into separate function
drivers: PL011: allow avoiding UART enabling/disabling
drivers: PL011: allow to supply fixed option string
drivers: PL011: add support for the ARM SBSA generic UART

 .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 +
 drivers/tty/serial/amba-pl011.c                    |  510 ++++++++++++++------
 2 files changed, 381 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt

Signature · 7 lines

1.7.9.5


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi Graeme,

Quoted 39 lines · Graeme Gregory

Quoted 34 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

Quoted 4 lines

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

Quoted 5 lines

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

Can you try to add:
-C bp.pl011_uart0.untimed_fifos=0
to your model command line? (given that your model supports this option)

We discovered that lately, also not sure how the default for this setting is handled these days in the various model versions.

We are about to investigate this here atm. This issue seems to be introduced by Dave's FIFO patch.

Quoted 55 lines · Andre Przywara

Hi Graeme,

Quoted 39 lines · Graeme Gregory

Quoted 34 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

Quoted 4 lines

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

Quoted 5 lines

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

Can you try to add:
-C bp.pl011_uart0.untimed_fifos=0
to your model command line? (given that your model supports this option)

We discovered that lately, also not sure how the default for this setting is handled these days in the various model versions.

Quoted 3 lines

We are about to investigate this here atm. This issue seems to be introduced by Dave's FIFO patch.

With this setting userspace functions better but loses characters fairly regularly.

Quoted 56 lines · Graeme Gregory

Quoted 55 lines · Andre Przywara

Hi Graeme,

Quoted 39 lines · Graeme Gregory

Quoted 34 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

Quoted 4 lines

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

Quoted 5 lines

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

Can you try to add:
-C bp.pl011_uart0.untimed_fifos=0
to your model command line? (given that your model supports this option)

We discovered that lately, also not sure how the default for this setting is handled these days in the various model versions.

Quoted 6 lines

Quoted 3 lines

We are about to investigate this here atm. This issue seems to be introduced by Dave's FIFO patch.

With this setting userspace functions better but loses characters fairly regularly.

Are you using arm,sbsa-uart in the DT, but a default PL011 in the model config? In my model the default PL011 version has a 16 byte FIFO only, specifying:
-C bp.pl011_uart0.revision="r1p5"
upgrades this to the SBSA specified 32 byte FIFO size.
With this setting I don't see any character loses.

Quoted 66 lines · Andre Przywara

Quoted 56 lines · Graeme Gregory

Quoted 55 lines · Andre Przywara

Hi Graeme,

Quoted 39 lines · Graeme Gregory

Quoted 34 lines · Andre Przywara

The ARM Server Base System Architecture[1] document describes a generic UART which is a subset of the PL011 UART.
It lacks DMA support, baud rate control and modem status line control, among other things.
The idea is to move the UART initialization and setup into the firmware (which does this job today already) and let the kernel just use the UART for sending and receiving characters.

This patchset integrates support for this UART subset into the existing PL011 driver - basically by refactoring some functions and providing a new uart_ops structure for it. It also has a separate probe function to be not dependent on AMBA/PrimeCell. It provides a device tree binding, but can easily be adapted to other device configuration systems.
Beside the obvious effect of code sharing reusing most of the PL011 code has the advantage of not introducing another serial device prefix, so it can go with ttyAMA, which seems to be pretty common.

This series relies on Dave's recent PL011 fix[2], which gets rid of the loopback trick to get the UART going. There is a repo at [3] (branch sbsa-uart/v1), which has this patch already integrated.

Patch 1/10 contains a bug fix which applies to the PL011 part also, it should be considered regardless of the rest of the series. Patch 2-7 refactor some PL011 functions by splitting them up into smaller pieces, so that most of the code can be reused later by the SBSA part.
Patch 8 and 9 introduce two new properties for the vendor structure, this is for SBSA functionality which cannot be controlled by separate uart_ops members only.
Patch 10 then finally drops in the SBSA specific code, by providing a new uart_ops, vendor struct and probe function for it. Also the new device tree binding is documented.

Quoted 4 lines

For testing you should be able to take any hardware which has a PL011 and change the DT to use a "arm,sbsa-uart" compatible string. Of course testing with a real SBSA Generic UART is welcomed!

Quoted 5 lines

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

Can you try to add:
-C bp.pl011_uart0.untimed_fifos=0
to your model command line? (given that your model supports this option)

We discovered that lately, also not sure how the default for this setting is handled these days in the various model versions.

Quoted 6 lines

Quoted 3 lines

We are about to investigate this here atm. This issue seems to be introduced by Dave's FIFO patch.

With this setting userspace functions better but loses characters fairly regularly.

Quoted 7 lines

Are you using arm,sbsa-uart in the DT, but a default PL011 in the model config? In my model the default PL011 version has a 16 byte FIFO only, specifying:
-C bp.pl011_uart0.revision="r1p5"
upgrades this to the SBSA specified 32 byte FIFO size.
With this setting I don't see any character loses.

Yes with this setting all works with untimed_fifos=0

I was not aware of the differences in versions thanks.

I have tested this series on Juno where it seems to work and also on FVP model where there are some issues.

On the FVP when we enter usespace a couple of 32 character strings are printed then nothing else. 32 Characters is a suspicious number.

This occurs with both OE based FS from linaro and debian ubstable FS.

My FVP is version 5602