<div class="gmail_quote">On Thu, Sep 27, 2012 at 11:22 PM, Roland Stigge <span dir="ltr"><<a href="mailto:stigge@antcom.de" target="_blank">stigge@antcom.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The recurring task of providing simultaneous access to GPIO lines (especially<br>
for bit banging protocols) needs an appropriate API.<br>
<br>
This patch adds a kernel internal "Block GPIO" API that enables simultaneous<br>
access to several GPIOs in the same gpio_chip (bit mapped). Further, it adds a<br>
sysfs interface (/sys/class/gpio/gpiochipXX/block).<br>
<br>
Signed-off-by: Roland Stigge <<a href="mailto:stigge@antcom.de">stigge@antcom.de</a>><br>
<br>
---<br>
NOTE: This is only useful if individual drivers implement the .get_block() and<br>
.set_block() functions. I'm providing an example implementation for max730x<br>
(see next patch), and can provide further driver patches after API review.<br>
<br>
Thanks in advance!<br><br></blockquote><div><br>Hi Roland,<br><br>In our kernel tree we have similar code. If you like I can request permission<br>to share. I can, however, already give you an update on the basic structure, perhaps<br>
it's useful now.<br><br>For the first part, the drivers need to implement a the gpio interface for groups.<br>gpio_set_multi, gpio_get_multi, gpio_direction_input_multi, <br>gpio_direction_output_multi. Each of them gets a 'u32 mask'.<br>
<br>Secondly, gpiolib gets some new code to handle groups:<br>groups are requested via a list of gpio ids. Mind that order is respected:<br>request( [1, 5, 2, 4] ) followed by a set(0x5) will translate to <br>gpio_set_multi( 0x18 ). An opaque gpio_group struct is used to keep track.<br>
This means the gpiolib interface also has a u32 mask, but translation is<br>done for the gpio-drivers.<br><br>There is some code to request groups via device-tree (again respecting order)<br>and there are also platform driver structures.<br>
<br>gpiolib was also extended to export groups into sysfs, respecting policy<br>(input, output, user-selectable) and to make softlinks to groups in other<br>driver's subdir. (One driver we use this in is a power-sequencer with 2<br>
gpios selecting a margining profile, this driver then has the gpio_group<br>exported in it's sysfs dir as .../profile, allowing H/W engineers to select<br>the profile without voltage glitches)<br><br>There's also a separate driver, that does nothing more than exporting<br>
both individual pins and groups to userspace based on platform description<br>or devicetree. This is probably less interesting for mainline, since we're<br>abusing device-tree to do away with some init script that can do the same.<br>
<br>The rationale behind a 32bit mask is that typical processors can at most<br>set one processor-word worth of GPIOs at once and there are probably<br>few chips with over 32GPIOs on a single gpio_chip anyway.<br>Nevertheless, in the era of 64bit, it's definitely possible to go for u64 instead.<br>
<br>Let me know if this looks like something usable to you.<br><br>Regards,<br>Stijn<br></div></div>