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: Sun, 21 Aug 2016 20:23:10 +0200 [thread overview] Message-ID: <FF7761E8-377A-43AD-96B2-83BA140E030B@goldelico.com> (raw) In-Reply-To: <20160821180910.51cf919d@lxorguk.ukuu.org.uk> > Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > >> 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 When and how fast is the work queue scheduled? And by which event? > The workqueue involves the receive handler. This should be faster than if a driver directly processes incoming bytes? > >> 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. Which means the work queue handler have to decide if it is enough for a frame to decode and if not, wait a little until more arrives. Or you have to assemble chunks into a frame, i.e. copy data around. Both seems a waste of scarce cpu cycles in high-speed situations to me. > >> 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. Which might become the pitfall of the design because as I have described it is an essential part of processing UART based protocols. You seem to focus on efficiently buffering only but not about efficiently processing the queued data. > 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 I think it works (even with user-space HCI daemon) because bluetooth HCI is slow (<300kByte/s). > - it's all about > data flows not about framing in the protocol sense. Yes, but you should also take framing into account for a solution that helps to implement UART slave devices. That is my concern. BR, Nikolaus
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: Sun, 21 Aug 2016 20:23:10 +0200 [thread overview] Message-ID: <FF7761E8-377A-43AD-96B2-83BA140E030B@goldelico.com> (raw) In-Reply-To: <20160821180910.51cf919d@lxorguk.ukuu.org.uk> > Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes = <gnomes@lxorguk.ukuu.org.uk>: >=20 >> Let me ask a question about your centralized and pre-cooked buffering = approach. >>=20 >> 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? >=20 > 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 When and how fast is the work queue scheduled? And by which event? > The workqueue involves the receive handler. This should be faster than if a driver directly processes incoming = bytes? >=20 >> But how does the kernel API know how long such a block is? >=20 > It's as long as the data that has arrived in that time. Which means the work queue handler have to decide if it is enough for a frame to decode and if not, wait a little until more arrives. Or you have to assemble chunks into a frame, i.e. copy data around. Both seems a waste of scarce cpu cycles in high-speed situations to me. >=20 >> 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. >=20 > It doesn't look for any kind of protocol block headers. Which might become the pitfall of the design because as I have described = it is an essential part of processing UART based protocols. You seem to focus on = efficiently buffering only but not about efficiently processing the queued data. > The routine > invoked by the work queue does any frame recovery. >=20 >> 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 >=20 > We do, today for bluetooth and other protocols just fine I think it works (even with user-space HCI daemon) because bluetooth HCI = is slow (<300kByte/s). > - it's all about > data flows not about framing in the protocol sense. Yes, but you should also take framing into account for a solution that = helps to implement UART slave devices. That is my concern. BR, Nikolaus=
next prev parent reply other threads:[~2016-08-21 18:23 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 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 [this message] 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=FF7761E8-377A-43AD-96B2-83BA140E030B@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.