Hi,
On 04/10/12 01:07, Linus Walleij wrote:
>> What do others think? JC? Linus? I'm considering this (unsigned int
>> data) a valid option.
>
> I think we mostly use an unsigned long for such stuff as IRQ flags
> and ioctl() parameters in the kernel.
>
> In this case it has the upside that it wi
On Sun, Sep 30, 2012 at 5:46 PM, Roland Stigge wrote:
> On 30/09/12 17:19, Stijn Devriendt wrote:
>>
>> Rules are rules, but why make the interface overly complex when
>> the multi-value file is saner, cleaner and simpler?
>
> Simply because they won't (and probably shouldn't) accept it mainline.
On Sun, Sep 30, 2012 at 12:50 PM, Roland Stigge wrote:
> Besides what I discussed with JC and Linus, I find the unsigned int
> (i.e. u32 or u64, depending on the arch) quite appealing. It is a nice
> compromise between my general bit mapped data model (variable size *u8
> array) and the bool *val
On Thu, Sep 27, 2012 at 11:22:02PM +0200, 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
On 30/09/12 17:19, Stijn Devriendt wrote:
>> If I understand correctly, it's a violation (single-value should hold
>> for read and write).
>>
>> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/
>> contains files "bit0" ... "bit31" which contain a gpio number each,
>> empty if "unco
On Sun, Sep 30, 2012 at 5:09 PM, Roland Stigge wrote:
> Hi Stijn,
>
> On 30/09/12 16:52, Stijn Devriendt wrote:
>>> One question: How did you solve the one-value-per-file in the sysfs
>>> interface?
>>>
>> By exporting the group as a whole:
>> /sys/.../gpiogroup248/value
>> where value contains a
On Sun, Sep 30, 2012 at 12:34 PM, Roland Stigge wrote:
> 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
Hi Stijn,
On 30/09/12 16:52, Stijn Devriendt wrote:
>> One question: How did you solve the one-value-per-file in the sysfs
>> interface?
>>
> By exporting the group as a whole:
> /sys/.../gpiogroup248/value
> where value contains a decimal representing the group value.
> Again, this respects the o
On Sun, Sep 30, 2012 at 12:50 PM, Roland Stigge wrote:
> On 30/09/12 11:35, Stijn Devriendt wrote:
>> In our kernel tree we have similar code. If you like I can request
>> permission
>> to share. I can, however, already give you an update on the basic
>> structure, perhaps
>> it's useful now.
>>
>
On 30/09/12 11:35, Stijn Devriendt wrote:
> In our kernel tree we have similar code. If you like I can request
> permission
> to share. I can, however, already give you an update on the basic
> structure, perhaps
> it's useful now.
>
> For the first part, the drivers need to implement a the gpio i
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
> g
On Thu, Sep 27, 2012 at 11:22 PM, 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 G
On 20:32 Fri 28 Sep , Roland Stigge wrote:
> Hi,
>
> On 28/09/12 18:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>Maybe like this, for some struct block *?
> >>
> >>block = set_block_prepare(gc, pins, values, size);
> >>if (block) {
> >>set_block(gc, block);
> >>...
> >>set_block
Hi,
On 28/09/12 18:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
Maybe like this, for some struct block *?
block = set_block_prepare(gc, pins, values, size);
if (block) {
set_block(gc, block);
...
set_block_unprepare(gc, block);
}
Would mean that all supported drivers wou
On 13:32 Fri 28 Sep , Roland Stigge wrote:
> On 09/28/2012 12:28 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> gpio0 = {1};
> >> set0 = {1};
> >>
> >> gpio1 = {33, 34};
> > here should be
> >
> > pin0 = {1};
> > set0 = {1};
> >
> > pin1 = {1, 2, 23};
> > set1 = {0, 0, 1};
> >
> > set_bloc
On 11:08 Fri 28 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:51 Fri 28 Sep , Roland Stigge wrote:
> > Hi!
> >
> > On 09/28/2012 09:51 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >> Right - will add checking for the request state of the respective GPIOs.
> > >>
> > >> The list
Hi,
On 09/28/2012 01:34 PM, Linus Walleij wrote:
>> Or some kind of new character device node?
>
> Yes, I don't know if we should create /dev/gpioN or /dev/pinctrlN for
> this, and add GPIO functions to pinctrl (while wrapping it in the
> gpiolib to aid migration) the latter would encourage users
On Fri, Sep 28, 2012 at 11:52 AM, Roland Stigge wrote:
> It's hard to do the one-value-per-file right for a several-gpios-at-once
> goal. :-)
That's true. This is one of the reasons I think GPIO chips should
be /dev/gpioN device nodes and this business be handled by
ioctl():s instead, it is hard
On 09/28/2012 12:28 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> gpio0 = {1};
>> set0 = {1};
>>
>> gpio1 = {33, 34};
> here should be
>
> pin0 = {1};
> set0 = {1};
>
> pin1 = {1, 2, 23};
> set1 = {0, 0, 1};
>
> set_blocks(gpio_chip0, pin0, set0, 1);
> set_blocks(gpio_chip1, pin1, set1, 3);
>
On 09/28/2012 11:14 AM, Linus Walleij wrote:
>> @@ -686,6 +731,13 @@ read-only attributes:
>>
>> "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
>>
>> + "block" ... get/set Block GPIO:
>> + * reads: space separated list of GPIO inputs of this
>> chip tha
On 09/28/2012 11:08 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Good idea! Talking about the public API (your above gpio_set_block()):
>> *gpios is a list of GPIOs, but set is still bitmapped (mapped onto the
>> list specified in *gpios)? To prevent confusion about what the size
>> argument mean
On Thu, Sep 27, 2012 at 11:22 PM, Roland Stigge wrote:
Grant really need to look at this patch too...
> 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
On 10:51 Fri 28 Sep , Roland Stigge wrote:
> Hi!
>
> On 09/28/2012 09:51 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> Right - will add checking for the request state of the respective GPIOs.
> >>
> >> The list of GPIOs to handle is defined by the offset (specified GPIO)
> >> and bitmapped
Hi!
On 09/28/2012 09:51 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Right - will add checking for the request state of the respective GPIOs.
>>
>> The list of GPIOs to handle is defined by the offset (specified GPIO)
>> and bitmapped list.
>>
>> If it looks more natural, I can change this to a
On 09:14 Fri 28 Sep , Roland Stigge wrote:
>
> Hi!
>
> On 09/28/2012 04:47 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> +Block GPIO (optional)
> >> +-
> >> +
> >> +The above described interface concentrates on handling single GPIOs.
> >> However,
> >> +in application
Hi!
On 09/28/2012 04:47 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> +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
>> +interf
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 sa
27 matches
Mail list logo
