From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755475AbcHSRmu (ORCPT ); Fri, 19 Aug 2016 13:42:50 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.161]:27541 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755268AbcHSRmr (ORCPT ); Fri, 19 Aug 2016 13:42:47 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6lSGtGsaxaXmwxFVAKQfU X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC PATCH 0/3] UART slave device bus From: "H. Nikolaus Schaller" In-Reply-To: <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> Date: Fri, 19 Aug 2016 19:42:37 +0200 Cc: Sebastian Reichel , Rob Herring , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Pavel Machek , Peter Hurley , NeilBrown , Arnd Bergmann , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Message-Id: <61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com> References: <20160818011445.22726-1-robh@kernel.org> <20160818202900.hyvm4hfxedifuefn@earth> <20160819052125.ze5zilppwoe3f2lx@earth> <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> To: One Thousand Gnomes X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7JHgtPw003006 > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes : > >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC PATCH 0/3] UART slave device bus From: "H. Nikolaus Schaller" In-Reply-To: <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> Date: Fri, 19 Aug 2016 19:42:37 +0200 Cc: Sebastian Reichel , Rob Herring , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Pavel Machek , Peter Hurley , NeilBrown , Arnd Bergmann , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Message-Id: <61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com> References: <20160818011445.22726-1-robh@kernel.org> <20160818202900.hyvm4hfxedifuefn@earth> <20160819052125.ze5zilppwoe3f2lx@earth> <20160819120631.5fe2af0d@lxorguk.ukuu.org.uk> To: One Thousand Gnomes Sender: linux-serial-owner@vger.kernel.org List-ID: > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes = : >=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