From: "H. Nikolaus Schaller" <hns@goldelico.com> To: Rob Herring <robh@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>, Peter Hurley <peter@hurleysoftware.com>, NeilBrown <neil@brown.name>, Arnd Bergmann <arnd@arndb.de>, Linus Walleij <linus.walleij@linaro.org>, linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Thu, 18 Aug 2016 12:39:25 +0200 [thread overview] Message-ID: <118926C8-F4D0-41F5-B6A8-690E0312F3FB@goldelico.com> (raw) In-Reply-To: <20160818011445.22726-1-robh@kernel.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com> To: Rob Herring <robh@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>, Peter Hurley <peter@hurleysoftware.com>, NeilBrown <neil@brown.name>, Arnd Bergmann <arnd@arndb.de>, Linus Walleij <linus.walleij@linaro.org>, linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Thu, 18 Aug 2016 12:39:25 +0200 [thread overview] Message-ID: <118926C8-F4D0-41F5-B6A8-690E0312F3FB@goldelico.com> (raw) In-Reply-To: <20160818011445.22726-1-robh@kernel.org> Hi Rob, many thanks for picking up this unsolved topic! > Am 18.08.2016 um 03:14 schrieb Rob Herring <robh@kernel.org>: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > Rob >=20 >=20 > 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 >=20 > 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 >>=20 >> .../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
next prev parent reply other threads:[~2016-08-18 10:39 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-18 1:14 [RFC PATCH 0/3] UART slave device bus Rob Herring 2016-08-18 1:14 ` [RFC PATCH 1/3] uart bus: Introduce new bus for UART slave devices Rob Herring 2016-08-18 1:14 ` [RFC PATCH 2/3] tty: serial_core: make tty_struct optional Rob Herring 2016-08-18 10:50 ` Pavel Machek 2016-08-18 1:14 ` [RFC PATCH 3/3] tty: serial_core: add uart controller registration Rob Herring 2016-08-18 10:22 ` [RFC PATCH 0/3] UART slave device bus Greg Kroah-Hartman 2016-08-18 10:22 ` Greg Kroah-Hartman 2016-08-18 10:30 ` Marcel Holtmann 2016-08-18 10:53 ` Greg Kroah-Hartman 2016-08-18 13:53 ` Rob Herring 2016-08-18 13:15 ` Rob Herring 2016-08-18 15:04 ` One Thousand Gnomes 2016-08-18 18:33 ` Rob Herring 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-25 16:40 ` Rob Herring 2016-08-25 16:40 ` Rob Herring 2016-08-26 13:12 ` One Thousand Gnomes 2016-08-18 10:39 ` H. Nikolaus Schaller [this message] 2016-08-18 10:39 ` H. Nikolaus Schaller 2016-08-18 10:47 ` Pavel Machek 2016-08-18 10:54 ` H. Nikolaus Schaller 2016-08-18 10:54 ` H. Nikolaus Schaller 2016-08-18 10:57 ` Greg Kroah-Hartman 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 11:14 ` H. Nikolaus Schaller 2016-08-18 14:40 ` One Thousand Gnomes 2016-08-18 14:40 ` One Thousand Gnomes 2016-08-18 14:58 ` Greg Kroah-Hartman 2016-08-18 11:27 ` H. Nikolaus Schaller 2016-08-18 10:49 ` Marcel Holtmann 2016-08-18 10:55 ` Greg Kroah-Hartman 2016-08-18 11:01 ` Marcel Holtmann 2016-08-18 11:24 ` Greg Kroah-Hartman 2016-08-18 11:42 ` Pavel Machek 2016-08-18 11:42 ` Pavel Machek 2016-08-18 11:51 ` Marcel Holtmann 2016-08-18 11:51 ` Marcel Holtmann 2016-08-18 15:14 ` One Thousand Gnomes 2016-08-18 15:13 ` One Thousand Gnomes 2016-08-18 11:10 ` Pavel Machek 2016-08-18 11:18 ` H. Nikolaus Schaller 2016-08-18 11:49 ` Marcel Holtmann 2016-08-18 12:16 ` H. Nikolaus Schaller 2016-08-18 12:16 ` H. Nikolaus Schaller 2016-08-18 15:15 ` One Thousand Gnomes 2016-08-18 11:47 ` Marcel Holtmann 2016-08-18 13:01 ` Pavel Machek 2016-08-18 15:16 ` One Thousand Gnomes 2016-08-18 11:02 ` H. Nikolaus Schaller 2016-08-18 11:02 ` H. Nikolaus Schaller 2016-08-18 11:41 ` Marcel Holtmann 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 12:07 ` H. Nikolaus Schaller 2016-08-18 11:02 ` Pavel Machek 2016-08-18 13:07 ` Linus Walleij 2016-08-18 17:31 ` Marcel Holtmann 2016-08-18 14:25 ` One Thousand Gnomes 2016-08-18 15:14 ` H. Nikolaus Schaller 2016-08-18 15:14 ` H. Nikolaus Schaller 2016-08-18 15:38 ` One Thousand Gnomes 2016-08-18 18:31 ` H. Nikolaus Schaller 2016-08-18 18:31 ` H. Nikolaus Schaller 2016-08-18 22:25 ` Rob Herring 2016-08-19 11:38 ` One Thousand Gnomes 2016-08-19 15:36 ` Sebastian Reichel 2016-08-18 20:29 ` Sebastian Reichel 2016-08-18 23:08 ` Rob Herring 2016-08-19 5:21 ` Sebastian Reichel 2016-08-19 7:29 ` H. Nikolaus Schaller 2016-08-19 7:49 ` Oleksij Rempel 2016-08-19 7:49 ` Oleksij Rempel 2016-08-19 17:50 ` H. Nikolaus Schaller 2016-08-19 20:19 ` Oleksij Rempel 2016-08-19 20:19 ` Oleksij Rempel 2016-08-20 13:34 ` One Thousand Gnomes 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-22 20:39 ` Sebastian Reichel 2016-08-22 21:23 ` H. Nikolaus Schaller 2016-08-22 21:43 ` Arnd Bergmann 2016-08-22 22:42 ` Sebastian Reichel 2016-08-22 22:52 ` One Thousand Gnomes 2016-08-22 23:10 ` Sebastian Reichel 2016-08-23 7:28 ` H. Nikolaus Schaller 2016-08-27 12:01 ` Michal Suchanek 2016-08-19 11:06 ` One Thousand Gnomes 2016-08-19 17:42 ` H. Nikolaus Schaller 2016-08-19 17:42 ` H. Nikolaus Schaller 2016-08-20 13:22 ` One Thousand Gnomes 2016-08-20 13:22 ` One Thousand Gnomes 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 7:50 ` H. Nikolaus Schaller 2016-08-21 17:09 ` One Thousand Gnomes 2016-08-21 18:23 ` H. Nikolaus Schaller 2016-08-21 18:23 ` H. Nikolaus Schaller 2016-08-22 9:09 ` One Thousand Gnomes 2016-08-22 9:33 ` Marcel Holtmann 2016-08-22 9:33 ` Marcel Holtmann 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-19 11:03 ` One Thousand Gnomes 2016-08-19 14:44 ` Sebastian Reichel 2016-08-22 12:37 ` Arnd Bergmann 2016-08-22 13:38 ` Rob Herring 2016-08-22 15:24 ` Arnd Bergmann 2016-08-22 15:28 ` Marcel Holtmann 2016-08-22 15:46 ` Arnd Bergmann 2016-08-22 15:45 ` One Thousand Gnomes 2016-08-22 21:07 ` Marcel Holtmann 2016-08-22 21:35 ` One Thousand Gnomes 2016-08-22 22:03 ` Sebastian Reichel 2016-08-22 22:46 ` One Thousand Gnomes 2016-08-22 23:41 ` Sebastian Reichel 2016-08-24 12:14 ` Linus Walleij 2016-08-22 16:44 ` Rob Herring 2016-08-22 17:02 ` One Thousand Gnomes 2016-08-22 17:30 ` Rob Herring 2016-08-22 17:30 ` Rob Herring 2016-08-22 17:38 ` One Thousand Gnomes 2016-08-22 21:16 ` Marcel Holtmann 2016-08-22 21:32 ` One Thousand Gnomes 2016-08-22 22:00 ` Pavel Machek 2016-08-22 22:54 ` One Thousand Gnomes 2016-08-22 23:57 ` Sebastian Reichel 2016-08-23 0:15 ` One Thousand Gnomes 2016-08-23 0:57 ` Sebastian Reichel 2016-08-24 13:57 ` One Thousand Gnomes 2016-08-24 13:57 ` One Thousand Gnomes 2016-08-24 14:29 ` Marcel Holtmann 2016-08-24 14:29 ` Marcel Holtmann 2016-08-23 11:42 ` Marcel Holtmann 2016-08-22 23:02 ` Sebastian Reichel 2016-08-22 20:00 ` Sebastian Reichel 2016-08-22 22:00 ` Rob Herring 2016-08-22 22:00 ` Rob Herring 2016-08-22 22:18 ` Sebastian Reichel 2016-08-23 21:04 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=118926C8-F4D0-41F5-B6A8-690E0312F3FB@goldelico.com \ --to=hns@goldelico.com \ --cc=arnd@arndb.de \ --cc=gregkh@linuxfoundation.org \ --cc=jslaby@suse.com \ --cc=linus.walleij@linaro.org \ --cc=linux-bluetooth@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=marcel@holtmann.org \ --cc=neil@brown.name \ --cc=pavel@ucw.cz \ --cc=peter@hurleysoftware.com \ --cc=robh@kernel.org \ --cc=sre@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.