From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Roland Stigge <stigge@antcom.de>
Cc: grant.likely@secretlab.ca, linus.walleij@linaro.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, w.sang@pengutronix.de,
jbe@pengutronix.de
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
Date: Fri, 28 Sep 2012 04:47:44 +0200 [thread overview]
Message-ID: <20120928024744.GV17667@game.jcrosoft.org> (raw)
In-Reply-To: <1348780923-27428-1-git-send-email-stigge@antcom.de>
On 23:22 Thu 27 Sep , Roland Stigge wrote:
> The recurring task of providing simultaneous access to GPIO lines (especially
> for bit banging protocols) needs an appropriate API.
>
> This patch adds a kernel internal "Block GPIO" API that enables simultaneous
> access to several GPIOs in the same gpio_chip (bit mapped). Further, it adds a
> sysfs interface (/sys/class/gpio/gpiochipXX/block).
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
>
> ---
> NOTE: This is only useful if individual drivers implement the .get_block() and
> .set_block() functions. I'm providing an example implementation for max730x
> (see next patch), and can provide further driver patches after API review.
>
> Thanks in advance!
>
> Documentation/gpio.txt | 52 +++++++++++++++++++
> drivers/gpio/gpiolib.c | 121 +++++++++++++++++++++++++++++++++++++++++++++
> include/asm-generic/gpio.h | 7 ++
> include/linux/gpio.h | 24 ++++++++
> 4 files changed, 204 insertions(+)
>
> --- linux-2.6.orig/Documentation/gpio.txt
> +++ linux-2.6/Documentation/gpio.txt
> @@ -439,6 +439,51 @@ slower clock delays the rising edge of S
> signaling rate accordingly.
>
>
> +Block GPIO (optional)
> +---------------------
> +
> +The above described interface concentrates on handling single GPIOs. However,
> +in applications where it is critical to set several GPIOs at once, this
> +interface doesn't work well, e.g. bit-banging protocols via GPIO lines.
> +Consider a GPIO controller that is connected via a slow I2C line. When
> +switching two or more GPIOs one after another, there can be considerable time
> +between those events. This is solved by an interface called Block GPIO:
> +
> +void gpio_get_block(unsigned int gpio, u8* values, size_t size);
> +void gpio_set_block(unsigned int gpio, u8* set, u8* clr, size_t size);
> +
> +The function gpio_get_block() detects the current state of several GPIOs at
> +once, practically by doing only one query at the hardware level (e.g. memory
> +mapped or via bus transfers like I2C). There are some limits to this interface:
> +A certain gpio_chip (see below) must be specified via the gpio parameter as the
> +first GPIO in the gpio_chip group. The Block GPIO interface only supports
> +simultaneous handling of GPIOs in the same gpio_chip group since different
> +gpio_chips typically map to different GPIO hardware blocks.
so basicaly you use a gpio numberthat you do not request, that is maybe
requested. This is broken if you want to get or set block you need to pass the
list of GPIO you want to control not some fancy magic
Otherwise this will end be broken code.
And how you can hope to describe this via DT
Best Regards,
J.
next prev parent reply other threads:[~2012-09-28 3:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
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-28 2:47 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2012-09-28 7:14 ` [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib Roland Stigge
2012-09-28 7:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 8:51 ` Roland Stigge
2012-09-28 9:08 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 9:23 ` Roland Stigge
2012-09-28 10:28 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 11:32 ` Roland Stigge
2012-09-28 16:01 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-28 18:32 ` Roland Stigge
2012-09-29 19:57 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-30 10:34 ` Roland Stigge
2012-09-30 15:11 ` Stijn Devriendt
2012-09-28 9:14 ` Linus Walleij
2012-09-28 9:52 ` Roland Stigge
2012-09-28 11:34 ` Linus Walleij
2012-09-28 12:35 ` Roland Stigge
[not found] ` <CAOY=C6GG6jqqEAAGJjmDG-BFT2eq=9+ck+F_EOcthRgDCDv8=Q@mail.gmail.com>
2012-09-30 9:39 ` Stijn Devriendt
2012-09-30 10:50 ` Roland Stigge
2012-09-30 14:52 ` Stijn Devriendt
2012-09-30 15:09 ` Roland Stigge
2012-09-30 15:19 ` Stijn Devriendt
2012-09-30 15:46 ` Roland Stigge
2012-10-03 23:11 ` Linus Walleij
2012-10-03 23:07 ` Linus Walleij
2012-10-04 20:25 ` Roland Stigge
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=20120928024744.GV17667@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=grant.likely@secretlab.ca \
--cc=jbe@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stigge@antcom.de \
--cc=w.sang@pengutronix.de \
/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
Powered by JetHome