linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: boris.brezillon@bootlin.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
Date: Tue, 7 Aug 2018 19:47:22 +0200	[thread overview]
Message-ID: <20180807194722.5aabb6da@bbrezillon> (raw)
In-Reply-To: <11711552.OvaP4pOjBH@z50>

Hi Janusz,

On Tue, 07 Aug 2018 19:29:53 +0200
Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:

> On Tuesday, August 7, 2018 1:43:56 AM CEST Linus Walleij wrote:
> > On Tue, Aug 7, 2018 at 12:29 AM Janusz Krzysztofik <jmkrzyszt@gmail.com>   
> wrote:
> > 
> > Hi Janusz!
> >   
> > > Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> > > information on a single GPIO chip driving array member pins in hardware
> > > order.  In such cases, bitmaps of values can be passed directly to the
> > > chip callback functions without wasting time on iterations.
> > >
> > > Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> > >
> > > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>  
> > 
> > I think it would be disappointing to leave all the users of the old
> > array API without the performance improvement. I think we need to
> > deal with this in a way such that everyone can benefit from it.  

I agree with Linus on that one. When I initially proposed the gpio
bitbanging API I had something more advanced in mind where the GPIO
framework would be responsible for toggling the GPIOs on its own when
it's given an array of bytes to transmit (this way you avoid going
back and forth between the GPIO user and the GPIO framework). But this
approach would clearly be more invasive than what you propose
here (turning the int array into a bitmap and optimizing). So, if we go
for the "int array -> bitmap" approach I think all users should be
converted so that we end up with a single API.

> 
> There are a few issues to be resolved:
> 
> 1) array size limited by bitmap size:
>     - are we ready to limit array size to a single bitmap for all users?
>     - if not, how can we pass a bitmap of an arbitrary size?
>     - if as an array of bitmaps, is that still clear enough and easy to use?
>     - other ideas?

What we call a bitmap is an array of unsigned longs each entry
containing NBITS_PER_LONG bits, so yes, it's an arbitrary size (see the
bitmap API here [1]).

> 
> 2) arbitrary array support:
>      - are we ready to drop that?
>      - if not, do we agree to require all users to pack their arbitrary arrays 
>         inside the gpio_descs structure?

I could only find one user, and it's the core itself (for the ioctl),
so that shouldn't be too hard to convert all users. Did you find more.

> 
> Maybe more.
> 
> > Also it is kludgy if users (consumers) would need to handle the case
> > where all lines are on the same chip separately, through the bitmap
> > API.  
> 
> Not true as long as array size fits (arbitrary arrays can be packed by users), 
> but I see your point.

I think the API should be the same and the framework should decide to
take the fast path if all gpios belong to the same chip (which AFAICT
is already the case, except it's putting the result in an int array
instead of a bitmap)

> 
> > What we need is an API that:
> > 
> > - All drivers handling arrays can use (including current users).
> > 
> > - Enables speed-up if the lines are all on the same chip/register.
> > 
> > - Doesn't require consumers to know if they are all on the same
> >   chip or not.
> > 
> > This means a deep API with a small surface.
> > 
> > How do we achieve this the best way?  
> 
> I think widely accepted solutions to those two issues I've mentioned above can 
> give the answer.

I'd still like to see how far we are from the initial perfs (the one
poking the GPIO regs directly) with this approach, and what's the
improvement compared to the int array solution we already have in place.

Regards,

Boris

[1]https://elixir.bootlin.com/linux/v4.18-rc8/source/include/linux/bitmap.h

  reply	other threads:[~2018-08-07 17:47 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18 23:57 [RFC PATCH 0/8] mtd: rawnand: ams-delta: Use gpio-omap accessors for data I/O Janusz Krzysztofik
2018-07-18 23:57 ` [RFC PATCH 1/8] mtd: rawnand: ams-delta: Use private structure Janusz Krzysztofik
2018-07-19  6:17   ` Boris Brezillon
2018-07-20 17:57     ` Janusz Krzysztofik
2018-07-18 23:57 ` [RFC PATCH 2/8] mtd: rawnand: ams-delta: Write protect device during probe Janusz Krzysztofik
2018-07-19  6:22   ` Boris Brezillon
2018-07-20 18:02     ` Janusz Krzysztofik
2018-07-18 23:57 ` [RFC PATCH 3/8] mtd: rawnand: ams-delta: Set port direction once per transfer Janusz Krzysztofik
2018-07-19  6:23   ` Boris Brezillon
2018-07-20 18:12     ` Janusz Krzysztofik
2018-07-20 19:29       ` Boris Brezillon
2018-07-18 23:57 ` [RFC PATCH 4/8] mtd: rawnand: ams-delta: Optimize pointer resolution on read/write Janusz Krzysztofik
2018-07-19  6:25   ` Boris Brezillon
2018-07-20 18:14     ` Janusz Krzysztofik
2018-07-20 19:29       ` Boris Brezillon
2018-07-18 23:57 ` [RFC PATCH 5/8] mtd: rawnand: ams-delta: Request data port GPIO resource Janusz Krzysztofik
2018-07-19  6:28   ` Boris Brezillon
2018-07-18 23:57 ` [RFC PATCH 6/8] gpio: omap: Add get/set_multiple() callbacks Janusz Krzysztofik
2018-07-29 20:29   ` Linus Walleij
2018-08-03  1:52     ` Grygorii Strashko
2018-08-03 16:47   ` Linus Walleij
2018-07-18 23:57 ` [RFC PATCH 7/8] mtd: rawnand: ams-delta: Check sanity of data GPIO resource Janusz Krzysztofik
2018-07-19  6:44   ` Boris Brezillon
2018-07-29 20:36     ` Linus Walleij
2018-07-29 21:16       ` Boris Brezillon
2018-07-29 20:33   ` Linus Walleij
2018-07-18 23:57 ` [RFC PATCH 8/8] mtd: rawnand: ams-delta: Use GPIO callbacks for data I/O Janusz Krzysztofik
2018-07-19  6:47   ` Boris Brezillon
2018-07-20 18:38     ` Janusz Krzysztofik
2018-07-20 19:48       ` Boris Brezillon
2018-07-19  6:15 ` [RFC PATCH 0/8] mtd: rawnand: ams-delta: Use gpio-omap accessors " Boris Brezillon
2018-07-20 17:55   ` Janusz Krzysztofik
2018-07-20 19:25     ` Boris Brezillon
2018-08-06 22:29 ` [RFC PATCH v2] mtd: rawnand: ams-delta: Use GPIO API " Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 01/12] mtd: rawnand: ams-delta: Assign mtd->dev.parent, not mtd->owner Janusz Krzysztofik
2018-08-06 23:54     ` Marek Vasut
2018-08-07 21:55       ` Janusz Krzysztofik
2018-08-07 16:57     ` Boris Brezillon
2018-08-06 22:29   ` [RFC PATCH v2 02/12] mtd: rawnand: ams-delta: Use private structure Janusz Krzysztofik
2018-08-07 16:59     ` Boris Brezillon
2018-08-06 22:29   ` [RFC PATCH v2 03/12] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port Janusz Krzysztofik
2018-08-07 16:59     ` Boris Brezillon
2018-08-10 10:10     ` Linus Walleij
2018-08-06 22:29   ` [RFC PATCH v2 04/12] mtd: rawnand: ams-delta: request data port GPIO resource Janusz Krzysztofik
2018-08-07 17:00     ` Boris Brezillon
2018-08-10 10:11     ` Linus Walleij
2018-08-06 22:29   ` [RFC PATCH v2 05/12] mtd: rawnand: ams-delta: use GPIO API for data read/write Janusz Krzysztofik
2018-08-06 23:57     ` Marek Vasut
2018-08-07 17:06     ` Boris Brezillon
2018-08-07 17:11       ` Janusz Krzysztofik
2018-08-10 10:25     ` Linus Walleij
2018-08-06 22:29   ` [RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 07/12] mtd: rawnand: ams-delta: Set port direction once per transfer Janusz Krzysztofik
2018-08-07 18:57     ` Boris Brezillon
2018-08-08 16:55       ` Janusz Krzysztofik
2018-08-08 17:42         ` Miquel Raynal
2018-08-06 22:29   ` [RFC PATCH v2 08/12] mtd: rawnand: ams-delta: Simplify pointer resolution on read/write Janusz Krzysztofik
2018-08-07 17:02     ` Boris Brezillon
2018-08-07 17:15       ` Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct mapping Janusz Krzysztofik
2018-08-06 23:29     ` Linus Walleij
2018-08-07 16:50       ` Janusz Krzysztofik
2018-08-07 17:10         ` Boris Brezillon
2018-08-07 17:14     ` Boris Brezillon
2018-08-07 17:19       ` Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension Janusz Krzysztofik
2018-08-06 22:29   ` [RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions Janusz Krzysztofik
2018-08-06 23:43     ` Linus Walleij
2018-08-07 17:29       ` Janusz Krzysztofik
2018-08-07 17:47         ` Boris Brezillon [this message]
2018-08-10 10:55           ` Linus Walleij
2018-08-13 22:34   ` [PATCH v3 0/7] mtd: rawnand: ams-delta: Use GPIO API for data I/O Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 1/7] mtd: rawnand: ams-delta: show parent device in sysfs Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 2/7] mtd: rawnand: ams-delta: Use private structure Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 3/7] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 4/7] mtd: rawnand: ams-delta: request data port GPIO resource Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 5/7] mtd: rawnand: ams-delta: Set port direction when needed Janusz Krzysztofik
2018-08-16  7:30       ` Boris Brezillon
2018-08-13 22:34     ` [PATCH v3 6/7] mtd: rawnand: ams-delta: Simplify pointer resolution on read/write Janusz Krzysztofik
2018-08-13 22:34     ` [PATCH v3 7/7] mtd: rawnand: ams-delta: use GPIO API for data I/O Janusz Krzysztofik
2018-08-16  7:39       ` Boris Brezillon
2018-11-21 11:08     ` Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use " Janusz Krzysztofik
2018-11-21 11:08       ` [PATCH v4 1/4] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port Janusz Krzysztofik
2018-11-23 17:02         ` Tony Lindgren
2018-11-21 11:08       ` [PATCH v4 2/4] mtd: rawnand: ams-delta: Request data port GPIO resource Janusz Krzysztofik
2018-11-21 11:08       ` [PATCH v4 3/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O Janusz Krzysztofik
2018-11-21 14:53         ` Boris Brezillon
2018-11-21 11:08       ` [PATCH v4 4/4] ARM: OMAP1: ams-delta: Drop obsolete NAND resources Janusz Krzysztofik
2018-11-21 14:56       ` Subject: [PATCH v4 0/4] mtd: rawnand: ams-delta: Use GPIO API for data I/O Boris Brezillon
2018-11-23 17:03         ` Tony Lindgren
2018-12-07  8:04           ` Miquel Raynal
2018-12-07 16:10             ` Tony Lindgren

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=20180807194722.5aabb6da@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).