serial: Add Generic Serial Device Tree Bindings
cover serial: Add Generic Serial Device Tree Bindings
Hi all,
This patch series, against next-20160414, introduces Generic Serial Device Tree Bindings, and converts drivers using vendor-specific DT properties to the generic properies where appropriate.
The Generic Serial Device Tree Bindings document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.
Whether these generic properties apply to a particular device still depends on the DT bindings of the actual device.
The old (deprecated) vendor-specific properties are still supported by the drivers for backwards compatibility. Actual DTS files are to be updated later, after this series has been integrated into mainline.
Thanks for your comments!
Geert Uytterhoeven (5):
doc: DT: Add Generic Serial Device Tree Bindings
serial: imx: Use generic uart-has-rtscts DT property
serial: mxs-auart: Use generic uart-has-rtscts DT property
serial: sirf: Introduce helper variable struct device_node *np
serial: sirf: Use generic uart-has-rtscts DT property
.../devicetree/bindings/serial/fsl-imx-uart.txt | 4 +- .../devicetree/bindings/serial/fsl-mxs-auart.txt | 2 +- .../devicetree/bindings/serial/serial.txt | 61 ++++++++++++++++++++++ .../devicetree/bindings/serial/sirf-uart.txt | 8 +-- drivers/tty/serial/imx.c | 3 +- drivers/tty/serial/mxs-auart.c | 3 +- drivers/tty/serial/sirfsoc_uart.c | 39 +++++++------- 7 files changed, 91 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/serial.txt
Signature · 12 lines
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus TorvaldsPATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.
--- .../devicetree/bindings/serial/serial.txt | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/serial.txt
Documentation/devicetree/bindings/serial/serial.txt new file +61 -0
@@ -0,0 +1,61 @@ +Generic Serial DT Bindings + +This document lists a set of generic properties for describing UARTs in a +device tree. Whether these properties apply to a particular device depends on +the DT bindings for the actual device. + +Optional properties: + - cts-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's CTS line. + - dcd-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's DCD line. + - dsr-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's DSR line. + - dtr-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's DTR line. + - out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's OUT1 line. + - out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's OUT2 line. + - rng-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's RNG line. + - rts-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be + used as the UART's RTS line. + + - uart-has-rtscts: The presence of this property indicates that the + UART has dedicated lines for RTS/CTS hardware flow control, and that + they are available for use (wired and enabled by pinmux configuration). + This depends on both the UART hardware and the board wiring. + Note that this property is mutually-exclusive with "cts-gpios" and + "rts-gpios" above. + + +Examples: + + uart1: serial at 48022000 { + compatible = "ti,am3352-uart", "ti,omap3-uart"; + ti,hwmods = "uart2"; + clock-frequency = <48000000>; + reg = <0x48022000 0x2000>; + interrupts = <73>; + dmas = <&edma 28 0>, <&edma 29 0>; + dma-names = "tx", "rx"; + dtr-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>; + dsr-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>; + dcd-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>; + rng-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; + cts-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; + rts-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; + status = "okay"; + }; + + scifa4: serial at e6c80000 { + compatible = "renesas,scifa-sh73a0", "renesas,scifa"; + reg = <0xe6c80000 0x100>; + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>; + clock-names = "fck"; + power-domains = <&pd_a3sp>; + uart-has-rtscts; + status = "okay"; + };
Signature · 1 line
1.9.1
Rob Herring
maintainerPATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
Quoted 8 lines · Geert Uytterhoeven
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.
Quoted 5 lines
Signed-off-by Geert Uytterhoeven <[email protected]>--- .../devicetree/bindings/serial/serial.txt | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/serial.txt
Thanks for doing this.
PATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
In reply to Geert UytterhoevenQuoted 9 lines · On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.Signed-off-by Geert Uytterhoeven <[email protected]>
Originally the ISA 8250 uart binding (from ieee) was used as the template for other uart bindings. How about documenting the parts that are used in 8250-of today (current-speed, clock-frequency, reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control) in the same file?
Quoted 4 lines
- out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT1 line.
- out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT2 line.
I had to look up what OUT1 and OUT2 are, but I still don't see how you'd implement them using a GPIO line: From all I can tell, these are usually internal registers in a hardware uart but they are not assigned to an external line on the standard db9 or even the old db25 connectors. Should we drop these instead?
On a related note, do you think it would be possible to do a bit-banged uart if we defined gpio lines for rxd and txd?
Arnd
PATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
Hi Arnd,
CC Richard (serial-mctrl-gpio)
CC Grant (ePAPR successor) and Frank
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.
Quoted 7 lines
Quoted 1 line
Signed-off-by Geert Uytterhoeven <[email protected]>Originally the ISA 8250 uart binding (from ieee) was used as the template for other uart bindings. How about documenting the parts that are used in 8250-of today (current-speed, clock-frequency, reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control) in the same file?
I don't think we have the habit of documenting (duplicating) bindings for ePAPR under Documentation/devicetree/bindings/. Perhaps we should?
Apart from that, most of the properties you mention look legacy or overly broad too me.
- current-speed: This is configuration, not a property of the hardware. For the console, this has been deprecated by appending the serial config to chosen/stdout-path (e.g. "serial0:115200n8").
For non-consoles, its use is debatable, IMHO.
It's users are mostly legacy powerpc and early adaptors of DT on ARM.
- clock-frequency: Legacy predating the Common Clock Framework. Any modern SoC uses clock specifiers with clock handles pointing to clock providers.
- reg-offset, reg-shift, reg-io-width: These are much broader than serial, and IMHO thus don't belong in Documentation/devicetree/bindings/serial/serial.txt.
- auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts". Documentation/devicetree/bindings/serial/8250.txt doesn't make it clear whether this is about hardware capabilities or software configuration. Even the driver doesn't make it clear:
#define UART_CAP_AFE (1 << 11) /* MCR-based hw flow control */
"MCR" could mean RTS/CTS, DSR/DTR, ...
- fifo-size: This one could be generic. atmel-usart uses a vendor-specific version "atmel,fifo-size".
I suggest we move forward with my initial set, as I have patches that depend on them? We can always add more properties later.
Quoted 10 lines
Quoted 4 lines
- out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT1 line.
- out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT2 line.I had to look up what OUT1 and OUT2 are, but I still don't see how you'd implement them using a GPIO line: From all I can tell, these are usually internal registers in a hardware uart but they are not assigned to an external line on the standard db9 or even the old db25 connectors. Should we drop these instead?
They're indeed fairly exotic, and they're burried deeply in the ns16550 datasheet. We do have TIOCM_OUT1 and TIOCM_LOOP in asm-generic/termios.h, probably for obscure historical reasons.
If we drop them, I guess they should be removed from the helper code in drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any current users.
Quoted 2 lines
On a related note, do you think it would be possible to do a bit-banged uart if we defined gpio lines for rxd and txd?
Sure we can. Whether it would work well is another question ;-) Regardless of flow control, byte transmission and reception has hard real-time requirements due to the implicit clocking.
Bit-banging i2c and spi (master) is much easier, as clocking is explicit. Even i2c slave is easier, as the slave can stretch cycles.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
Quoted 29 lines · On Monday 18 April 2016 14:34:12 Geert Uytterhoeven wrote:
Hi Arnd,
CC Richard (serial-mctrl-gpio)
CC Grant (ePAPR successor) and FrankQuoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.Quoted 7 lines
Quoted 1 line
Signed-off-by Geert Uytterhoeven <[email protected]>Originally the ISA 8250 uart binding (from ieee) was used as the template for other uart bindings. How about documenting the parts that are used in 8250-of today (current-speed, clock-frequency, reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control) in the same file?
I don't think we have the habit of documenting (duplicating) bindings for ePAPR under
Documentation/devicetree/bindings/. Perhaps we should?Apart from that, most of the properties you mention look legacy or overly broad too me.
Quoted 8 lines
- current-speed: This is configuration, not a property of the hardware. For the console, this has been deprecated by appending the serial config to chosen/stdout-path (e.g. "serial0:115200n8").
For non-consoles, its use is debatable, IMHO.
It's users are mostly legacy powerpc and early adaptors of DT on ARM.
- clock-frequency: Legacy predating the Common Clock Framework. Any modern SoC uses clock specifiers with clock handles pointing to clock providers.
I think both are still used by IBM Firmware, which does not use the clock binding or the linux syntax for passing the speed.
Quoted 3 lines
- reg-offset, reg-shift, reg-io-width: These are much broader than serial, and IMHO thus don't belong in
Documentation/devicetree/bindings/serial/serial.txt.
The exact meaning can be explained elsewhere, but I think the binding can mention that they are allowed.
Quoted 11 lines
- auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts".
Documentation/devicetree/bindings/serial/8250.txtdoesn't make it clear whether this is about hardware capabilities or software configuration. Even the driver doesn't make it clear:
#defineUART_CAP_AFE(1 << 11) /* MCR-based hw flow control */
"MCR" could mean RTS/CTS, DSR/DTR, ...
- fifo-size: This one could be generic. atmel-usart uses a vendor-specific version "atmel,fifo-size".I suggest we move forward with my initial set, as I have patches that depend on them? We can always add more properties later.
Sounds ok to me.
Quoted 11 lines
Quoted 10 lines
Quoted 4 lines
- out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT1 line.
- out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT2 line.I had to look up what OUT1 and OUT2 are, but I still don't see how you'd implement them using a GPIO line: From all I can tell, these are usually internal registers in a hardware uart but they are not assigned to an external line on the standard db9 or even the old db25 connectors. Should we drop these instead?
Quoted 7 lines
They're indeed fairly exotic, and they're burried deeply in the ns16550 datasheet. We do have
TIOCM_OUT1andTIOCM_LOOPinasm-generic/termios.h, probably for obscure historical reasons.If we drop them, I guess they should be removed from the helper code in
drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any current users.
I think it makes sense for user space to toggle at least TIOCM_OUT1 through the ioctl and for drivers to implement it correctly. Apparently the "Hayes SmartModem" used this for resetting the modem from its integrated uart.
Arnd
PATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
In reply to Geert Uytterhoeven2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <[email protected]>:
Quoted 63 lines
Hi Arnd,
CC Richard (serial-mctrl-gpio)
CC Grant (ePAPR successor) and FrankQuoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
Document a set of generic properties for describing UARTs in a device tree:
1. The GPIO modem control properties are currently duplicated across hardware-specific binding documentation,
2. The property for dedicated RTS/CTS hardware flow control lines is already supported by several drivers, albeit with a vendor-specific prefix, hence make it generic.Quoted 7 lines
Quoted 1 line
Signed-off-by Geert Uytterhoeven <[email protected]>Originally the ISA 8250 uart binding (from ieee) was used as the template for other uart bindings. How about documenting the parts that are used in 8250-of today (current-speed, clock-frequency, reg-offset, reg-shift, fifo-size, reg-io-width, auto-flow-control) in the same file?
I don't think we have the habit of documenting (duplicating) bindings for ePAPR under
Documentation/devicetree/bindings/. Perhaps we should?Apart from that, most of the properties you mention look legacy or overly broad too me.
- current-speed: This is configuration, not a property of the hardware. For the console, this has been deprecated by appending the serial config to chosen/stdout-path (e.g. "serial0:115200n8").
For non-consoles, its use is debatable, IMHO.
It's users are mostly legacy powerpc and early adaptors of DT on ARM.
- clock-frequency: Legacy predating the Common Clock Framework. Any modern SoC uses clock specifiers with clock handles pointing to clock providers.
- reg-offset, reg-shift, reg-io-width: These are much broader than serial, and IMHO thus don't belong inDocumentation/devicetree/bindings/serial/serial.txt.
- auto-flow-control: Looks a bit like a vague version of "uart-has-rtscts".Documentation/devicetree/bindings/serial/8250.txtdoesn't make it clear whether this is about hardware capabilities or software configuration. Even the driver doesn't make it clear:
#defineUART_CAP_AFE(1 << 11) /* MCR-based hw flow control */
"MCR" could mean RTS/CTS, DSR/DTR, ...
- fifo-size: This one could be generic. atmel-usart uses a vendor-specific version "atmel,fifo-size".I suggest we move forward with my initial set, as I have patches that depend on them? We can always add more properties later.
Quoted 10 lines
Quoted 4 lines
- out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT1 line.
- out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT2 line.I had to look up what OUT1 and OUT2 are, but I still don't see how you'd implement them using a GPIO line: From all I can tell, these are usually internal registers in a hardware uart but they are not assigned to an external line on the standard db9 or even the old db25 connectors. Should we drop these instead?
Quoted 7 lines
They're indeed fairly exotic, and they're burried deeply in the ns16550 datasheet. We do have
TIOCM_OUT1andTIOCM_LOOPinasm-generic/termios.h, probably for obscure historical reasons.If we drop them, I guess they should be removed from the helper code in
drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any current users.
I must confess that I don't really know what TIOCM_OUT1&2 are for. (I implemented them for completeness)
But it seems that OUT2 is used in some drivers:drivers/tty/serial/omap-serial.c:
/*
* Most PC uarts need OUT2 raised to enable interrupts.
*/
up->port.mctrl |= TIOCM_OUT2;Quoted 9 lines
Quoted 3 lines
On a related note, do you think it would be possible to do a bit-banged uart if we defined gpio lines for rxd and txd?
Sure we can. Whether it would work well is another question ;-) Regardless of flow control, byte transmission and reception has hard real-time requirements due to the implicit clocking.
Bit-banging i2c and spi (master) is much easier, as clocking is explicit. Even i2c slave is easier, as the slave can stretch cycles.
+1
PATCH 1/5 doc: DT: Add Generic Serial Device Tree Bindings
Quoted 8 lines · Richard Genoud
2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <[email protected]>:
Quoted 7 lines
Hi Arnd,
CC Richard (serial-mctrl-gpio)
CC Grant (ePAPR successor) and FrankQuoted 1 line · Arnd Bergmann
On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote:
[...]
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
- out1-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT1 line.
- out2-gpios: Must contain a GPIO specifier, referring to the GPIO pin to be used as the UART's OUT2 line.I had to look up what OUT1 and OUT2 are, but I still don't see how you'd implement them using a GPIO line: From all I can tell, these are usually internal registers in a hardware uart but they are not assigned to an external line on the standard db9 or even the old db25 connectors. Should we drop these instead?
Yeah, not sure how those snuck in for gpios.
The original 8250/16550 uarts had OUT1 and OUT2 pins, and OUT1 could be used like gpio. That was 3 decades ago though so maybe we don't need to try to recreate that tech again :)
Quoted 3 lines
Quoted 3 lines
They're indeed fairly exotic, and they're burried deeply in the ns16550 datasheet. We do have
TIOCM_OUT1andTIOCM_LOOPinasm-generic/termios.h, probably for obscure historical reasons.
Please leave the bit defs alone.
Quoted 11 lines
Quoted 3 lines
If we drop them, I guess they should be removed from the helper code in
drivers/tty/serial/serial_mctrl_gpio.c, too? There don't seem to be any current users.I must confess that I don't really know what TIOCM_OUT1&2 are for. (I implemented them for completeness)
But it seems that OUT2 is used in some drivers:drivers/tty/serial/omap-serial.c:/* * Most PC uarts need OUT2 raised to enable interrupts. */ up->port.mctrl |= TIOCM_OUT2;
There's no need for OUT1 and OUT2 gpios; let's fix that.
Regards,
Peter Hurley
PATCH 2/5 serial: imx: Use generic uart-has-rtscts DT property
In reply to Geert UytterhoevenConvert the Freescale IMX UART driver from using the vendor-specific "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as documented by the Generic Serial DT Bindings.
The old vendor-specific property is still recognized by the driver for backwards compatibility, but deprecated.
--- Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 ++-- drivers/tty/serial/imx.c | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)
Documentation/devicetree/bindings/serial/fsl-imx-uart.txt +2 -2
@@ -6,7 +6,7 @@ Required properties: - interrupts : Should contain uart interrupt Optional properties: -- fsl,uart-has-rtscts : Indicate the uart has rts and cts +- uart-has-rtscts : Indicate the uart has rts and cts - fsl,irda-mode : Indicate the uart supports irda mode - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works in DCE mode by default.
@@ -24,6 +24,6 @@ uart1: serial at 73fbc000 { compatible = "fsl,imx51-uart", "fsl,imx21-uart"; reg = <0x73fbc000 0x4000>; interrupts = <31>; - fsl,uart-has-rtscts; + uart-has-rtscts; fsl,dte-mode; };
drivers/tty/serial/imx.c +2 -1
@@ -1927,7 +1927,8 @@ static int serial_imx_probe_dt(struct imx_port *sport, } sport->port.line = ret; -if (of_get_property (np,"fsl,uart-has-rtscts" ,NULL )) +if (of_get_property (np,"uart-has-rtscts" ,NULL ) || +of_get_property (np,"fsl,uart-has-rtscts" ,NULL )/* deprecated */ ) sport->have_rtscts =1 ;if (of_get_property (np,"fsl,dte-mode" ,NULL ))
Signature · 1 line
1.9.1
Rob Herring
maintainerPATCH 2/5 serial: imx: Use generic uart-has-rtscts DT property
Quoted 6 lines · Geert Uytterhoeven
Convert the Freescale IMX UART driver from using the vendor-specific "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as documented by the Generic Serial DT Bindings.
The old vendor-specific property is still recognized by the driver for backwards compatibility, but deprecated.
You should update the dts files as well.
Quoted 45 lines
Signed-off-by Geert Uytterhoeven <[email protected]>--- Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 4 ++-- drivers/tty/serial/imx.c | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)Documentation/devicetree/bindings/serial/fsl-imx-uart.txt +2
-2@@ -6,7 +6,7 @@ Required properties: - interrupts : Should contain uart interrupt Optional properties: -- fsl,uart-has-rtscts : Indicate the uart has rts and cts +- uart-has-rtscts : Indicate the uart has rts and cts - fsl,irda-mode : Indicate the uart supports irda mode - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works in DCE mode by default.@@ -24,6 +24,6 @@ uart1: serial at 73fbc000 { compatible = "fsl,imx51-uart", "fsl,imx21-uart"; reg = <0x73fbc000 0x4000>; interrupts = <31>; - fsl,uart-has-rtscts; + uart-has-rtscts; fsl,dte-mode; };drivers/tty/serial/imx.c +2
-1@@ -1927,7 +1927,8 @@ static int serial_imx_probe_dt(struct imx_port *sport, } sport->port.line = ret; -if (of_get_property (np,"fsl,uart-has-rtscts" ,NULL )) +if (of_get_property (np,"uart-has-rtscts" ,NULL ) || +of_get_property (np,"fsl,uart-has-rtscts" ,NULL )/* deprecated */ ) sport->have_rtscts =1 ;if (of_get_property (np,"fsl,dte-mode" ,NULL ))Signature · 1 line
1.9.1
PATCH 2/5 serial: imx: Use generic uart-has-rtscts DT property
Hi Rob,
Quoted 9 lines · Rob Herring
Quoted 6 lines · Geert Uytterhoeven
Convert the Freescale IMX UART driver from using the vendor-specific "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as documented by the Generic Serial DT Bindings.
The old vendor-specific property is still recognized by the driver for backwards compatibility, but deprecated.
You should update the dts files as well.
Indeed. But as I said in the cover letter:
"Actual DTS files are to be updated later, after this series has been
integrated into mainline."
DTS updates typically go through a different path (e.g. arm-soc). RTS/CTS support will be broken if the DTSes are updated before the drivers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH 3/5 serial: mxs-auart: Use generic uart-has-rtscts DT property
In reply to Geert UytterhoevenConvert the Freescale MXS AUART driver from using the vendor-specific "fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as documented by the Generic Serial DT Bindings.
The old vendor-specific property is still recognized by the driver for backwards compatibility, but it is deprecated.
--- Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt | 2 +- drivers/tty/serial/mxs-auart.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt +1 -1
@@ -11,7 +11,7 @@ Required properties: - dma-names: "rx" for RX channel, "tx" for TX channel. Optional properties: -- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines +- uart-has-rtscts : Indicate the UART has RTS and CTS lines for hardware flow control, it also means you enable the DMA support for this UART. - {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD
drivers/tty/serial/mxs-auart.c +2 -1
@@ -1185,7 +1185,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s, } s->port.line = ret; -if (of_get_property (np,"fsl,uart-has-rtscts" ,NULL )) +if (of_get_property (np,"uart-has-rtscts" ,NULL ) || +of_get_property (np,"fsl,uart-has-rtscts" ,NULL )/* deprecated */ )set_bit (MXS_AUART_RTSCTS , &s->flags);return 0 ;
Signature · 1 line
1.9.1
PATCH 4/5 serial: sirf: Introduce helper variable struct device_node *np
In reply to Geert Uytterhoeven--- drivers/tty/serial/sirfsoc_uart.c | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-)
drivers/tty/serial/sirfsoc_uart.c +18 -20
@@ -1264,6 +1264,7 @@ MODULE_DEVICE_TABLE(of, sirfsoc_uart_ids);static int sirfsoc_uart_probe (struct platform_device *pdev) { +struct device_node *np = pdev->dev.of_node;struct sirfsoc_uart_port *sirfport;struct uart_port *port;struct resource *res;
@@ -1276,13 +1277,13 @@ static int sirfsoc_uart_probe(struct platform_device *pdev) };const struct of_device_id *match; - match =of_match_node (sirfsoc_uart_ids, pdev->dev.of_node); + match =of_match_node (sirfsoc_uart_ids, np); sirfport =devm_kzalloc (&pdev->dev,sizeof (*sirfport),GFP_KERNEL );if (!sirfport) { ret = -ENOMEM ; goto err; } - sirfport->port.line =of_alias_get_id (pdev->dev.of_node,"serial" ); + sirfport->port.line =of_alias_get_id (np,"serial" ); sirf_ports[sirfport->port.line] = sirfport; sirfport->port.iotype =UPIO_MEM ; sirfport->port.flags =UPF_BOOT_AUTOCONF ;
@@ -1291,25 +1292,24 @@ static int sirfsoc_uart_probe(struct platform_device *pdev) port->private_data = sirfport; sirfport->uart_reg = (struct sirfsoc_uart_register *)match->data; - sirfport->hw_flow_ctrl =of_property_read_bool (pdev->dev.of_node, -"sirf,uart-has-rtscts" ); -if (of_device_is_compatible (pdev->dev.of_node,"sirf,prima2-uart" ) || -of_device_is_compatible (pdev->dev.of_node,"sirf,atlas7-uart" )) + sirfport->hw_flow_ctrl = +of_property_read_bool (np,"sirf,uart-has-rtscts" ); +if (of_device_is_compatible (np,"sirf,prima2-uart" ) || +of_device_is_compatible (np,"sirf,atlas7-uart" )) sirfport->uart_reg->uart_type =SIRF_REAL_UART ; -if (of_device_is_compatible (pdev->dev.of_node, -"sirf,prima2-usp-uart" ) ||of_device_is_compatible ( - pdev->dev.of_node,"sirf,atlas7-usp-uart" )) { +if (of_device_is_compatible (np,"sirf,prima2-usp-uart" ) || +of_device_is_compatible (np,"sirf,atlas7-usp-uart" )) { sirfport->uart_reg->uart_type =SIRF_USP_UART ;if (!sirfport->hw_flow_ctrl) goto usp_no_flow_control; -if (of_find_property (pdev->dev.of_node,"cts-gpios" ,NULL )) - sirfport->cts_gpio =of_get_named_gpio ( - pdev->dev.of_node,"cts-gpios" ,0 ); +if (of_find_property (np,"cts-gpios" ,NULL )) + sirfport->cts_gpio = +of_get_named_gpio (np,"cts-gpios" ,0 );else sirfport->cts_gpio =-1 ; -if (of_find_property (pdev->dev.of_node,"rts-gpios" ,NULL )) - sirfport->rts_gpio =of_get_named_gpio ( - pdev->dev.of_node,"rts-gpios" ,0 ); +if (of_find_property (np,"rts-gpios" ,NULL )) + sirfport->rts_gpio = +of_get_named_gpio (np,"rts-gpios" ,0 );else sirfport->rts_gpio =-1 ;
@@ -1336,13 +1336,11 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)gpio_direction_output (sirfport->rts_gpio,1 ); } usp_no_flow_control: -if (of_device_is_compatible (pdev->dev.of_node,"sirf,atlas7-uart" ) || -of_device_is_compatible (pdev->dev.of_node,"sirf,atlas7-usp-uart" )) +if (of_device_is_compatible (np,"sirf,atlas7-uart" ) || +of_device_is_compatible (np,"sirf,atlas7-usp-uart" )) sirfport->is_atlas7 = true; -if (of_property_read_u32 (pdev->dev.of_node, -"fifosize" , - &port->fifosize)) { +if (of_property_read_u32 (np,"fifosize" , &port->fifosize)) {dev_err (&pdev->dev,"Unable to find fifosize in uart node.\n" ); ret = -EFAULT ;
Signature · 1 line
1.9.1
PATCH 5/5 serial: sirf: Use generic uart-has-rtscts DT property
In reply to Geert UytterhoevenConvert the SiRF UART driver from using the vendor-specific "sirf,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as documented by the Generic Serial DT Bindings.
The old vendor-specific property is still recognized by the driver for backwards compatibility, but deprecated.
--- Documentation/devicetree/bindings/serial/sirf-uart.txt | 8 ++++---- drivers/tty/serial/sirfsoc_uart.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/serial/sirf-uart.txt +4 -4
@@ -9,9 +9,9 @@ Required properties: - clocks : Should contain uart clock number Optional properties: -- sirf,uart-has-rtscts: we have hardware flow controller pins in hardware -- rts-gpios: RTS pin for USP-based UART if sirf,uart-has-rtscts is true -- cts-gpios: CTS pin for USP-based UART if sirf,uart-has-rtscts is true +- uart-has-rtscts: we have hardware flow controller pins in hardware +- rts-gpios: RTS pin for USP-based UART if uart-has-rtscts is true +- cts-gpios: CTS pin for USP-based UART if uart-has-rtscts is true Example:
@@ -28,7 +28,7 @@ On the board-specific dts, we can put rts-gpios and cts-gpios like usp at b0090000 { compatible = "sirf,prima2-usp-uart"; - sirf,uart-has-rtscts; + uart-has-rtscts; rts-gpios = <&gpio 15 0>; cts-gpios = <&gpio 46 0>; };
drivers/tty/serial/sirfsoc_uart.c +2 -1
@@ -1293,7 +1293,8 @@ static int sirfsoc_uart_probe(struct platform_device *pdev) sirfport->uart_reg = (struct sirfsoc_uart_register *)match->data; sirfport->hw_flow_ctrl = -of_property_read_bool (np,"sirf,uart-has-rtscts" ); +of_property_read_bool (np,"uart-has-rtscts" ) || +of_property_read_bool (np,"sirf,uart-has-rtscts" )/* deprecated */ ;if (of_device_is_compatible (np,"sirf,prima2-uart" ) ||of_device_is_compatible (np,"sirf,atlas7-uart" )) sirfport->uart_reg->uart_type =SIRF_REAL_UART ;
Signature · 1 line
1.9.1