From: stigge@antcom.de (Roland Stigge)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
Date: Sun, 30 Sep 2012 12:34:55 +0200 [thread overview]
Message-ID: <5068204F.6090606@antcom.de> (raw)
In-Reply-To: <20120929195754.GC17667@game.jcrosoft.org>
On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Problem here is that it's only an intermediate format since hardware
>> often needs special preparation of the data.
>>
>> But will evaluate what makes most sense.
> the key point here is to avoid to manipualte data each time we call
> gpio_block_set
>
> hardware specific will have to be handle at driver level
Understand, thanks! I'm just trying to prevent overly complex API because:
* In our discussed scheme, the driver still needs to convert the data bits
* In practice, the block gpio API is especially useful for use on single
gpio_chips (only there, a real simultaneous i/o is possible anyway)
* Wouldn't introduce this kind of optimization in lack of measurable
improvement
* The actual i/o data bits still need handling, generating a bit CPU
load anyway.
Trying to provide as simple API as possible.
Roland
WARNING: multiple messages have this Message-ID (diff)
From: Roland Stigge <stigge@antcom.de>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
w.sang@pengutronix.de, grant.likely@secretlab.ca,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
Date: Sun, 30 Sep 2012 12:34:55 +0200 [thread overview]
Message-ID: <5068204F.6090606@antcom.de> (raw)
In-Reply-To: <20120929195754.GC17667@game.jcrosoft.org>
On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Problem here is that it's only an intermediate format since hardware
>> often needs special preparation of the data.
>>
>> But will evaluate what makes most sense.
> the key point here is to avoid to manipualte data each time we call
> gpio_block_set
>
> hardware specific will have to be handle at driver level
Understand, thanks! I'm just trying to prevent overly complex API because:
* In our discussed scheme, the driver still needs to convert the data bits
* In practice, the block gpio API is especially useful for use on single
gpio_chips (only there, a real simultaneous i/o is possible anyway)
* Wouldn't introduce this kind of optimization in lack of measurable
improvement
* The actual i/o data bits still need handling, generating a bit CPU
load anyway.
Trying to provide as simple API as possible.
Roland
next prev parent reply other threads:[~2012-09-30 10:34 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 21:22 [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib Roland Stigge
2012-09-27 21:22 ` Roland Stigge
2012-09-27 21:22 ` [PATCH RFC 2/2] gpio-max730x: Add block GPIO API Roland Stigge
2012-09-27 21:22 ` Roland Stigge
2012-09-28 2:47 ` [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 2:47 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 7:14 ` Roland Stigge
2012-09-28 7:14 ` Roland Stigge
2012-09-28 7:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 7:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 8:51 ` Roland Stigge
2012-09-28 8:51 ` Roland Stigge
2012-09-28 9:08 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 9:08 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 9:23 ` Roland Stigge
2012-09-28 9:23 ` Roland Stigge
2012-09-28 10:28 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 10:28 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 11:32 ` Roland Stigge
2012-09-28 11:32 ` Roland Stigge
2012-09-28 16:01 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 16:01 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 18:32 ` Roland Stigge
2012-09-28 18:32 ` Roland Stigge
2012-09-29 19:57 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-29 19:57 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-30 10:34 ` Roland Stigge [this message]
2012-09-30 10:34 ` Roland Stigge
2012-09-30 15:11 ` Stijn Devriendt
2012-09-30 15:11 ` Stijn Devriendt
2012-09-28 9:14 ` Linus Walleij
2012-09-28 9:14 ` Linus Walleij
2012-09-28 9:52 ` Roland Stigge
2012-09-28 9:52 ` Roland Stigge
2012-09-28 11:34 ` Linus Walleij
2012-09-28 11:34 ` Linus Walleij
2012-09-28 12:35 ` Roland Stigge
2012-09-28 12:35 ` Roland Stigge
2012-09-30 9:35 ` Stijn Devriendt
2012-09-30 9:39 ` Stijn Devriendt
2012-09-30 10:50 ` Roland Stigge
2012-09-30 10:50 ` Roland Stigge
2012-09-30 14:52 ` Stijn Devriendt
2012-09-30 14:52 ` Stijn Devriendt
2012-09-30 15:09 ` Roland Stigge
2012-09-30 15:09 ` Roland Stigge
2012-09-30 15:19 ` Stijn Devriendt
2012-09-30 15:19 ` Stijn Devriendt
2012-09-30 15:46 ` Roland Stigge
2012-09-30 15:46 ` Roland Stigge
2012-10-03 23:11 ` Linus Walleij
2012-10-03 23:11 ` Linus Walleij
2012-10-03 23:07 ` Linus Walleij
2012-10-03 23:07 ` Linus Walleij
2012-10-04 20:25 ` Roland Stigge
2012-10-04 20:25 ` Roland Stigge
2012-10-03 19:08 ` Mark Brown
2012-10-03 19:08 ` Mark Brown
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=5068204F.6090606@antcom.de \
--to=stigge@antcom.de \
--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 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.