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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2016-08-19 03:40 +0200 |
| Message-ID | <s7GWS-7sc-47@gated-at.bofh.it> |
| In reply to | #1465794 |
On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: > Hi Rob, > > Thanks for going forward and implementing this. I also started, > but was far from a functional state. > > 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. >> - 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). > > I had a look at the uart_dev API: > > int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); > int uart_dev_connect(struct uart_device *udev); > > The flow control configuration should be done separately. e.g.: > uart_dev_flow_control(struct uart_device *udev, bool enable); No objection, but out of curiosity, why? > int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); > int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); > > UART communication does not have to be host-initiated, so this > API requires polling. Either some function similar to poll in > userspace is needed, or it should be implemented as callback. What's the userspace need? I'm assuming the only immediate consumers are in-kernel. Rob
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-19 07:30 +0200 |
| Message-ID | <s7Kxs-1qQ-21@gated-at.bofh.it> |
| In reply to | #1465815 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: > On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: > > Thanks for going forward and implementing this. I also started, > > but was far from a functional state. > > > > 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. > >> - 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). > > > > I had a look at the uart_dev API: > > > > int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); > > int uart_dev_connect(struct uart_device *udev); > > > > The flow control configuration should be done separately. e.g.: > > uart_dev_flow_control(struct uart_device *udev, bool enable); > > No objection, but out of curiosity, why? Nokia's bluetooth uart protocol disables flow control during speed changes. > > int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); > > int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); > > > > UART communication does not have to be host-initiated, so this > > API requires polling. Either some function similar to poll in > > userspace is needed, or it should be implemented as callback. > > What's the userspace need? I meant "Either some function similar to userspace's poll() is needed, ...". Something like uart_dev_wait_for_rx() Alternatively the rx function could be a callback, that is called when there is new data. > I'm assuming the only immediate consumers are in-kernel. Yes, but the driver should be notified about incoming data. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-19 09:40 +0200 |
| Message-ID | <s7Mzh-2Fi-85@gated-at.bofh.it> |
| In reply to | #1466004 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > Am 19.08.2016 um 07:21 schrieb Sebastian Reichel <sre@kernel.org>: > > Hi, > > On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: >> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: >>> Thanks for going forward and implementing this. I also started, >>> but was far from a functional state. >>> >>> 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. >>>> - 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). >>> >>> I had a look at the uart_dev API: >>> >>> int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); >>> int uart_dev_connect(struct uart_device *udev); >>> >>> The flow control configuration should be done separately. e.g.: >>> uart_dev_flow_control(struct uart_device *udev, bool enable); >> >> No objection, but out of curiosity, why? > > Nokia's bluetooth uart protocol disables flow control during speed > changes. > >>> int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); >>> int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); >>> >>> UART communication does not have to be host-initiated, so this >>> API requires polling. Either some function similar to poll in >>> userspace is needed, or it should be implemented as callback. >> >> What's the userspace need? > > I meant "Either some function similar to userspace's poll() is > needed, ...". Something like uart_dev_wait_for_rx() > > Alternatively the rx function could be a callback, that > is called when there is new data. > >> I'm assuming the only immediate consumers are in-kernel. > > Yes, but the driver should be notified about incoming data. Yes, this is very important. If possible, please do a callback for every character that arrives. And not only if the rx buffer becomes full, to give the slave driver a chance to trigger actions almost immediately after every character. This probably runs in interrupt context and can happen often. In our proposal some months ago we have implemented such an rx_notification callback for every character. This allows to work without rx buffer and implement one in the driver if needed. This gives the driver full control over the rx buffer dimensions. And we have made the callback to return a boolean flag which tells if the character is to be queued in the tty layer so that the driver can decide for every byte if it is to be hidden from user space or passed. Since we pass a pointer, the driver could even modify the character passed back, but we have not used this feature. This should cover most (but certainly not all) situations of implementing protocol engines in uart slave drivers. Our API therefore was defined as: void uart_register_slave(struct uart_port *uport, void *slave); void uart_register_rx_notification(struct uart_port *uport, bool (*function)(void *slave, unsigned int *c), struct ktermios *termios); Registering a slave appears to be comparable to uart_dev_connect() and registering an rx_notification combines uart_dev_config() and setting the callback. Unregistration is done by passing a NULL pointer for 'slave' or 'function'. If there will be a very similar API with a callback like this, we won't have to change our driver architecture much. If there is a uart_dev_wait_for_rx() with buffer it is much more difficult to handle. BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Oleksij Rempel <linux@rempel-privat.de> |
|---|---|
| Date | 2016-08-19 10:00 +0200 |
| Message-ID | <s7MSC-2Nt-7@gated-at.bofh.it> |
| In reply to | #1466190 |
[Multipart message — attachments visible in raw view] — view raw
Hallo Nikolaus, do i understand it correctly. This driver is to make kind of interchip communication and represent uart as a bus to allow use this bus from multiple kernel driver or expose it to user space? Correct? Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller: > Hi, > >> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel <sre@kernel.org>: >> >> Hi, >> >> On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: >>> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: >>>> Thanks for going forward and implementing this. I also started, >>>> but was far from a functional state. >>>> >>>> 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. >>>>> - 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). >>>> >>>> I had a look at the uart_dev API: >>>> >>>> int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); >>>> int uart_dev_connect(struct uart_device *udev); >>>> >>>> The flow control configuration should be done separately. e.g.: >>>> uart_dev_flow_control(struct uart_device *udev, bool enable); >>> >>> No objection, but out of curiosity, why? >> >> Nokia's bluetooth uart protocol disables flow control during speed >> changes. >> >>>> int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); >>>> int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); >>>> >>>> UART communication does not have to be host-initiated, so this >>>> API requires polling. Either some function similar to poll in >>>> userspace is needed, or it should be implemented as callback. >>> >>> What's the userspace need? >> >> I meant "Either some function similar to userspace's poll() is >> needed, ...". Something like uart_dev_wait_for_rx() >> >> Alternatively the rx function could be a callback, that >> is called when there is new data. >> >>> I'm assuming the only immediate consumers are in-kernel. >> >> Yes, but the driver should be notified about incoming data. > > Yes, this is very important. > > If possible, please do a callback for every character that arrives. > And not only if the rx buffer becomes full, to give the slave driver > a chance to trigger actions almost immediately after every character. > This probably runs in interrupt context and can happen often. > > In our proposal some months ago we have implemented such > an rx_notification callback for every character. This allows to work > without rx buffer and implement one in the driver if needed. This > gives the driver full control over the rx buffer dimensions. > > And we have made the callback to return a boolean flag which > tells if the character is to be queued in the tty layer so that the > driver can decide for every byte if it is to be hidden from user > space or passed. Since we pass a pointer, the driver could even > modify the character passed back, but we have not used this > feature. > > This should cover most (but certainly not all) situations of > implementing protocol engines in uart slave drivers. > > Our API therefore was defined as: > > void uart_register_slave(struct uart_port *uport, void *slave); > void uart_register_rx_notification(struct uart_port *uport, > bool (*function)(void *slave, unsigned int *c), > struct ktermios *termios); > > Registering a slave appears to be comparable to uart_dev_connect() > and registering an rx_notification combines uart_dev_config() and > setting the callback. > > Unregistration is done by passing a NULL pointer for 'slave' or 'function'. > > If there will be a very similar API with a callback like this, we won't have > to change our driver architecture much. > > If there is a uart_dev_wait_for_rx() with buffer it is much more difficult > to handle. > > BR, > Nikolaus > > -- Regards, Oleksij
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-19 20:00 +0200 |
| Message-ID | <s7Wff-e9-11@gated-at.bofh.it> |
| In reply to | #1466201 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > Am 19.08.2016 um 09:49 schrieb Oleksij Rempel <linux@rempel-privat.de>: > > Hallo Nikolaus, > > do i understand it correctly. This driver is to make kind of interchip > communication and represent uart as a bus to allow use this bus from > multiple kernel driver or expose it to user space? The idea for UART slave devices is to handle devices connected on an embedded board to an UART port in kernel. Currently most such devices are just passed through to some /dev/tty and handled by user-space daemons. So it is not necessarily about multiple kernel drivers to use the same UART, although that could also be required. A single one is already difficult... And some scenarios need to shield the UART from user space (currently there is always one /dev/tty per UART - unless the UART is completely disabled). Some ideas where it might be needed: * bluetooth HCI over UART * a weird GPS device whose power state can only reliably be detected by monitoring data activity * other chips (microcontrollers) connected through UART - similar to I2C slave devices * it potentially could help to better implement IrDA (although that is mostly legacy) What it is not about are UART/RS232 converters connected through USB or virtual serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices connected through USB (even if they also run HCI protocol). > > Correct? > > Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller: >> Hi, >> >>> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel <sre@kernel.org>: >>> >>> Hi, >>> >>> On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: >>>> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: >>>>> Thanks for going forward and implementing this. I also started, >>>>> but was far from a functional state. >>>>> >>>>> 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. >>>>>> - 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). >>>>> >>>>> I had a look at the uart_dev API: >>>>> >>>>> int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); >>>>> int uart_dev_connect(struct uart_device *udev); >>>>> >>>>> The flow control configuration should be done separately. e.g.: >>>>> uart_dev_flow_control(struct uart_device *udev, bool enable); >>>> >>>> No objection, but out of curiosity, why? >>> >>> Nokia's bluetooth uart protocol disables flow control during speed >>> changes. >>> >>>>> int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); >>>>> int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); >>>>> >>>>> UART communication does not have to be host-initiated, so this >>>>> API requires polling. Either some function similar to poll in >>>>> userspace is needed, or it should be implemented as callback. >>>> >>>> What's the userspace need? >>> >>> I meant "Either some function similar to userspace's poll() is >>> needed, ...". Something like uart_dev_wait_for_rx() >>> >>> Alternatively the rx function could be a callback, that >>> is called when there is new data. >>> >>>> I'm assuming the only immediate consumers are in-kernel. >>> >>> Yes, but the driver should be notified about incoming data. >> >> Yes, this is very important. >> >> If possible, please do a callback for every character that arrives. >> And not only if the rx buffer becomes full, to give the slave driver >> a chance to trigger actions almost immediately after every character. >> This probably runs in interrupt context and can happen often. >> >> In our proposal some months ago we have implemented such >> an rx_notification callback for every character. This allows to work >> without rx buffer and implement one in the driver if needed. This >> gives the driver full control over the rx buffer dimensions. >> >> And we have made the callback to return a boolean flag which >> tells if the character is to be queued in the tty layer so that the >> driver can decide for every byte if it is to be hidden from user >> space or passed. Since we pass a pointer, the driver could even >> modify the character passed back, but we have not used this >> feature. >> >> This should cover most (but certainly not all) situations of >> implementing protocol engines in uart slave drivers. >> >> Our API therefore was defined as: >> >> void uart_register_slave(struct uart_port *uport, void *slave); >> void uart_register_rx_notification(struct uart_port *uport, >> bool (*function)(void *slave, unsigned int *c), >> struct ktermios *termios); >> >> Registering a slave appears to be comparable to uart_dev_connect() >> and registering an rx_notification combines uart_dev_config() and >> setting the callback. >> >> Unregistration is done by passing a NULL pointer for 'slave' or 'function'. >> >> If there will be a very similar API with a callback like this, we won't have >> to change our driver architecture much. >> >> If there is a uart_dev_wait_for_rx() with buffer it is much more difficult >> to handle. >> >> BR, >> Nikolaus >> >> > > > -- > Regards, > Oleksij >
[toc] | [prev] | [next] | [standalone]
| From | Oleksij Rempel <linux@rempel-privat.de> |
|---|---|
| Date | 2016-08-19 22:30 +0200 |
| Message-ID | <s7YAp-1Rm-13@gated-at.bofh.it> |
| In reply to | #1466591 |
[Multipart message — attachments visible in raw view] — view raw
Am 19.08.2016 um 19:50 schrieb H. Nikolaus Schaller: > Hi, > >> Am 19.08.2016 um 09:49 schrieb Oleksij Rempel <linux@rempel-privat.de>: >> >> Hallo Nikolaus, >> >> do i understand it correctly. This driver is to make kind of interchip >> communication and represent uart as a bus to allow use this bus from >> multiple kernel driver or expose it to user space? > > The idea for UART slave devices is to handle devices connected on an > embedded board to an UART port in kernel. Currently most such devices > are just passed through to some /dev/tty and handled by user-space daemons. > > So it is not necessarily about multiple kernel drivers to use the same UART, although > that could also be required. > > A single one is already difficult... And some scenarios need to shield the UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C slave devices > * it potentially could help to better implement IrDA (although that is mostly legacy) > > What it is not about are UART/RS232 converters connected through USB or virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices > connected through USB (even if they also run HCI protocol). Ah... ok. thank you for explanation. I was thinking it is going in similar direction with my project - use SPI for communication between two SoCs. It is based on SSI32 protocol from Bosch. In case it is going to this direction: Master implementation for linux side (tested on Banana Pi and iMX6): https://github.com/olerem/linux-2.6/commits/bpi-spi-variant2-2016.07.26.2 Slave implementation for stm32f303 (tested on f3 discovery): https://github.com/olerem/libopencm3-examples/commits/ssi32-2016.08.17.1 protocol decoder for logic analyzer (sigrok): https://github.com/olerem/libsigrokdecode/commits/ssi32_dec-2016.08.11 >> Correct? >> >> Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller: >>> Hi, >>> >>>> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel <sre@kernel.org>: >>>> >>>> Hi, >>>> >>>> On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: >>>>> On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel <sre@kernel.org> wrote: >>>>>> Thanks for going forward and implementing this. I also started, >>>>>> but was far from a functional state. >>>>>> >>>>>> 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. >>>>>>> - 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). >>>>>> >>>>>> I had a look at the uart_dev API: >>>>>> >>>>>> int uart_dev_config(struct uart_device *udev, int baud, int parity, int bits, int flow); >>>>>> int uart_dev_connect(struct uart_device *udev); >>>>>> >>>>>> The flow control configuration should be done separately. e.g.: >>>>>> uart_dev_flow_control(struct uart_device *udev, bool enable); >>>>> >>>>> No objection, but out of curiosity, why? >>>> >>>> Nokia's bluetooth uart protocol disables flow control during speed >>>> changes. >>>> >>>>>> int uart_dev_tx(struct uart_device *udev, u8 *buf, size_t count); >>>>>> int uart_dev_rx(struct uart_device *udev, u8 *buf, size_t count); >>>>>> >>>>>> UART communication does not have to be host-initiated, so this >>>>>> API requires polling. Either some function similar to poll in >>>>>> userspace is needed, or it should be implemented as callback. >>>>> >>>>> What's the userspace need? >>>> >>>> I meant "Either some function similar to userspace's poll() is >>>> needed, ...". Something like uart_dev_wait_for_rx() >>>> >>>> Alternatively the rx function could be a callback, that >>>> is called when there is new data. >>>> >>>>> I'm assuming the only immediate consumers are in-kernel. >>>> >>>> Yes, but the driver should be notified about incoming data. >>> >>> Yes, this is very important. >>> >>> If possible, please do a callback for every character that arrives. >>> And not only if the rx buffer becomes full, to give the slave driver >>> a chance to trigger actions almost immediately after every character. >>> This probably runs in interrupt context and can happen often. >>> >>> In our proposal some months ago we have implemented such >>> an rx_notification callback for every character. This allows to work >>> without rx buffer and implement one in the driver if needed. This >>> gives the driver full control over the rx buffer dimensions. >>> >>> And we have made the callback to return a boolean flag which >>> tells if the character is to be queued in the tty layer so that the >>> driver can decide for every byte if it is to be hidden from user >>> space or passed. Since we pass a pointer, the driver could even >>> modify the character passed back, but we have not used this >>> feature. >>> >>> This should cover most (but certainly not all) situations of >>> implementing protocol engines in uart slave drivers. >>> >>> Our API therefore was defined as: >>> >>> void uart_register_slave(struct uart_port *uport, void *slave); >>> void uart_register_rx_notification(struct uart_port *uport, >>> bool (*function)(void *slave, unsigned int *c), >>> struct ktermios *termios); >>> >>> Registering a slave appears to be comparable to uart_dev_connect() >>> and registering an rx_notification combines uart_dev_config() and >>> setting the callback. >>> >>> Unregistration is done by passing a NULL pointer for 'slave' or 'function'. >>> >>> If there will be a very similar API with a callback like this, we won't have >>> to change our driver architecture much. >>> >>> If there is a uart_dev_wait_for_rx() with buffer it is much more difficult >>> to handle. >>> >>> BR, >>> Nikolaus >>> >>> >> >> >> -- >> Regards, >> Oleksij >> > -- Regards, Oleksij
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-20 15:40 +0200 |
| Message-ID | <s8eFb-3F4-23@gated-at.bofh.it> |
| In reply to | #1466591 |
> A single one is already difficult... And some scenarios need to shield the UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). That bit is already covered and one or two devices support this because they have things like 3 serial ports but one cannot be used if some other feature is enabled. You simply keep a private counter and return -EBUSY in the port->activate() method if needed. That is sufficient to share a UART with the tty layer when you have a contended resource, but not to borrow the UART and re-use the stack which is what is needed in this case. (You can even steal a UART this way by doing a hangup on it and then once it drops out of use taking it over and ensuring the EBUSY behaviour) > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C slave devices > * it potentially could help to better implement IrDA (although that is mostly legacy) > > What it is not about are UART/RS232 converters connected through USB or virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices > connected through USB (even if they also run HCI protocol). It actually has to be about both because you will find the exact same device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is it just about embedded boards. A current PC class device will usually have bluetooth connected via a UART where both components are on board. The same for GPS (or more accurately location services as it's usually more than just a GPS nowdays). There may also be onboard WWAN modems and other widgets wired this way. In the PC case the power relationship and connectivity is usually described via ACPI and that often means the kernel simply doesn't know how to manage the power states besides telling the modem, GPS. etc to turn itself on and off via normal ACPI power descriptions. Those may well call OpRegion handlers so it's all abstracted nicely and generic, but rather more invisible to the OS than DT describing pmic and/or gpio setings for the device. Todays low end Intel x86 PC has multiple DMA accelerated low power 16x50 compatible UARTS on die along with multiple channels of I2C and SPI. Things like Android and PC tablet devices with sensors have pretty much converged the old divide between a desktop/laptop/tablet PC and an 'embedded' board. Alan
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-21 10:00 +0200 |
| Message-ID | <s8vPH-5WQ-5@gated-at.bofh.it> |
| In reply to | #1466815 |
> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: >> What it is not about are UART/RS232 converters connected through USB or virtual >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices >> connected through USB (even if they also run HCI protocol). > > It actually has to be about both because you will find the exact same > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > it just about embedded boards. Not necessarily. We often have two interface options for exactly the sam sensor chips. They can be connected either through SPI or I2C. Which means that there is a core driver for the chip and two different transport glue components (see e.g. iio/accel/bmc150). This does not require I2C to be able to handle SPI or vice versa or provide a common API. And most Bluetooth devices I know have either UART or a direct USB interface. So in the USB case there is no need to connect it through some USB-UART bridge and treat it as an UART at all. BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-22 22:50 +0200 |
| Message-ID | <s94kp-2KX-9@gated-at.bofh.it> |
| In reply to | #1466937 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > > Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > >> What it is not about are UART/RS232 converters connected through USB or virtual > >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices > >> connected through USB (even if they also run HCI protocol). > > > > It actually has to be about both because you will find the exact same > > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > > it just about embedded boards. > > Not necessarily. > > We often have two interface options for exactly the sam sensor chips. They can be connected > either through SPI or I2C. Which means that there is a core driver for the chip and two different > transport glue components (see e.g. iio/accel/bmc150). > > This does not require I2C to be able to handle SPI or vice versa or provide a common API. I don't understand this comparison. I2C and SPI are different protocols, while native UART and USB-connected UART are both UART. > And most Bluetooth devices I know have either UART or a direct > USB interface. So in the USB case there is no need to connect > it through some USB-UART bridge and treat it as an UART at all. I think having support for USB-UART dongles is useful for driver development and testing on non-embedded HW. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-22 23:30 +0200 |
| Message-ID | <s94X8-3dH-19@gated-at.bofh.it> |
| In reply to | #1468037 |
[Multipart message — attachments visible in raw view] — view raw
Hi Sebastian, > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel <sre@kernel.org>: > > Hi, > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: >>>> What it is not about are UART/RS232 converters connected through USB or virtual >>>> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices >>>> connected through USB (even if they also run HCI protocol). >>> >>> It actually has to be about both because you will find the exact same >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is >>> it just about embedded boards. >> >> Not necessarily. >> >> We often have two interface options for exactly the sam sensor chips. They can be connected >> either through SPI or I2C. Which means that there is a core driver for the chip and two different >> transport glue components (see e.g. iio/accel/bmc150). >> >> This does not require I2C to be able to handle SPI or vice versa or provide a common API. > > I don't understand this comparison. I2C and SPI are different > protocols, Yes, they are different on protocol level, but on both you transfer blocks of data from/to a slave device which usually can be addressed. And for some chips they are just two slightly alternative serial interfaces. > while native UART and USB-connected UART are both UART. I see what you mean, but kernel divides between directly connected UART and USB-connected UART. drivers/usb/serial/ vs. drivers/tty/serial/ to implement two different groups of UARTs. Although on user space level they are harmonized again. This is why I compare with i2c and spi. But each such comparison is not perfect. Anyways, to me it looks as if everybody wants to make the solution work for usb-uarts as well (although I still would like to see a real world use-case). > >> And most Bluetooth devices I know have either UART or a direct >> USB interface. So in the USB case there is no need to connect >> it through some USB-UART bridge and treat it as an UART at all. > > I think having support for USB-UART dongles is useful for > driver development and testing on non-embedded HW. Hm. I assume you mean the Bluetooth situation where both, embedded UART connected chips and USB dongles are available. I am not a specialist for such things, but I think you have three options to connect bluetooth: a) SoC-UART <-> BT-Chip-UART-port b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port c) USB <-> BT-Chip-USB-port (not UART involved at all) Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected through USB and plugging it into a non-embedded USB port does not automatically show it as a tty interface. So you can't use it for testing the UART drivers. BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and one for USB. So they are also not exchangeable. Variant b) is IMHO of no practical relevance (but I may be wrong) because it would mean to add some costly FT232 or PL2302 chip where a different firmware variant works with direct USB connection. So to me it looks as if you need to develop different low-level drivers anyways. BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-22 23:50 +0200 |
| Message-ID | <s95gt-3lP-9@gated-at.bofh.it> |
| In reply to | #1468072 |
On Monday, August 22, 2016 11:23:26 PM CEST H. Nikolaus Schaller wrote: > I see what you mean, but kernel divides between directly connected UART and USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ That distinction purely exists for historic reasons. I'd argue that the former should actually go into drivers/tty/usb or similar. A long time ago, we commonly sorted device drivers by how they were attached to the system (as drivers/usb/serial/ and drivers/usb/storage still do), but almost everything is now sorted according to how it is used instead. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 00:50 +0200 |
| Message-ID | <s96cx-3WR-1@gated-at.bofh.it> |
| In reply to | #1468072 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On Mon, Aug 22, 2016 at 11:23:26PM +0200, H. Nikolaus Schaller wrote: > > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel <sre@kernel.org>: > > > > Hi, > > > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > >>>> What it is not about are UART/RS232 converters connected through USB or virtual > >>>> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices > >>>> connected through USB (even if they also run HCI protocol). > >>> > >>> It actually has to be about both because you will find the exact same > >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > >>> it just about embedded boards. > >> > >> Not necessarily. > >> > >> We often have two interface options for exactly the sam sensor chips. They can be connected > >> either through SPI or I2C. Which means that there is a core driver for the chip and two different > >> transport glue components (see e.g. iio/accel/bmc150). > >> > >> This does not require I2C to be able to handle SPI or vice versa or provide a common API. > > > > I don't understand this comparison. I2C and SPI are different > > protocols, > > Yes, they are different on protocol level, but on both you transfer blocks of data from/to a slave device > which usually can be addressed. And for some chips they are just two slightly alternative serial interfaces. > > > while native UART and USB-connected UART are both UART. > > I see what you mean, but kernel divides between directly connected UART and USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ > > to implement two different groups of UARTs. Although on user space level they are harmonized again. > This is why I compare with i2c and spi. But each such comparison is not perfect. > > Anyways, to me it looks as if everybody wants to make the solution work for usb-uarts as well > (although I still would like to see a real world use-case). > > > > >> And most Bluetooth devices I know have either UART or a direct > >> USB interface. So in the USB case there is no need to connect > >> it through some USB-UART bridge and treat it as an UART at all. > > > > I think having support for USB-UART dongles is useful for > > driver development and testing on non-embedded HW. > > Hm. I assume you mean the Bluetooth situation where both, embedded UART > connected chips and USB dongles are available. No. I mean I have some serial device, which is connected to the embedded UART, but I also have a standalone version. For driver development I can just use my standalone serial device, connect it to an USB-UART and develop the driver on non embedded HW. Then I can use the same driver on my embedded platform and it works, since it uses the same API. For e.g. I2C this works perfectly fine. I already did this with the I2C interface exposed on my notebook's VGA port. > I am not a specialist for such things, but I think you have three > options to connect bluetooth: > > a) SoC-UART <-> BT-Chip-UART-port > b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port > c) USB <-> BT-Chip-USB-port (not UART involved at all) > > Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected > through USB and plugging it into a non-embedded USB port does not automatically > show it as a tty interface. So you can't use it for testing the UART drivers. > > BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and > one for USB. So they are also not exchangeable. Yes, let's ignore option c). I'm talking about UART only. If the chip has native USB support, then that's a different driver. Note, that for more complex drivers it may become possible to use the same high-level driver via regmap at some point. Not sure if this kind of HW exists, though. > Variant b) is IMHO of no practical relevance (but I may be wrong) > because it would mean to add some costly FT232 or PL2302 chip > where a different firmware variant works with direct USB > connection. Well for some chips there is not native USB support. But my scenario was about development. Let's say I have a serial-chip and I want to develop a driver for it. It would be nice if I can develop the driver with a USB-UART and then use it on my embedded system. There are usb-serial devices, which could benefit from support btw. I would find it really useful, if the Dangerous Prototype's Bus Pirate would expose native /dev/i2c and /dev/spi and it's based on FT232. > So to me it looks as if you need to develop different low-level > drivers anyways. No. You say, that option b) is irrelevant and assume, that every serial chip also has native USB support. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-23 01:00 +0200 |
| Message-ID | <s96md-40p-25@gated-at.bofh.it> |
| In reply to | #1468112 |
> There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. That should just need an ldisc. I2C and SPI should at this point be sane for hotplugging as needed for an ldisc. And having an ldisc also has another nice effect. You can plug the bus pirate into a remote machine, run an 8bit clean link over a pty/tty pair half way around the world and get a local i2c/spi to the remote machine's i2c/spi bus pirate ports and devices. It also means that if Bus Pirate 5 changes USB uart nothing breaks. Alan
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2016-08-23 01:20 +0200 |
| Message-ID | <s96FA-4mL-15@gated-at.bofh.it> |
| In reply to | #1468132 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On Mon, Aug 22, 2016 at 11:52:56PM +0100, One Thousand Gnomes wrote: > > There are usb-serial devices, which could benefit from support > > btw. I would find it really useful, if the Dangerous Prototype's > > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > > based on FT232. > > That should just need an ldisc. Right, since it does not need any extra resources. Probably not the best example. > I2C and SPI should at this point be sane for hotplugging as needed > for an ldisc. I guess hotplugging support in the downstream kernel frameworks would be needed anyway with usb-serial being USB based. > And having an ldisc also has another nice effect. You can plug the bus > pirate into a remote machine, run an 8bit clean link over a pty/tty pair > half way around the world and get a local i2c/spi to the remote machine's > i2c/spi bus pirate ports and devices. Right. > It also means that if Bus Pirate 5 changes USB uart nothing breaks. And it means no auto-support. Which would be fine in case of Bus Pirate, since its mainly a developer device and some people may actually prefer the IMHO anoying serial interface. Let's forget that example. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-23 09:30 +0200 |
| Message-ID | <s9ejL-M9-17@gated-at.bofh.it> |
| In reply to | #1468112 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > Am 23.08.2016 um 00:42 schrieb Sebastian Reichel <sre@kernel.org>: > >> I am not a specialist for such things, but I think you have three >> options to connect bluetooth: >> >> a) SoC-UART <-> BT-Chip-UART-port >> b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port >> c) USB <-> BT-Chip-USB-port (not UART involved at all) >> >> Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected >> through USB and plugging it into a non-embedded USB port does not automatically >> show it as a tty interface. So you can't use it for testing the UART drivers. >> >> BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and >> one for USB. So they are also not exchangeable. > > Yes, let's ignore option c). > I'm talking about UART only. If the > chip has native USB support, then that's a different driver. Exactly. > >> Variant b) is IMHO of no practical relevance (but I may be wrong) >> because it would mean to add some costly FT232 or PL2302 chip >> where a different firmware variant works with direct USB >> connection. > > Well for some chips there is not native USB support. But my scenario > was about development. Let's say I have a serial-chip and I want to > develop a driver for it. It would be nice if I can develop the > driver with a USB-UART Yes it would be nice, but is this a thing with significant practical relevance? Usually you have to write drivers for a complete device where the slave chip is already wired up to a SoC-UART. Sometimes you can get a bare chip where you can connect to an USB-UART. But someone has to design that piece of special hardware for you. If you are really lucky there is an evaluation board. And in that case I would use a RasPi or BeagleBone and tie up directly to some SoC-UART instead of using an intermediate USB-UART adapter. Because it is more close to timing relations to the final SoC based design. > and then use it on my embedded system. > > There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. Oh, that is an interesting device I didn't know yet. > >> So to me it looks as if you need to develop different low-level >> drivers anyways. > > No. You say, that option b) is irrelevant and assume, that every > serial chip also has native USB support. I just assume that b) is rarely used because there are alternatives. Although it would be a nice option. Anyways, while following the discussion this is not the most important facet of the overall topic. BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-19 13:10 +0200 |
| Message-ID | <s7PQu-4Rb-9@gated-at.bofh.it> |
| In reply to | #1466190 |
> If possible, please do a callback for every character that arrives. > And not only if the rx buffer becomes full, to give the slave driver > a chance to trigger actions almost immediately after every character. > This probably runs in interrupt context and can happen often. We don't realistically have the clock cycles to do that on a low end embedded processor handling high speed I/O. The best you can do is trigger a workqueue to switch the buffer data around and call the helper while the uart may be receiving more bytes. What you are asking for you'd get out of the first parts of tidying up the receive paths because you'd set a different port->rx() method and get bursts of characters, flags and length data. Alan
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-19 19:50 +0200 |
| Message-ID | <s7W5A-aY-11@gated-at.bofh.it> |
| In reply to | #1466291 |
> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > >> If possible, please do a callback for every character that arrives. >> And not only if the rx buffer becomes full, to give the slave driver >> a chance to trigger actions almost immediately after every character. >> This probably runs in interrupt context and can happen often. > > We don't realistically have the clock cycles to do that on a low end > embedded processor handling high speed I/O. well, if we have a low end embedded processor and high-speed I/O, then buffering the data before processing doesn't help either since processing still will eat up clock cycles. > The best you can do is > trigger a workqueue to switch the buffer data around and call the helper > while the uart may be receiving more bytes. Ok, assuming DMA double buffering might (almost) double throughput. The question is if this is needed at all. If we have a bluetooth stack with HCI the fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. framing means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide if the byte should go to a buffer or not, check checksums, or discard and move the protocol engine to a different state. This is what I assume would be done in a callback. No processing needing some ms per frame. > > What you are asking for you'd get out of the first parts of tidying up > the receive paths because you'd set a different port->rx() method and get > bursts of characters, flags and length data. > > Alan
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-20 15:30 +0200 |
| Message-ID | <s8evv-3Bs-3@gated-at.bofh.it> |
| In reply to | #1466585 |
On Fri, 19 Aug 2016 19:42:37 +0200 "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > > > >> If possible, please do a callback for every character that arrives. > >> And not only if the rx buffer becomes full, to give the slave driver > >> a chance to trigger actions almost immediately after every character. > >> This probably runs in interrupt context and can happen often. > > > > We don't realistically have the clock cycles to do that on a low end > > embedded processor handling high speed I/O. > > well, if we have a low end embedded processor and high-speed I/O, then > buffering the data before processing doesn't help either since processing > still will eat up clock cycles. Of course it helps. You are out of the IRQ handler within the 9 serial clocks, so you can take another interrupt and grab the next byte. You will also get benefits from processing the bytes further in blocks, and if you get too far behind you'll make the flow control limit. You've also usually got multiple cores these days - although not on the very low end quite often. > The question is if this is needed at all. If we have a bluetooth stack with HCI the > fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. framing > means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide > if the byte should go to a buffer or not, check checksums, or discard and move > the protocol engine to a different state. This is what I assume would be done in > a callback. No processing needing some ms per frame. That depends on the processor - remember people run Linux on low end CPUs including those embedded in an FPGA not just high end PC and ARM class devices. The more important question is - purely for the receive side of things - is a callback which guarantees to be called "soon" after the bytes arrive sufficient. If it is then almost no work is needed on the receive side to allow pure kernel code to manage recevied data directly because the current buffering support throughout the receive side is completely capable of providing those services without a tty structure, and to anything which can have a tty attached. Doesn't solve transmit or configuration but it's one step that needs no additional real work and re-invention. Alan
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-08-21 10:00 +0200 |
| Message-ID | <s8vPI-5WQ-15@gated-at.bofh.it> |
| In reply to | #1466814 |
> Am 20.08.2016 um 15:22 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > > On Fri, 19 Aug 2016 19:42:37 +0200 > "H. Nikolaus Schaller" <hns@goldelico.com> wrote: > >>> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: >>> >>>> If possible, please do a callback for every character that arrives. >>>> And not only if the rx buffer becomes full, to give the slave driver >>>> a chance to trigger actions almost immediately after every character. >>>> This probably runs in interrupt context and can happen often. >>> >>> We don't realistically have the clock cycles to do that on a low end >>> embedded processor handling high speed I/O. >> >> well, if we have a low end embedded processor and high-speed I/O, then >> buffering the data before processing doesn't help either since processing >> still will eat up clock cycles. > > Of course it helps. You are out of the IRQ handler within the 9 serial > clocks, so you can take another interrupt and grab the next byte. You > will also get benefits from processing the bytes further in blocks, if there are benefits from processing blocks. That depends on the specific protocol. My proposal can still check and then place byte by byte in a buffer and almost immediately return from interrupt. Until a block is completed and then trigger processing outside of the interrupt context. > and if you get too far behind you'll make the flow control limit. > > You've also usually got multiple cores these days - although not on the > very low end quite often. Indeed. But low-end rarely has really high-speed requirements and then should also run Linux. If it goes to performance limits, probably some assembler code will be used. And UART is inherently slow compared to SPI or USB or Ethernet. > >> The question is if this is needed at all. If we have a bluetooth stack with HCI the >> fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. framing >> means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide >> if the byte should go to a buffer or not, check checksums, or discard and move >> the protocol engine to a different state. This is what I assume would be done in >> a callback. No processing needing some ms per frame. > > That depends on the processor - remember people run Linux on low end CPUs > including those embedded in an FPGA not just high end PC and ARM class > devices. > > The more important question is - purely for the receive side of things - > is a callback which guarantees to be called "soon" after the bytes arrive > sufficient. > > If it is then almost no work is needed on the receive side to allow pure > kernel code to manage recevied data directly because the current > buffering support throughout the receive side is completely capable of > providing those services without a tty structure, and to anything which > can have a tty attached. Let me ask a question about your centralized and pre-cooked buffering approach. As far as I see, even then the kernel API must notify the driver at the right moment that a new block has arrived. Right? But how does the kernel API know how long such a block is? Usually there is a start byte/character, sometimes a length indicator, then payload data, some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n. For other serial protocols it might be AT, no length, and \r. Or something different. HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length. So this means each protocol has a different block format. How can centralized solution manage such differently formatted blocks? IMHO it can't without help from the device specific slave device driver. Which must therefore be able to see every byte to decide into which category it goes. Which brings us back to the every-byte-interrupt-context callback. This is different from well formatted protocols like SPI or I2C or Ethernet etc. where the controller decodes the frame boundaries and DMA can store the payload data and an interrupt occurs for every received block. So I would even conclude that you usually can't even use DMA based UART receive processing for arbitrary and not well-defined protocols. Or have to assume that the protocol is 100% request-response based and a timeout can tell that no more data will be received - until a new request has been sent. > > Doesn't solve transmit or configuration but it's one step that needs no > additional real work and re-invention. > > Alan BR, Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-08-21 19:20 +0200 |
| Message-ID | <s8EzD-3dF-7@gated-at.bofh.it> |
| In reply to | #1466945 |
> Let me ask a question about your centralized and pre-cooked buffering approach. > > As far as I see, even then the kernel API must notify the driver at the right moment > that a new block has arrived. Right? The low level driver queues words (data byte, flag byte) The buffer processing workqueue picks those bytes from the queue and atomically empties the queue The workqueue involves the receive handler. > But how does the kernel API know how long such a block is? It's as long as the data that has arrived in that time. > Usually there is a start byte/character, sometimes a length indicator, then payload data, > some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n. > For other serial protocols it might be AT, no length, and \r. Or something different. > HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length. It doesn't look for any kind of protocol block headers. The routine invoked by the work queue does any frame recovery. > So I would even conclude that you usually can't even use DMA based UART receive > processing for arbitrary and not well-defined protocols. Or have to assume that the We do, today for bluetooth and other protocols just fine - it's all about data flows not about framing in the protocol sense. Alan
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | linux.kernel
csiph-web