gpio_keys input driver

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

A few days back I posted a patch which gave recent kernel versions the gpio_keys driver and the header for avr32. There's been a bit of interest so here's the official thread!

The patch is reposted below along with a (NOT FULLY FUNCTIONING) sample implementation. I say not fully functioning because it doesn't set up the chosen gpio lines as correctly-pulled inputs with interrupts enabled nor does it correctly program the interrupt controller, it just demonstrates how to set up the gpio_keys side of things.

If you are going to put the setup in a seperate file like this remember to add it to your Makefile ;) otherwise you can add all this stuff to arch/avr32/boards/atstk1000/atstk1002.c and/or call the init function from atstk1002_init rather than registering another postcore_initcall.

As mentioned in the other thread, this driver will be officially in 2.6.21 when that is released, though it probably won't have gpio_keys.h in asm-avr32 as well as asm-arm unless I can get my act together and post a patch to do just that ;)

Good luck!

S.

Attachment(s): 

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

Thanks for the patch, unfortunately I'm unable to try it on my STK.
But your new explanation raised a lot of questions.

I thought about the easy algorithm of making gpio keyboard:
1) apply the patch
2) copy ap7000_button_table[], ap7000_keys_data and ap7000_keys to arch/avr32/boards/atstk1000/atstk1002.c
3) fill struct gpio_keys_button ap7000_button_table[] with all the keys I need.
4) Place

platform_register_device(&ap7000_keys);

at the end of static int __init at32stk1002_init(void)
(but before the "return 0;":) )
5) build the uImage, u-boot it.

And I have my scancodes in /dev/input - that's all I dream about.

It was my plan according to explanation in Qtopia thread, where this patch was originally posted.

But here you write:

Quote:
I say not fully functioning because it doesn't set up the chosen gpio lines as correctly-pulled inputs with interrupts enabled nor does it correctly program the interrupt controller, it just demonstrates how to set up the gpio_keys side of things.

So I need some more hacking?

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

gpio_keys knows what pins to look at and which interrupts to monitor, but it doesn't know how to set those pins up. It has no idea about the workings of the PIO or interrupt controllers. This is kinda how it should be really as it's a board-specific thing and the driver is pretty generic.

Setting up the pins is a pretty easy task, have a look at chapter 19.6 of the ap7000 datasheet (page 252 in version H), it sets up pins 8-11 with pull-ups, glitch filters and input change interrupts. This is how the PIO should be programmed for the pins you care about. IIRC the intc is initially programmed with all interrupts unmasked so you shouldn't have to worry about doing anything there except if you have a need to change their priority. Which you shouldn't.

Apart from this your algorithm looks correct, sure.

S.