Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1464881 > unrolled thread
| Started by | Rob Herring <robh@kernel.org> |
|---|---|
| First post | 2016-08-18 03:20 +0200 |
| Last post | 2016-08-23 23:20 +0200 |
| Articles | 20 on this page of 96 — 10 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 03:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 12:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 12:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 16:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-18 15:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 12:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 12:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-08-18 13:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 14:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 15:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-18 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-18 14:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-18 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-18 15:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-19 03:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-18 16:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 03:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 04:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 17:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 03:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-19 03:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 07:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 09:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 20:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Oleksij Rempel <linux@rempel-privat.de> - 2016-08-19 22:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-22 23:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 23:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-23 09:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-19 19:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-20 15:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 10:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-21 19:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-08-21 20:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 11:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 11:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-19 13:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-19 16:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 14:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 15:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 17:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 17:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Arnd Bergmann <arnd@arndb.de> - 2016-08-22 18:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 18:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 23:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Pavel Machek <pavel@ucw.cz> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 02:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 02:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 03:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-24 16:00 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-24 16:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-23 13:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-22 19:40 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-22 22:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-22 19:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Marcel Holtmann <marcel@holtmann.org> - 2016-08-22 23:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 00:10 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 01:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Sebastian Reichel <sre@kernel.org> - 2016-08-23 01:50 +0200
Re: [RFC PATCH 0/3] UART slave device bus One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-08-23 00:20 +0200
Re: [RFC PATCH 0/3] UART slave device bus Linus Walleij <linus.walleij@linaro.org> - 2016-08-24 14:30 +0200
Re: [RFC PATCH 0/3] UART slave device bus Rob Herring <robh@kernel.org> - 2016-08-23 23:20 +0200
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-18 03:20 +0200 |
| Subject | [RFC PATCH 0/3] UART slave device bus |
| Message-ID | <s7k9X-TX-3@gated-at.bofh.it> |
Currently, devices attached via a UART are not well supported in the kernel. The problem is the device support is done in tty line disciplines, various platform drivers to handle some sideband, and in userspace with utilities such as hciattach. There have been several attempts to improve support, but they suffer from still being tied into the tty layer and/or abusing the platform bus. This is a prototype to show creating a proper UART bus for UART devices. It is tied into the serial core (really struct uart_port) below the tty layer in order to use existing serial drivers. This is functional with minimal testing using the loopback driver and pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave device). It still needs lots of work and polish. TODOs: - Figure out the port locking. mutex plus spinlock plus refcounting? I'm hoping all that complexity is from the tty layer and not needed here. - Split out the controller for uart_ports into separate driver. Do we see a need for controller drivers that are not standard serial drivers? - Implement/test the removal paths - Fix the receive callbacks for more than character at a time (i.e. DMA) - Need better receive buffering than just a simple circular buffer or perhaps a different receive interface (e.g. direct to client buffer)? - Test with other UART drivers - Convert a real driver/line discipline over to UART bus. Before I spend more time on this, I'm looking mainly for feedback on the general direction and structure (the interface with the existing serial drivers in particular). Rob Rob Herring (3): uart bus: Introduce new bus for UART slave devices tty: serial_core: make tty_struct optional tty: serial_core: add uart controller registration drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/tty/serial/serial_core.c | 11 +- drivers/tty/tty_buffer.c | 2 + drivers/uart/Kconfig | 17 ++ drivers/uart/Makefile | 3 + drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ drivers/uart/loopback.c | 72 ++++++ include/linux/serial_core.h | 3 +- include/linux/uart_device.h | 163 ++++++++++++++ 10 files changed, 730 insertions(+), 2 deletions(-) create mode 100644 drivers/uart/Kconfig create mode 100644 drivers/uart/Makefile create mode 100644 drivers/uart/core.c create mode 100644 drivers/uart/loopback.c create mode 100644 include/linux/uart_device.h -- 2.9.2
[toc] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-08-18 12:30 +0200 |
| Message-ID | <s7sKd-6Ri-19@gated-at.bofh.it> |
| In reply to | #1464881 |
On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote: > Currently, devices attached via a UART are not well supported in the > kernel. The problem is the device support is done in tty line disciplines, > various platform drivers to handle some sideband, and in userspace with > utilities such as hciattach. > > There have been several attempts to improve support, but they suffer from > still being tied into the tty layer and/or abusing the platform bus. This > is a prototype to show creating a proper UART bus for UART devices. It is > tied into the serial core (really struct uart_port) below the tty layer > in order to use existing serial drivers. > > This is functional with minimal testing using the loopback driver and > pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave > device). It still needs lots of work and polish. > > TODOs: > - Figure out the port locking. mutex plus spinlock plus refcounting? I'm > hoping all that complexity is from the tty layer and not needed here. It should be. > - Split out the controller for uart_ports into separate driver. Do we see > a need for controller drivers that are not standard serial drivers? What do you mean by "controller" drivers here? I didn't understand them in the code. > - Implement/test the removal paths > - Fix the receive callbacks for more than character at a time (i.e. DMA) > - Need better receive buffering than just a simple circular buffer or > perhaps a different receive interface (e.g. direct to client buffer)? Why? Is the code as-is slow? > - Test with other UART drivers > - Convert a real driver/line discipline over to UART bus. That's going to be the real test, I recommend trying that as soon as possible as it will show where the real pain points are :) > Before I spend more time on this, I'm looking mainly for feedback on the > general direction and structure (the interface with the existing serial > drivers in particular). Yes, I like the idea (minor nit, you still have SPMI in a lot of places instead of UART), so I recommend keeping going with it. > drivers/uart/Kconfig | 17 ++ > drivers/uart/Makefile | 3 + > drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ > drivers/uart/loopback.c | 72 ++++++ Why not just put this in drivers/tty/uart/ ? thanks, greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-18 12:40 +0200 |
| Message-ID | <s7sTT-6Vc-3@gated-at.bofh.it> |
| In reply to | #1465113 |
Hi Greg, >> Currently, devices attached via a UART are not well supported in the >> kernel. The problem is the device support is done in tty line disciplines, >> various platform drivers to handle some sideband, and in userspace with >> utilities such as hciattach. >> >> There have been several attempts to improve support, but they suffer from >> still being tied into the tty layer and/or abusing the platform bus. This >> is a prototype to show creating a proper UART bus for UART devices. It is >> tied into the serial core (really struct uart_port) below the tty layer >> in order to use existing serial drivers. >> >> This is functional with minimal testing using the loopback driver and >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >> device). It still needs lots of work and polish. >> >> TODOs: >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >> hoping all that complexity is from the tty layer and not needed here. > > It should be. > >> - Split out the controller for uart_ports into separate driver. Do we see >> a need for controller drivers that are not standard serial drivers? > > What do you mean by "controller" drivers here? I didn't understand them > in the code. > >> - Implement/test the removal paths >> - Fix the receive callbacks for more than character at a time (i.e. DMA) >> - Need better receive buffering than just a simple circular buffer or >> perhaps a different receive interface (e.g. direct to client buffer)? > > Why? Is the code as-is slow? > >> - Test with other UART drivers >> - Convert a real driver/line discipline over to UART bus. > > That's going to be the real test, I recommend trying that as soon as > possible as it will show where the real pain points are :) maybe we can get the Intel LnP driver ported over and see how that one works out. It is one of the more complex ones when it comes to bootloader and firmware loading. Maybe Loic can take a stab at this. We would then also see how we can map the ACPI tables into a driver. >> Before I spend more time on this, I'm looking mainly for feedback on the >> general direction and structure (the interface with the existing serial >> drivers in particular). > > Yes, I like the idea (minor nit, you still have SPMI in a lot of places > instead of UART), so I recommend keeping going with it. > >> drivers/uart/Kconfig | 17 ++ >> drivers/uart/Makefile | 3 + >> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ >> drivers/uart/loopback.c | 72 ++++++ > > Why not just put this in drivers/tty/uart/ ? Is it really then a TTY at all. Would be the UART become the basic core for a TTY? Having tty/uart/ seems a bit backward. Then again, it is just a directory name ;) Regards Marcel
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-08-18 13:00 +0200 |
| Message-ID | <s7tdg-75c-15@gated-at.bofh.it> |
| In reply to | #1465115 |
On Thu, Aug 18, 2016 at 12:30:32PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >> Currently, devices attached via a UART are not well supported in the > >> kernel. The problem is the device support is done in tty line disciplines, > >> various platform drivers to handle some sideband, and in userspace with > >> utilities such as hciattach. > >> > >> There have been several attempts to improve support, but they suffer from > >> still being tied into the tty layer and/or abusing the platform bus. This > >> is a prototype to show creating a proper UART bus for UART devices. It is > >> tied into the serial core (really struct uart_port) below the tty layer > >> in order to use existing serial drivers. > >> > >> This is functional with minimal testing using the loopback driver and > >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave > >> device). It still needs lots of work and polish. > >> > >> TODOs: > >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm > >> hoping all that complexity is from the tty layer and not needed here. > > > > It should be. > > > >> - Split out the controller for uart_ports into separate driver. Do we see > >> a need for controller drivers that are not standard serial drivers? > > > > What do you mean by "controller" drivers here? I didn't understand them > > in the code. > > > >> - Implement/test the removal paths > >> - Fix the receive callbacks for more than character at a time (i.e. DMA) > >> - Need better receive buffering than just a simple circular buffer or > >> perhaps a different receive interface (e.g. direct to client buffer)? > > > > Why? Is the code as-is slow? > > > >> - Test with other UART drivers > >> - Convert a real driver/line discipline over to UART bus. > > > > That's going to be the real test, I recommend trying that as soon as > > possible as it will show where the real pain points are :) > > maybe we can get the Intel LnP driver ported over and see how that one > works out. It is one of the more complex ones when it comes to > bootloader and firmware loading. Maybe Loic can take a stab at this. > We would then also see how we can map the ACPI tables into a driver. Yes, I was going to complain about the OF-only bent of this patch, but I figured it would get fixed up once Rob started to use a "real" machine for his testing of this code :) > >> Before I spend more time on this, I'm looking mainly for feedback on the > >> general direction and structure (the interface with the existing serial > >> drivers in particular). > > > > Yes, I like the idea (minor nit, you still have SPMI in a lot of places > > instead of UART), so I recommend keeping going with it. > > > >> drivers/uart/Kconfig | 17 ++ > >> drivers/uart/Makefile | 3 + > >> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ > >> drivers/uart/loopback.c | 72 ++++++ > > > > Why not just put this in drivers/tty/uart/ ? > > Is it really then a TTY at all. Would be the UART become the basic > core for a TTY? Hm, interesting idea. Not for all TTYs of course, but for those that are on UART devices, maybe? How would a usb-serial device fit into that picture? > Having tty/uart/ seems a bit backward. Then again, it is just a > directory name ;) And as we know, naming is hard :) thanks, greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-18 16:00 +0200 |
| Message-ID | <s7w1t-vD-65@gated-at.bofh.it> |
| In reply to | #1465132 |
On Thu, Aug 18, 2016 at 5:53 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Aug 18, 2016 at 12:30:32PM +0200, Marcel Holtmann wrote: >> Hi Greg, >> >> >> Currently, devices attached via a UART are not well supported in the >> >> kernel. The problem is the device support is done in tty line disciplines, >> >> various platform drivers to handle some sideband, and in userspace with >> >> utilities such as hciattach. >> >> >> >> There have been several attempts to improve support, but they suffer from >> >> still being tied into the tty layer and/or abusing the platform bus. This >> >> is a prototype to show creating a proper UART bus for UART devices. It is >> >> tied into the serial core (really struct uart_port) below the tty layer >> >> in order to use existing serial drivers. >> >> >> >> This is functional with minimal testing using the loopback driver and >> >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >> >> device). It still needs lots of work and polish. >> >> >> >> TODOs: >> >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >> >> hoping all that complexity is from the tty layer and not needed here. >> > >> > It should be. >> > >> >> - Split out the controller for uart_ports into separate driver. Do we see >> >> a need for controller drivers that are not standard serial drivers? >> > >> > What do you mean by "controller" drivers here? I didn't understand them >> > in the code. >> > >> >> - Implement/test the removal paths >> >> - Fix the receive callbacks for more than character at a time (i.e. DMA) >> >> - Need better receive buffering than just a simple circular buffer or >> >> perhaps a different receive interface (e.g. direct to client buffer)? >> > >> > Why? Is the code as-is slow? >> > >> >> - Test with other UART drivers >> >> - Convert a real driver/line discipline over to UART bus. >> > >> > That's going to be the real test, I recommend trying that as soon as >> > possible as it will show where the real pain points are :) >> >> maybe we can get the Intel LnP driver ported over and see how that one >> works out. It is one of the more complex ones when it comes to >> bootloader and firmware loading. Maybe Loic can take a stab at this. >> We would then also see how we can map the ACPI tables into a driver. > > Yes, I was going to complain about the OF-only bent of this patch, but I > figured it would get fixed up once Rob started to use a "real" machine > for his testing of this code :) I fully expected that from you. :) It is no different than any other bus we have. Each discovery/enumeration method needs hooks for matching and creating devices. It just happens that DT is the only one added ATM. > >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> >> general direction and structure (the interface with the existing serial >> >> drivers in particular). >> > >> > Yes, I like the idea (minor nit, you still have SPMI in a lot of places >> > instead of UART), so I recommend keeping going with it. >> > >> >> drivers/uart/Kconfig | 17 ++ >> >> drivers/uart/Makefile | 3 + >> >> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ >> >> drivers/uart/loopback.c | 72 ++++++ >> > >> > Why not just put this in drivers/tty/uart/ ? >> >> Is it really then a TTY at all. Would be the UART become the basic >> core for a TTY? > > Hm, interesting idea. Not for all TTYs of course, but for those that > are on UART devices, maybe? How would a usb-serial device fit into that > picture? DT overlay. Just like greybus serial. :) That's a good question though as usb-serial doesn't use uart_port. Perhaps there needs to be a uart controller/host driver that's a line discipline so existing tty drivers can work. That somewhat defeats the point of getting line disciplines out of the picture, but would provide a solution for h/w hacking (and no worse than what can be supported today). Longer term, the drivers would need to be adapted to use the uart slave bus directly. Rob
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-18 15:20 +0200 |
| Message-ID | <s7voL-ho-51@gated-at.bofh.it> |
| In reply to | #1465113 |
On Thu, Aug 18, 2016 at 5:22 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote: >> Currently, devices attached via a UART are not well supported in the >> kernel. The problem is the device support is done in tty line disciplines, >> various platform drivers to handle some sideband, and in userspace with >> utilities such as hciattach. >> >> There have been several attempts to improve support, but they suffer from >> still being tied into the tty layer and/or abusing the platform bus. This >> is a prototype to show creating a proper UART bus for UART devices. It is >> tied into the serial core (really struct uart_port) below the tty layer >> in order to use existing serial drivers. >> >> This is functional with minimal testing using the loopback driver and >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >> device). It still needs lots of work and polish. >> >> TODOs: >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >> hoping all that complexity is from the tty layer and not needed here. > > It should be. > >> - Split out the controller for uart_ports into separate driver. Do we see >> a need for controller drivers that are not standard serial drivers? > > What do you mean by "controller" drivers here? I didn't understand them > in the code. The host uart driver. It's basically a wrapper around struct uart_port, but may need to evolve to have its own ops if we want to make using struct uart_port for driver. Maybe host would be a better name. >> - Implement/test the removal paths >> - Fix the receive callbacks for more than character at a time (i.e. DMA) >> - Need better receive buffering than just a simple circular buffer or >> perhaps a different receive interface (e.g. direct to client buffer)? > > Why? Is the code as-is slow? No, the code should be fast as it is so simple. I assume there is some reason the tty buffering is more complex than just a circular buffer. My best guess is because the tty layer has to buffer things for userspace and userspace can be slow to read? Do line disciplines make assumptions about the tty buffering? Is 4KB enough buffering? Also, the current receive implementation has no concept of blocking or timeout. Should the uart_dev_rx() function return when there's no more data or wait (with timeout) until all requested data is received? (Probably do all of them is my guess). > >> - Test with other UART drivers >> - Convert a real driver/line discipline over to UART bus. > > That's going to be the real test, I recommend trying that as soon as > possible as it will show where the real pain points are :) > >> Before I spend more time on this, I'm looking mainly for feedback on the >> general direction and structure (the interface with the existing serial >> drivers in particular). > > Yes, I like the idea (minor nit, you still have SPMI in a lot of places > instead of UART), so I recommend keeping going with it. > >> drivers/uart/Kconfig | 17 ++ >> drivers/uart/Makefile | 3 + >> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++ >> drivers/uart/loopback.c | 72 ++++++ > > Why not just put this in drivers/tty/uart/ ? Because it has nothing to do with the tty layer. If anything, I think the direction would be move drivers/tty/serial/ to drivers/uart/ (didn't they used to be in drivers/serial/? :)) i'm not proposing we do that though. Rob
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-19 03:50 +0200 |
| Message-ID | <s7H6x-7vO-27@gated-at.bofh.it> |
| In reply to | #1465290 |
On Thu, Aug 18, 2016 at 10:04 AM, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote: >> No, the code should be fast as it is so simple. I assume there is some >> reason the tty buffering is more complex than just a circular buffer. > > I would suggest you read n_tty.c carefully and then it'll make a fair bit > of sense. It has to interlock multiple reader/writes with discipline > changes and flushes of pending data. At the same time a received > character may cause output changes including bytes to be queued for > transmit and the entire lot must not excessively recurse. > > It's fun and it took years to make work safely but basically you need to > handle a simultaneous ldisc change, config change, read of data from the > buffers, receive, transmit and the receive causing the transmit status to > change and maybe other transmits, that might have to be sent with > priority. It's fun 8) > > The good news is that nobody but n_tty and maybe n_irda cares on the rx > side. Every other ldisc consumes the bytes immediately. IRDA hasn't worked > for years anyway. > >> My best guess is because the tty layer has to buffer things for >> userspace and userspace can be slow to read? Do line disciplines make >> assumptions about the tty buffering? Is 4KB enough buffering? > > RTFS but to save you a bit of effort > > 1. 4K is not enough, 64K is not always sufficient, this is why we have > all the functionality you appear to want to re-invent already in the tty > buffer logic of the tty_port I don't want to reinvent it which is why I'm asking. > 2. Only n_tty actually uses the tty_port layer buffering So the first point on 4K is not enough only applies to n_tty? If I don't need the tty_port buffer logic, then how am I re-inventing it? > 3. The ring buffer used for dumb uarts is entirely about latency limits > on low end processors and only used by some uarts anyway. > >> Also, the current receive implementation has no concept of blocking or >> timeout. Should the uart_dev_rx() function return when there's no more >> data or wait (with timeout) until all requested data is received? >> (Probably do all of them is my guess). > > Your rx routine needs to be able to run in IRQ context, not block and > complete in very very short time scales because on some hardware you have > exactly 9 bit times to recover the data byte and clear the IRQ done. > Serial really stretches some of the low end embedded processors running > at 56K/115200, and RS485 at 4Mbits even with 8 bytes of buffering is > pretty tight. Thus you need very fast buffers for just about any use case. > Dumb uarts you'll need to keep the existing ring buffer or similar > (moving to a kfifo would slightly improve performance I think) and queue > after. > >> >> - Convert a real driver/line discipline over to UART bus. >> > >> > That's going to be the real test, I recommend trying that as soon as >> > possible as it will show where the real pain points are :) > > The locking. It's taken ten years to debug the current line discipline > change locking. If you want to be able to switch stuff kernel side > however it's somewhat easier. > > The change should be > > Add tty_port->rx(uint8_t *data,uint8_t *flags, unsigned int len) > > The semantics of tty_port->rx are > > - You may not assume a tty is bound to this port > - You may be called in IRQ context, but are guaranteed not to get > parallel calls for the same port > - When you return the bytes you passed are history > > At that point you can set tty_port->rx to point to the > tty_flip_buffer_push() and everyone can use it. Slow ones will want to > queue to a ring buffer then do tty_port->rx (where we do the flush_buffer > now), fast ones will do the ->rx directly. I think I understand this for rx, but let's back-up to the registration and transmit paths. tty_port and uart_port have nothing in common other than name, and tty_port has nothing to do with i/o. So we still need tty_operations which all take a tty_struct and implies a tty_driver. It seems to me we would need surgery all over the tty code to make chardev, ldisc and anything else I'm not aware of optional. Rob
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-19 13:10 +0200 |
| Message-ID | <s7PQu-4Rb-13@gated-at.bofh.it> |
| In reply to | #1465842 |
> > 2. Only n_tty actually uses the tty_port layer buffering > > So the first point on 4K is not enough only applies to n_tty? If I > don't need the tty_port buffer logic, then how am I re-inventing it? There are two layers of buffering. 1. Some devices buffer bytes into an internal ring buffer in the uart layer and then kick a handler to push them into the tty layer separately to the IRQ. For dumb uarts that is pretty much unavoidable. At high speed you don't have time to do processing. 2. The majority of drivers use the tty_buffer.c buffering alone. Quite a few that use the #1 above could in fact just use this today but for historical reasons don't. The buffering needed to meet latency needs to be sufficient for the hardware and is always needed on devices that have that problem. The rest of the buffering functionality is in fact ultimately only used by n_tty because every other ldisc implements the receive function as alloc something copy the data queue to somewhere return > > At that point you can set tty_port->rx to point to the > > tty_flip_buffer_push() and everyone can use it. Slow ones will want to > > queue to a ring buffer then do tty_port->rx (where we do the flush_buffer > > now), fast ones will do the ->rx directly. > > I think I understand this for rx, but let's back-up to the > registration and transmit paths. tty_port and uart_port have nothing > in common other than name, and tty_port has nothing to do with i/o. So Yes they do - every uart has a tty_port. > we still need tty_operations which all take a tty_struct and implies a > tty_driver. It seems to me we would need surgery all over the tty code > to make chardev, ldisc and anything else I'm not aware of optional. Very little today *needs* a tty attached. The callbacks already handle the no tty case (because they can be called asynchronously to a tty closing) The open and close are doable directly, and it is deliberate and ready for this kind of use that we have port->ops->activate, tty_port_set_initialized() and tty_port_shutdown() so just need to add a couple of abstracted out bits of code to give us tty_port_activate(); tty_port_shutdown(); as the pair of methods needed for non tty enabling/disabling of the port Right now you need tty for transmission because tty manages the outbound queueing, and for termios changes. Termios is historically attached to the tty structure and the fact tty->ops->set_termio[sx] exists in tty-> is just a historical quirk. They can just move. The writing part is slightly harder to untangle. The tty->ops->write() passes a tty and there are three ways that gets used 1. tty->driver_data to get the underlying device object. That can easily be moved to port->driver_data 2. access to flow control state tty->stopped and tty->hw_stopped. Again these can migrate along with the termios bits that are rferenced 3. Calling back to do wakeups, throttle and unthrottle These again could be migrated to the port, and whatever port writing method you implement will anyway have to implement this simply because you have to do flow control and in some cases flow control is pure software. The transmit side is the hardest part by far but the infrastructure is there, and already handles the nasty cases you'll have to deal with like a transmit being triggered from a receive. Alan
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-18 12:40 +0200 |
| Message-ID | <s7sTT-6Vc-5@gated-at.bofh.it> |
| In reply to | #1464881 |
Hi Rob,
many thanks for picking up this unsolved topic!
> Am 18.08.2016 um 03:14 schrieb Rob Herring <robh@kernel.org>:
>
> Currently, devices attached via a UART are not well supported in the
> kernel. The problem is the device support is done in tty line disciplines,
> various platform drivers to handle some sideband, and in userspace with
> utilities such as hciattach.
>
> There have been several attempts to improve support, but they suffer from
> still being tied into the tty layer and/or abusing the platform bus. This
> is a prototype to show creating a proper UART bus for UART devices. It is
> tied into the serial core (really struct uart_port) below the tty layer
> in order to use existing serial drivers.
>
> This is functional with minimal testing using the loopback driver and
> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave
> device). It still needs lots of work and polish.
>
> TODOs:
> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm
> hoping all that complexity is from the tty layer and not needed here.
> - Split out the controller for uart_ports into separate driver. Do we see
> a need for controller drivers that are not standard serial drivers?
> - Implement/test the removal paths
> - Fix the receive callbacks for more than character at a time (i.e. DMA)
> - Need better receive buffering than just a simple circular buffer or
> perhaps a different receive interface (e.g. direct to client buffer)?
> - Test with other UART drivers
> - Convert a real driver/line discipline over to UART bus.
>
> Before I spend more time on this, I'm looking mainly for feedback on the
> general direction and structure (the interface with the existing serial
> drivers in particular).
Some quick comments (can't do any real life tests in the next weeks) from my (biased) view:
* tieing the solution into uart_port is the same as we had done. The difference seems to
me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation.
We have tapped the tty layer only because it can not be 100% avoided if we use serial_core.
* one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that.
* what I don't see is how we can implement our GPS device power control driver:
- the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should
not be completely hidden from user space or represented by a new interface type invented just for this device
(while the majority of other GPS receivers are still simple tty devices).
- how we can detect that the device is sending data to the UART while no user space process has the uart port open
i.e. when does the driver know when to start/stop the UART.
* I like that a driver can simply call uart_dev_config(udev, 115200, 'n', 8, 0); instead of our
uart_register_rx_notification(data->uart, rx_notification, &termios); where we have to partially
fill the termios structure.
* it appears to need more code than our proposal did:
>
> Rob
>
>
> Rob Herring (3):
> uart bus: Introduce new bus for UART slave devices
> tty: serial_core: make tty_struct optional
> tty: serial_core: add uart controller registration
>
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/tty/serial/serial_core.c | 11 +-
> drivers/tty/tty_buffer.c | 2 +
> drivers/uart/Kconfig | 17 ++
> drivers/uart/Makefile | 3 +
> drivers/uart/core.c | 458 +++++++++++++++++++++++++++++++++++++++
> drivers/uart/loopback.c | 72 ++++++
> include/linux/serial_core.h | 3 +-
> include/linux/uart_device.h | 163 ++++++++++++++
> 10 files changed, 730 insertions(+), 2 deletions(-)
> create mode 100644 drivers/uart/Kconfig
> create mode 100644 drivers/uart/Makefile
> create mode 100644 drivers/uart/core.c
> create mode 100644 drivers/uart/loopback.c
> create mode 100644 include/linux/uart_device.h
thereof 9 files, ~650 changes w/o loopback demo
vs.
> On 10/16/2015 11:08 AM, H. Nikolaus Schaller wrote:
>> H. Nikolaus Schaller (3):
>> tty: serial core: provide a method to search uart by phandle
>> tty: serial_core: add hooks for uart slave drivers
>> misc: Add w2sg0004 gps receiver driver
>>
>> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt | 18 +
>> .../devicetree/bindings/serial/slaves.txt | 16 +
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> Documentation/serial/slaves.txt | 36 ++
>> drivers/misc/Kconfig | 18 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/w2sg0004.c | 443 +++++++++++++++++++++
>> drivers/tty/serial/serial_core.c | 214 +++++++++-
>> include/linux/serial_core.h | 25 +-
>> include/linux/w2sg0004.h | 27 ++
>> 10 files changed, 793 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
>> create mode 100644 Documentation/serial/slaves.txt
>> create mode 100644 drivers/misc/w2sg0004.c
>> create mode 100644 include/linux/w2sg0004.h
Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
BR and thanks,
Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-08-18 12:50 +0200 |
| Message-ID | <s7t3z-6Zk-7@gated-at.bofh.it> |
| In reply to | #1465116 |
> > Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. So what do you use for the serial devices? platform_device was vetoed for that purpose by Greg. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-08-18 13:00 +0200 |
| Message-ID | <s7tdg-75c-31@gated-at.bofh.it> |
| In reply to | #1465119 |
On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote: > Hi Pavel, > > > Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@ucw.cz>: > > > > > >> > >> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. > > > > So what do you use for the serial devices? platform_device was vetoed > > for that purpose by Greg. > > device tree? No. This patchset from Rob is the way I have been saying it should be done for years now. Yes, a "bus" takes up more boilerplate code (blame me for that), but overall, it makes the drivers simpler, and fits into the rest of the kernel driver/device model much better. greg k-h
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-18 13:20 +0200 |
| Message-ID | <s7twB-7tk-13@gated-at.bofh.it> |
| In reply to | #1465142 |
Hi Greg, > Am 18.08.2016 um 12:57 schrieb Greg Kroah-Hartman <gregkh@linuxfoundation.org>: > > On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote: >> Hi Pavel, >> >>> Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@ucw.cz>: >>> >>> >>>> >>>> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. >>> >>> So what do you use for the serial devices? platform_device was vetoed >>> for that purpose by Greg. >> >> device tree? > > No. ? Sorry, but each time Pavel jumps in, he just copies half of a statement and any reply gets misunderstood. I did not even mention platform_device, still you disagree to device tree for the *slave driver*? > > This patchset from Rob is the way I have been saying it should be done > for years now. Yes, a "bus" takes up more boilerplate code (blame me > for that), but overall, it makes the drivers simpler, Sorry, but I don't see how Rob's approach makes it simpler to write a device driver than our original proposal, which btw is also sort of a bus and I see only some implementation differences. Except that IMHO Rob's approach lacks functions we need (which maybe can added). > and fits into the > rest of the kernel driver/device model much better. BR and thanks, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-18 16:50 +0200 |
| Message-ID | <s7wNR-16E-73@gated-at.bofh.it> |
| In reply to | #1465142 |
On Thu, 18 Aug 2016 12:57:59 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote: > > Hi Pavel, > > > > > Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@ucw.cz>: > > > > > > > > >> > > >> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. > > > > > > So what do you use for the serial devices? platform_device was vetoed > > > for that purpose by Greg. > > > > device tree? > > No. > > This patchset from Rob is the way I have been saying it should be done > for years now. Yes, a "bus" takes up more boilerplate code (blame me > for that), but overall, it makes the drivers simpler, and fits into the > rest of the kernel driver/device model much better. The basic problem is that the bus should be tty_ports not uart, fix that and the rest starts to make sense. Alan
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-18 13:00 +0200 |
| Message-ID | <s7tdg-75c-33@gated-at.bofh.it> |
| In reply to | #1465119 |
Hi Pavel, > Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@ucw.cz>: > > >> >> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. > > So what do you use for the serial devices? platform_device was vetoed > for that purpose by Greg. device tree? This adds code of course - but only for the slave drivers. So you shouldn't count them for a fair comparison of what it means for implementing a new API.
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-18 13:30 +0200 |
| Message-ID | <s7tGi-7xL-5@gated-at.bofh.it> |
| In reply to | #1465119 |
Because it was misunderstood, here a longer answer. > Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@ucw.cz>: > > >> >> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings. > > So what do you use for the serial devices? You misunderstood the w/o documentation/bindings in a way that the full patch set doesn't use it. But it means changes w/o these aspects... > platform_device was vetoed > for that purpose by Greg. That is true but not relevant at all since nobody wants to introduce platform_device again. I have just removed these from counting differences to make the number of lines comparable to Rob's proposal. Rob also uses device tree but has not added bindings or documentation to his patch set so that it would be unfair to include them in the changes count in one proposal and omit it in the other. Generally it might not even be important to compare both approaches again and then the number of files / changes is not important. But if it is, we should count them correctly.
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-08-18 13:00 +0200 |
| Message-ID | <s7tdh-75c-51@gated-at.bofh.it> |
| In reply to | #1465116 |
On Thu, Aug 18, 2016 at 12:49:47PM +0200, Marcel Holtmann wrote: > Hi Nikolaus, > > >> Currently, devices attached via a UART are not well supported in the > >> kernel. The problem is the device support is done in tty line disciplines, > >> various platform drivers to handle some sideband, and in userspace with > >> utilities such as hciattach. > >> > >> There have been several attempts to improve support, but they suffer from > >> still being tied into the tty layer and/or abusing the platform bus. This > >> is a prototype to show creating a proper UART bus for UART devices. It is > >> tied into the serial core (really struct uart_port) below the tty layer > >> in order to use existing serial drivers. > >> > >> This is functional with minimal testing using the loopback driver and > >> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave > >> device). It still needs lots of work and polish. > >> > >> TODOs: > >> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm > >> hoping all that complexity is from the tty layer and not needed here. > >> - Split out the controller for uart_ports into separate driver. Do we see > >> a need for controller drivers that are not standard serial drivers? > >> - Implement/test the removal paths > >> - Fix the receive callbacks for more than character at a time (i.e. DMA) > >> - Need better receive buffering than just a simple circular buffer or > >> perhaps a different receive interface (e.g. direct to client buffer)? > >> - Test with other UART drivers > >> - Convert a real driver/line discipline over to UART bus. > >> > >> Before I spend more time on this, I'm looking mainly for feedback on the > >> general direction and structure (the interface with the existing serial > >> drivers in particular). > > > > Some quick comments (can't do any real life tests in the next weeks) from my (biased) view: > > > > * tieing the solution into uart_port is the same as we had done. The difference seems to > > me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation. > > > > We have tapped the tty layer only because it can not be 100% avoided if we use serial_core. > > > > * one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that. > > > > * what I don't see is how we can implement our GPS device power control driver: > > - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should > > not be completely hidden from user space or represented by a new interface type invented just for this device > > (while the majority of other GPS receivers are still simple tty devices). > > - how we can detect that the device is sending data to the UART while no user space process has the uart port open > > i.e. when does the driver know when to start/stop the UART. > > I am actually not convinced that GPS should be represented as > /dev/ttyS0 or similar TTY. It think they deserve their own driver > exposing them as simple character devices. That way we can have a > proper DEVTYPE and userspace can find them correctly. We can also > annotate them if needed for special settings. I would _love_ to see that happen, but what about the GPS line discipline that we have today? How would that match up with a char device driver? thanks, greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-18 13:10 +0200 |
| Message-ID | <s7tmW-7oo-47@gated-at.bofh.it> |
| In reply to | #1465146 |
Hi Greg, >>>> Currently, devices attached via a UART are not well supported in the >>>> kernel. The problem is the device support is done in tty line disciplines, >>>> various platform drivers to handle some sideband, and in userspace with >>>> utilities such as hciattach. >>>> >>>> There have been several attempts to improve support, but they suffer from >>>> still being tied into the tty layer and/or abusing the platform bus. This >>>> is a prototype to show creating a proper UART bus for UART devices. It is >>>> tied into the serial core (really struct uart_port) below the tty layer >>>> in order to use existing serial drivers. >>>> >>>> This is functional with minimal testing using the loopback driver and >>>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >>>> device). It still needs lots of work and polish. >>>> >>>> TODOs: >>>> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >>>> hoping all that complexity is from the tty layer and not needed here. >>>> - Split out the controller for uart_ports into separate driver. Do we see >>>> a need for controller drivers that are not standard serial drivers? >>>> - Implement/test the removal paths >>>> - Fix the receive callbacks for more than character at a time (i.e. DMA) >>>> - Need better receive buffering than just a simple circular buffer or >>>> perhaps a different receive interface (e.g. direct to client buffer)? >>>> - Test with other UART drivers >>>> - Convert a real driver/line discipline over to UART bus. >>>> >>>> Before I spend more time on this, I'm looking mainly for feedback on the >>>> general direction and structure (the interface with the existing serial >>>> drivers in particular). >>> >>> Some quick comments (can't do any real life tests in the next weeks) from my (biased) view: >>> >>> * tieing the solution into uart_port is the same as we had done. The difference seems to >>> me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation. >>> >>> We have tapped the tty layer only because it can not be 100% avoided if we use serial_core. >>> >>> * one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that. >>> >>> * what I don't see is how we can implement our GPS device power control driver: >>> - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should >>> not be completely hidden from user space or represented by a new interface type invented just for this device >>> (while the majority of other GPS receivers are still simple tty devices). >>> - how we can detect that the device is sending data to the UART while no user space process has the uart port open >>> i.e. when does the driver know when to start/stop the UART. >> >> I am actually not convinced that GPS should be represented as >> /dev/ttyS0 or similar TTY. It think they deserve their own driver >> exposing them as simple character devices. That way we can have a >> proper DEVTYPE and userspace can find them correctly. We can also >> annotate them if needed for special settings. > > I would _love_ to see that happen, but what about the GPS line > discipline that we have today? How would that match up with a char > device driver? we have a GPS line discipline? What is that one doing? As far as I know all GPS implementations are fully userspace. Regards Marcel
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-08-18 13:30 +0200 |
| Message-ID | <s7tGi-7xL-3@gated-at.bofh.it> |
| In reply to | #1465175 |
On Thu, Aug 18, 2016 at 01:01:24PM +0200, Marcel Holtmann wrote: > Hi Greg, > > >>>> Currently, devices attached via a UART are not well supported in the > >>>> kernel. The problem is the device support is done in tty line disciplines, > >>>> various platform drivers to handle some sideband, and in userspace with > >>>> utilities such as hciattach. > >>>> > >>>> There have been several attempts to improve support, but they suffer from > >>>> still being tied into the tty layer and/or abusing the platform bus. This > >>>> is a prototype to show creating a proper UART bus for UART devices. It is > >>>> tied into the serial core (really struct uart_port) below the tty layer > >>>> in order to use existing serial drivers. > >>>> > >>>> This is functional with minimal testing using the loopback driver and > >>>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave > >>>> device). It still needs lots of work and polish. > >>>> > >>>> TODOs: > >>>> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm > >>>> hoping all that complexity is from the tty layer and not needed here. > >>>> - Split out the controller for uart_ports into separate driver. Do we see > >>>> a need for controller drivers that are not standard serial drivers? > >>>> - Implement/test the removal paths > >>>> - Fix the receive callbacks for more than character at a time (i.e. DMA) > >>>> - Need better receive buffering than just a simple circular buffer or > >>>> perhaps a different receive interface (e.g. direct to client buffer)? > >>>> - Test with other UART drivers > >>>> - Convert a real driver/line discipline over to UART bus. > >>>> > >>>> Before I spend more time on this, I'm looking mainly for feedback on the > >>>> general direction and structure (the interface with the existing serial > >>>> drivers in particular). > >>> > >>> Some quick comments (can't do any real life tests in the next weeks) from my (biased) view: > >>> > >>> * tieing the solution into uart_port is the same as we had done. The difference seems to > >>> me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation. > >>> > >>> We have tapped the tty layer only because it can not be 100% avoided if we use serial_core. > >>> > >>> * one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that. > >>> > >>> * what I don't see is how we can implement our GPS device power control driver: > >>> - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should > >>> not be completely hidden from user space or represented by a new interface type invented just for this device > >>> (while the majority of other GPS receivers are still simple tty devices). > >>> - how we can detect that the device is sending data to the UART while no user space process has the uart port open > >>> i.e. when does the driver know when to start/stop the UART. > >> > >> I am actually not convinced that GPS should be represented as > >> /dev/ttyS0 or similar TTY. It think they deserve their own driver > >> exposing them as simple character devices. That way we can have a > >> proper DEVTYPE and userspace can find them correctly. We can also > >> annotate them if needed for special settings. > > > > I would _love_ to see that happen, but what about the GPS line > > discipline that we have today? How would that match up with a char > > device driver? > > we have a GPS line discipline? What is that one doing? As far as I > know all GPS implementations are fully userspace. Hm, for some reason I thought that was what n_gsm.c was being used for, but I could be wrong, I've never seen the hardware that uses that code... greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-08-18 13:50 +0200 |
| Message-ID | <s7tZD-7Fb-7@gated-at.bofh.it> |
| In reply to | #1465188 |
Hi! > > > I would _love_ to see that happen, but what about the GPS line > > > discipline that we have today? How would that match up with a char > > > device driver? > > > > we have a GPS line discipline? What is that one doing? As far as I > > know all GPS implementations are fully userspace. > > Hm, for some reason I thought that was what n_gsm.c was being used for, > but I could be wrong, I've never seen the hardware that uses that > code... n_gsm.c seems to be multiplexing support. Splits one serial link into multiple "virtual" serial links. Nothing to do with GPS explicitely, altrough it looks NMEA data is going to go over one of the channels sometimes. I guess we should care about that later... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | Marcel Holtmann <marcel@holtmann.org> |
|---|---|
| Date | 2016-08-18 14:00 +0200 |
| Message-ID | <s7u9k-7K4-23@gated-at.bofh.it> |
| In reply to | #1465188 |
Hi Greg, >>>>>> Currently, devices attached via a UART are not well supported in the >>>>>> kernel. The problem is the device support is done in tty line disciplines, >>>>>> various platform drivers to handle some sideband, and in userspace with >>>>>> utilities such as hciattach. >>>>>> >>>>>> There have been several attempts to improve support, but they suffer from >>>>>> still being tied into the tty layer and/or abusing the platform bus. This >>>>>> is a prototype to show creating a proper UART bus for UART devices. It is >>>>>> tied into the serial core (really struct uart_port) below the tty layer >>>>>> in order to use existing serial drivers. >>>>>> >>>>>> This is functional with minimal testing using the loopback driver and >>>>>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >>>>>> device). It still needs lots of work and polish. >>>>>> >>>>>> TODOs: >>>>>> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >>>>>> hoping all that complexity is from the tty layer and not needed here. >>>>>> - Split out the controller for uart_ports into separate driver. Do we see >>>>>> a need for controller drivers that are not standard serial drivers? >>>>>> - Implement/test the removal paths >>>>>> - Fix the receive callbacks for more than character at a time (i.e. DMA) >>>>>> - Need better receive buffering than just a simple circular buffer or >>>>>> perhaps a different receive interface (e.g. direct to client buffer)? >>>>>> - Test with other UART drivers >>>>>> - Convert a real driver/line discipline over to UART bus. >>>>>> >>>>>> Before I spend more time on this, I'm looking mainly for feedback on the >>>>>> general direction and structure (the interface with the existing serial >>>>>> drivers in particular). >>>>> >>>>> Some quick comments (can't do any real life tests in the next weeks) from my (biased) view: >>>>> >>>>> * tieing the solution into uart_port is the same as we had done. The difference seems to >>>>> me that you completely bypass serial_core (and tty) while we want to integrate it with standard tty operation. >>>>> >>>>> We have tapped the tty layer only because it can not be 100% avoided if we use serial_core. >>>>> >>>>> * one feedback I had received was that there may be uart device drivers not using serial_core. I am not sure if your approach addresses that. >>>>> >>>>> * what I don't see is how we can implement our GPS device power control driver: >>>>> - the device should still present itself as a tty device (so that cat /dev/ttyO1 reports NMEA records) and should >>>>> not be completely hidden from user space or represented by a new interface type invented just for this device >>>>> (while the majority of other GPS receivers are still simple tty devices). >>>>> - how we can detect that the device is sending data to the UART while no user space process has the uart port open >>>>> i.e. when does the driver know when to start/stop the UART. >>>> >>>> I am actually not convinced that GPS should be represented as >>>> /dev/ttyS0 or similar TTY. It think they deserve their own driver >>>> exposing them as simple character devices. That way we can have a >>>> proper DEVTYPE and userspace can find them correctly. We can also >>>> annotate them if needed for special settings. >>> >>> I would _love_ to see that happen, but what about the GPS line >>> discipline that we have today? How would that match up with a char >>> device driver? >> >> we have a GPS line discipline? What is that one doing? As far as I >> know all GPS implementations are fully userspace. > > Hm, for some reason I thought that was what n_gsm.c was being used for, > but I could be wrong, I've never seen the hardware that uses that > code... the n_gsm.c is for 3GPP TS 07.10. Which is a TTY multiplexer. Has nothing to do with GPS. Regards Marcel
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | linux.kernel
csiph-web