question on generic gpio interface

question on generic gpio interface

[Francis Moreau]

Hi,

I'm trying to port my old gpio code to the generic one to see if it
can fit my needs.

The gpio controller is a home made one and has a really weird
interface. It has several registers to read the gpio status, to
configure gpio directions, or to configure if a gpio can trigger an
interrupt and on which event (level or edge). All gpios use the same
IRQ and a gpio controller register allows to read which gpio has
triggered the interrupt.

Now the question is how should irq_to_gpio()  work ? Is it supposed to
be called only when a gpio interrupt occure ?

Another question is how can I specify if a gpio interrupt trigger on
level or on edge ?

thanks
-- 
Francis

Re: question on generic gpio interface

[David Brownell]

On Friday 13 April 2007 1:51 pm, Francis Moreau wrote:
> Hi,
> 
> I'm trying to port my old gpio code to the generic one to see if it
> can fit my needs.

Good .. this is more like an IRQ question though.


> The gpio controller is a home made one and has a really weird
> interface. It has several registers to read the gpio status, to
> configure gpio directions, or to configure if a gpio can trigger an
> interrupt and on which event (level or edge). All gpios use the same
> IRQ and a gpio controller register allows to read which gpio has
> triggered the interrupt.

I'll trust you on "weird", but that sounds quite typical in
terms of functionality.  You'll find that most system-on-chip
GPIO controllers act the same way.

IRQ logic on that platform must do a few things, like:

 - NR_IRQS includes the N interrupts triggered from that chip,
   and their numbers probably fit right sometimes after the
   core set of IRQs (which might include SOC GPIO irqs);

 - You'll provide an irq_chip for this controller, and it will
   handle the relevant irq operations (set trigger type, mask,
   unmask etc);

 - When configuring the IRQ handler for that "same IRQ", you'll
   set it up to use a chained handler that you provide, which
   reads the register to see which gpio(s) triggered the IRQ,
   maybe acks it (if just reading that register isn't enough),
   and then calls whatever handler was instaled for that GPIO.

If that's not familiar to you, look at arch/arm/mach-at91/gpio.c
or arch/arm/mach-pxa/irq.c or arch/arm/plat-omap/gpio.c or a
number of other similar files showing how the "toplevel" IRQ
logic will demux from a "one of these N GPIOs" interrupt down
to the handler for that particular IRQ.


> Now the question is how should irq_to_gpio()  work ?

Normally irq_to_gpio() and gpio_to_irq() are simple arithmetic
operations.  If both identifiers start at zero, irq_to_gpio()
would probably subtract a constant, and gpio_to_irq() would add
the same constant.


> Is it supposed to be called only when a gpio interrupt occure ?

It's not the most commonly used operation, and exactly when
it's used would be the choice of whatever code uses it.  That
would be one common answer ... e.g. for GPIOs that only allow
"both edges" triggering, the driver may actually care about the
level so it's got to check that with gpio_get_value().

If the IRQ handler doesn't like the notion of subtracting that
constant at that time, it's easy to cache the answer ahead of
time.  (Though it might not be a net win to spend extra memory
that way.)

 
> Another question is how can I specify if a gpio interrupt trigger on
> level or on edge ?

That's handled in the irq_chip.set_type() method.  See the above
referenced source files for examples.

- Dave


> thanks
> -- 
> Francis
> 

Re: question on generic gpio interface

[Francis Moreau]

Hi David,

Thanks for your detailed answer, it helps a lot !

On 4/14/07, David Brownell <david-b@pacbell.net> wrote:
> On Friday 13 April 2007 1:51 pm, Francis Moreau wrote:
> > Hi,
> >
> > I'm trying to port my old gpio code to the generic one to see if it
> > can fit my needs.
>
> Good .. this is more like an IRQ question though.
>

yeah now it appears to me so...

>
> > The gpio controller is a home made one and has a really weird
> > interface. It has several registers to read the gpio status, to
> > configure gpio directions, or to configure if a gpio can trigger an
> > interrupt and on which event (level or edge). All gpios use the same
> > IRQ and a gpio controller register allows to read which gpio has
> > triggered the interrupt.
>
> I'll trust you on "weird", but that sounds quite typical in
> terms of functionality.  You'll find that most system-on-chip
> GPIO controllers act the same way.
>
> IRQ logic on that platform must do a few things, like:
>
>  - NR_IRQS includes the N interrupts triggered from that chip,
>    and their numbers probably fit right sometimes after the
>    core set of IRQs (which might include SOC GPIO irqs);
>
>  - You'll provide an irq_chip for this controller, and it will
>    handle the relevant irq operations (set trigger type, mask,
>    unmask etc);
>
>  - When configuring the IRQ handler for that "same IRQ", you'll
>    set it up to use a chained handler that you provide, which
>    reads the register to see which gpio(s) triggered the IRQ,
>    maybe acks it (if just reading that register isn't enough),
>    and then calls whatever handler was instaled for that GPIO.
>
> If that's not familiar to you, look at arch/arm/mach-at91/gpio.c
> or arch/arm/mach-pxa/irq.c or arch/arm/plat-omap/gpio.c or a
> number of other similar files showing how the "toplevel" IRQ
> logic will demux from a "one of these N GPIOs" interrupt down
> to the handler for that particular IRQ.
>

I think I got the picture now, thanks again.

Just to be sure I understand, it seems to me that your point 2) and 3)
are 2 different approaches to do the same thing, aren't they ?

If so I can only implement 2) since it seems to me better than the
last one (it better uses genirq layer).

Thanks !
-- 
Francis

Re: question on generic gpio interface

[David Brownell]

On Monday 16 April 2007 3:03 am, Francis Moreau wrote:

> > Good .. this is more like an IRQ question though.
> 
> ...
> 
> > IRQ logic on that platform must do a few things, like:
> >
> >  - NR_IRQS includes the N interrupts triggered from that chip,
> >    and their numbers probably fit right sometime after the
> >    core set of IRQs (which might include SOC GPIO irqs);
> >
> >  - You'll provide an irq_chip for this controller, and it will
> >    handle the relevant irq operations (set trigger type, mask,
> >    unmask etc);
> >
> >  - When configuring the IRQ handler for that "same IRQ", you'll
> >    set it up to use a chained handler that you provide, which
> >    reads the register to see which gpio(s) triggered the IRQ,
> >    maybe acks it (if just reading that register isn't enough),
> >    and then calls whatever handler was instaled for that GPIO.
> >
> > If that's not familiar to you, look at arch/arm/mach-at91/gpio.c
> > or arch/arm/mach-pxa/irq.c or arch/arm/plat-omap/gpio.c or a
> > number of other similar files showing how the "toplevel" IRQ
> > logic will demux from a "one of these N GPIOs" interrupt down
> > to the handler for that particular IRQ.
> >
> 
> I think I got the picture now, thanks again.
> 
> Just to be sure I understand, it seems to me that your point 2) and 3)
> are 2 different approaches to do the same thing, aren't they ?

No, all of those need to be done.  (Plus maybe a few more things,
I wasn't trying to be exhaustive.)  That last point is what makes
the other ones take effect ... without it, the top level IRQ will
never get dispatched to the GPIO-specific IRQ.

Look at the examples I referenced.


> If so I can only implement 2) since it seems to me better than the
> last one (it better uses genirq layer).

No, implementing all of those points is required.  That's how
the relevant parts of the IRQ layer connect to each other.

- Dave

Re: question on generic gpio interface

[Francis Moreau]

On 4/16/07, David Brownell <david-b@pacbell.net> wrote:
> No, all of those need to be done.  (Plus maybe a few more things,
> I wasn't trying to be exhaustive.)  That last point is what makes
> the other ones take effect ... without it, the top level IRQ will
> never get dispatched to the GPIO-specific IRQ.
>
> Look at the examples I referenced.
>

I took a deeper look at the examples you mentioned and I understand
what you mean now...

I'm going to implement this since it all makes sense to me now. I'll
give you any feedbacks and try to post questions related to gpio only
if any.

BTW, are there any plan to make gpio usable from userspace ? I don't
know if it makes sense but I saw some patches on LKML that did that.

Thanks again.
-- 
Francis

Re: question on generic gpio interface

[David Brownell]

On Tuesday 17 April 2007 12:04 am, Francis Moreau wrote:

> BTW, are there any plan to make gpio usable from userspace ? I don't
> know if it makes sense but I saw some patches on LKML that did that.

Only the usual plan:  someone who wants that feature provides a driver,
which can be merged after suitable review.

For example, the gpio_keys and leds-gpio drivers already exist to
expose some kinds of GPIOs ... though not specifically as GPIOs.
And I've seen various drivers that package GPIOs on specific chips,
mostly for _exclusive_ use by userspace (no kernel access).


In this case I'm not entirely sure how it'd work.  I've seen a few
drivers which let userspace peek and poke at GPIO signals -- like
one for Gumstix boards -- but generalizing the model isn't simple.
Sub-problems include:

 - Configuring the relevant pins.  Especially for SOC cases, GPIO
   roles are multiplexed with several others.  So there are two
   issues:  (a) the platform-specific setup of that multiplexing,
   plus (b) the board-specific knowledge of what pins are truly
   available for use as GPIOs, and not otherwise in use.

 - Enumerating those GPIOs to userspace.  One SOC might have just
   a few dozen, another might have a few hundred; and then there
   are all the board-specific ones, on FPGA or I2C chips etc.

 - Exposing those pins to userspace.  It'd be unsafe to let pins
   claimed by drivers be managed by userspace; the default should
   be that only unclaimed GPIOs can be accessed.

Those points imply part of a design that includes board-specific
hooks of various kinds (maybe delegating a lot to platform code).

But nobody's yet provided code that would generalize.

- Dave

Re: question on generic gpio interface

[Francis Moreau]

On 4/17/07, David Brownell <david-b@pacbell.net> wrote:
> In this case I'm not entirely sure how it'd work.  I've seen a few
> drivers which let userspace peek and poke at GPIO signals -- like
> one for Gumstix boards -- but generalizing the model isn't simple.
> Sub-problems include:
>
>  - Configuring the relevant pins.  Especially for SOC cases, GPIO
>    roles are multiplexed with several others.  So there are two
>    issues:  (a) the platform-specific setup of that multiplexing,
>    plus (b) the board-specific knowledge of what pins are truly
>    available for use as GPIOs, and not otherwise in use.
>

what about create a module "user-gpio" for example that could request
some gpios that the board could have declared using resource
subsystem, like this:

static struct resource foo_gpio_resource[] = {
        [0] = {
                .start = 10,
                .end  = 11,
                .flags = IORESOURCE_GPIO,
        },
       [1] = {
                .start = 26,
                .end  = 31,
                .flags = IORESOURCE_GPIO,
        },
};

struct platform_device foo_device_usergpio = {
        .name           = "user-gpio",
        .id             = -1,
        .num_resources  = ARRAY_SIZE(foo_gpio_resource),
        .resource       = foo_gpio_resource,
};

This way "user-gpio" module knows which pins are avalaible to userspace.

>  - Enumerating those GPIOs to userspace.  One SOC might have just
>    a few dozen, another might have a few hundred; and then there
>    are all the board-specific ones, on FPGA or I2C chips etc.
>

This point is actully the one where I'm really not sure...

Enumerating user GPIOs would always start from 0 to GPIO_USER_NR - 1
and an application that need to be portable should use a config file
to specify which GPIO num to use...

>  - Exposing those pins to userspace.  It'd be unsafe to let pins
>    claimed by drivers be managed by userspace; the default should
>    be that only unclaimed GPIOs can be accessed.
>

Well an extreme solution would be to test in gpio_request(), if the
passed gpio nr is a user one then gpio_request() would return an
error. We could use is_user_gpio() function implemented by user-gpio
module

Thanks
-- 
Francis

Re: question on generic gpio interface

[David Brownell]

On Thursday 19 April 2007 1:05 am, Francis Moreau wrote:
> On 4/17/07, David Brownell <david-b@pacbell.net> wrote:

With regards to a userspace interface to GPIOs (rather than to
devices such as leds or switches they control):


> > In this case I'm not entirely sure how it'd work.  I've seen a few
> > drivers which let userspace peek and poke at GPIO signals -- like
> > one for Gumstix boards -- but generalizing the model isn't simple.
> > Sub-problems include:
> >
> >  - Configuring the relevant pins.  Especially for SOC cases, GPIO
> >    roles are multiplexed with several others.  So there are two
> >    issues:  (a) the platform-specific setup of that multiplexing,
> >    plus (b) the board-specific knowledge of what pins are truly
> >    available for use as GPIOs, and not otherwise in use.
> >
> 
> what about create a module "user-gpio" for example that could request
> some gpios that the board could have declared using resource
> subsystem, like this:

That addresses only (b).  But (a) would still need a solution.

It's common that any given pin be usable for multiple different
purposes ... it's rarely hardwired only to a GPIO controller.
More usually it will be multiplexed to several other controllers
under software control.  (Some chips allow up to eight choices,
Others only have two or three.)

> 
> static struct resource foo_gpio_resource[] = {
>         [0] = {
>                 .start = 10,
>                 .end  = 11,
>                 .flags = IORESOURCE_GPIO,

As you probably know, there is no such thing as IORESOURCE_GPIO;
that could be changed if necessary.

>         },
>        [1] = {
>                 .start = 26,
>                 .end  = 31,
>                 .flags = IORESOURCE_GPIO,
>         },
> };
> 
> struct platform_device foo_device_usergpio = {
>         .name           = "user-gpio",
>         .id             = -1,
>         .num_resources  = ARRAY_SIZE(foo_gpio_resource),
>         .resource       = foo_gpio_resource,
> };
> 
> This way "user-gpio" module knows which pins are avalaible to userspace.

If there's going to be a "user-gpio" driver it could just as easily
take an array of GPIOs in its platform data; and that would usuallly
take a lot less space, even if it's not compressed to a bitmask!


> >  - Enumerating those GPIOs to userspace.  One SOC might have just
> >    a few dozen, another might have a few hundred; and then there
> >    are all the board-specific ones, on FPGA or I2C chips etc.
> >
> 
> This point is actully the one where I'm really not sure...
> 
> Enumerating user GPIOs would always start from 0 to GPIO_USER_NR - 1
> and an application that need to be portable should use a config file
> to specify which GPIO num to use...

Actually GPIOs don't need to start at zero, and the numbering doesn't
need to be continuous.  On one system I use, GPIOs start at 32; on
another, they go 0..63 and then 192..207; and that's just for the
once on the same chip as the CPU!

As far as configuration goes, what would be useful would be to have
someone do a survey of the existing userspace tools that work with
GPIOs, and see what they're trying to do.  I'd start with that one
for Gumstix, since it's got a fairly broad problem domain.


> >  - Exposing those pins to userspace.  It'd be unsafe to let pins
> >    claimed by drivers be managed by userspace; the default should
> >    be that only unclaimed GPIOs can be accessed.
> >
> 
> Well an extreme solution would be to test in gpio_request(), if the
> passed gpio nr is a user one then gpio_request() would return an
> error. We could use is_user_gpio() function implemented by user-gpio
> module

Yes, using gpio_request() is the natural solution.  I hope to see more
platforms actually implementing it before too long.

- Dave