To everyone using gpio-dev, use cases

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The version of gpio-dev we've come to know (and has been immortalized all over the wiki and in Atmel app notes) is an AVR32-specific thing maintained out of tree. The time has come for a generic version and there are discussions now on how to design the interface.

What I'm hoping is that anyone using gpio-dev now can tell me what they're using it for, what's good, what's bad etc.

Also, if you're using it for button inputs why aren't you using the gpio_keys or gpio_mouse driver? If you are running indicators (eg LEDs) off them why aren't you using gpio-leds? And of course valid responses to these questions may be things like "too complex" or "I didn't know they existed".

So please, let us know what you want to see in a new userspace gpio interface!

Thanks
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right now I am using gpio-dev for both buttons and leds for the exact reason you mentioned - I didn't know anything else existed.
Is there a wiki page somewhere that outlines these other drivers and how to use them? I searched briefly and didn't turn anything up other than: http://www.avr32linux.org/twiki/...

-Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool thanks :-)

There's no real docco that I know of either. Neither of those things are avr32-specific so the docco, if it exists will be elsewhere on teh interwebz :-)

The LEDs on the NGW100 and STK1000 are driven using gpio-leds. The idea is that in your board setup code (eg arch/avr32/boards/atngw100/setup.c in your kernel source tree) and fill in structures representing which LED is where. You use these to register a new gpio-leds device and then control it through /sys/class/leds. Don't be too scared by this, I know it sounds tricky, but it's pretty self-explanatory once you actually get in there and start digging around.

gpio-keys is similar in that you fill in structures containing each gpio pin and the key you want it to be mapped to then use that to register a gpio-keys device. Then all your buttons will just look like a normal keyboard, hurray!

Thanks for your feedback Steve, I'd say that no matter how good a gpio-dev interface we get there needs to be more docco regarding the more "formal" and "proper" alternatives :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Squid, I have a question about gpio. Is there any way to have an interrupt on a pin state change? Right now I'm interested in knowing when a state transition occurs and I would really like to not have to poll. It sounds like there's quite a bit about the gpio drivers I'm not aware of, is this something that exists? Thanks,

-Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you've configured for example GPIO_PIN_PB(27) as an input (or even as an open drain output), just

request_gpio(gpio_to_irq(GPIO_PIN_PB(27)), ...) 

to use that input as an IRQ line. That's worked for quite a long time now. It's pretty standard on Linux that GPIOs be usable for IRQs. See Documentation/gpio.txt for more information about general GPIO programming.

There are also a few mechanisms that are specific to the Atmel GPIOs (AVR32 and AT91) ... like pullups, input deglitch filters, and open drain (vs totem pole) output stages. Those are described in the chip docs, and there are some CPU-specific calls to take advantage of them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The application note "AVR32408: AVR32 AP7 Linux GPIO driver" attempts to document a few possible ways to do GPIO from user space, including leds, keys and mouse. It says a few words about GPIO from kernel space as well, but if that's what you want to do, you're much better off reading Documentation/gpio.txt.

It also explains how to use the gpio-dev interface, with a few words of warning first ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, and you can find the appnote near the bottom of this page:

http://www.atmel.com/dyn/product...