| Message ID | 1460636003-3011-2-git-send-email-geert+renesas@glider.be |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Apr 14, 2016 at 02:13:19PM +0200, 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 <geert+renesas@glider.be> > --- > .../devicetree/bindings/serial/serial.txt | 61 ++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > create mode 100644 Documentation/devicetree/bindings/serial/serial.txt Thanks for doing this. Acked-by: Rob Herring <rob@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <geert+renesas@glider.be> 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? > - 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, CC Richard (serial-mctrl-gpio) CC Grant (ePAPR successor) and Frank On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: > 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 <geert+renesas@glider.be> > > 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. >> - 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. > 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@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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 18 April 2016 14:34:12 Geert Uytterhoeven wrote: > Hi Arnd, > > CC Richard (serial-mctrl-gpio) > CC Grant (ePAPR successor) and Frank > > On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > 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 <geert+renesas@glider.be> > > > > 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. I think both are still used by IBM Firmware, which does not use the clock binding or the linux syntax for passing the speed. > - 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. > - 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. Sounds ok to me. > >> - 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. 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>: > Hi Arnd, > > CC Richard (serial-mctrl-gpio) > CC Grant (ePAPR successor) and Frank > > On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> 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 <geert+renesas@glider.be> >> >> 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. > >>> - 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. 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; > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/18/2016 08:43 AM, Richard Genoud wrote: > 2016-04-18 14:34 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>: >> Hi Arnd, >> >> CC Richard (serial-mctrl-gpio) >> CC Grant (ePAPR successor) and Frank >> >> On Sat, Apr 16, 2016 at 6:30 PM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Thursday 14 April 2016 14:13:19 Geert Uytterhoeven wrote: [...] >>>> - 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 :) >> 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. Please leave the bit defs alone. >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/serial/serial.txt b/Documentation/devicetree/bindings/serial/serial.txt new file mode 100644 index 0000000000000000..21afdbd973b07a44 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/serial.txt @@ -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@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@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"; + };
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 <geert+renesas@glider.be> --- .../devicetree/bindings/serial/serial.txt | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/serial.txt