From: "H. Nikolaus Schaller" <hns@goldelico.com> To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Sebastian Reichel <sre@kernel.org>, Rob Herring <robh@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, 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>, "open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>, "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Fri, 19 Aug 2016 19:42:37 +0200 [thread overview] Message-ID: <61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com> (raw) In-Reply-To: <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> > 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
WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com> To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Sebastian Reichel <sre@kernel.org>, Rob Herring <robh@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marcel Holtmann <marcel@holtmann.org>, Jiri Slaby <jslaby@suse.com>, 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>, "open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>, "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 0/3] UART slave device bus Date: Fri, 19 Aug 2016 19:42:37 +0200 [thread overview] Message-ID: <61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com> (raw) In-Reply-To: <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes = <gnomes@lxorguk.ukuu.org.uk>: >=20 >> 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. >=20 > 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=C2=B5s 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. >=20 > 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. >=20 > Alan
next prev parent reply other threads:[~2016-08-19 17:42 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 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 [this message] 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=61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com \ --to=hns@goldelico.com \ --cc=arnd@arndb.de \ --cc=gnomes@lxorguk.ukuu.org.uk \ --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.