linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Miquèl Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Brian Norris" <computersforpeace@gmail.com>,
	"Mark Vasut" <marek.vasut@gmail.com>,
	"ext Tony Lindgren" <tony@atomide.com>,
	"Aaro Koskinen" <aaro.koskinen@iki.fi>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	linux-mtd@lists.infradead.org, linux-doc@vger.kernel.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct mapping
Date: Tue, 7 Aug 2018 19:10:42 +0200	[thread overview]
Message-ID: <20180807191042.0204909a@bbrezillon> (raw)
In-Reply-To: <1793769.2WP40jSPqy@z50>

On Tue, 07 Aug 2018 18:50:22 +0200
Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:

> Hi Linus,
> 
> On Tuesday, August 7, 2018 1:29:43 AM CEST Linus Walleij wrote:
> > Hi Janusz!
> > 
> > On Tue, Aug 7, 2018 at 12:29 AM Janusz Krzysztofik <jmkrzyszt@gmail.com>   
> wrote:
> >   
> > > Certain GPIO array lookup results may map directly to GPIO pins of a
> > > single GPIO chip in hardware order.  If that condition is recognized
> > > and handled efficiently, significant performance gain of get/set array
> > > functions may be possible.
> > >
> > > While processing a request for an array of GPIO descriptors, verify if
> > > the descriptors just collected represent consecutive pins of a single
> > > GPIO chip.  Pass that information with the array to the caller so it
> > > can benefit from enhanced performance as soon as bitmap based get/set
> > > array functions which can make efficient use of that are available.
> > >
> > > Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>  
> > (...)  
> > >  This function returns a struct gpio_descs which contains an array of
> > > -descriptors::
> > > +descriptors.  It may also contain a valid descriptor of a single GPIO   
> chip in
> > > +case the array strictly matches pin hardware layout of the chip::
> > >
> > >         struct gpio_descs {
> > >                 unsigned int ndescs;
> > >                 struct gpio_desc *desc[];
> > > +               struct gpio_chip *chip;  
> > 
> > This must be motivated: if the only purpose is to indicate to the consumer   
> that
> > all GPIOs are on the same chip, why not just have a
> > 
> > bool all_on_same_chip;
> > 
> > That you set to true if these are all on the same chip?  
> 
> My approach would probably save one or two instructions per get/set call, but 
> I'm not stuck to it and will be happy to find a better solution.
> 
> How about folding the chip descriptor inside an additional structure, private 
> to drivers, with internals not revealed to consumers?

Or just get the chip from gpio_descs->desc[0]->gdev->chip when
->all_on_same_chip is true...

That adds 2 dereferencing though.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180718235710.18242-1-jmkrzyszt@gmail.com>
2018-08-06 22:29 ` [RFC PATCH v2] mtd: rawnand: ams-delta: Use GPIO API for data I/O 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 [this message]
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
2018-08-10 10:55           ` Linus Walleij

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=20180807191042.0204909a@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=computersforpeace@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=jmkrzyszt@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tony@atomide.com \
    /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).