[RFC] GPIO framework

[Oleksandr Tymoshenko]

Milan Obuch wrote:
> On Thursday 26 November 2009 05:57:36 Oleksandr Tymoshenko wrote:
> 
> Anyway, I will try to look at your work in next amount of my free time and 
> comment on the code side, if I will have anything, but now, some general 
> comments on your mail. I have some WRAP boards, where some GPIOs are used to 
> drive three status LEDs and attach a soft reset button, add-on board with LPC 
> SuperIO chip with some tens of GPIOs and some other SuperIOs where I can test 
> things, x86 based.
     Thanks, I'd appreciate it.

> Also there are some PRs open for NSLU2 (ARM SoC based), where some GPIOs are 
> used for LEDs and button(s), too. You might consider them too, if you did not 
> already. I can test something for NSLU2, too, but I did not manage to master 
> it completely yet.
> 
> And, one more general note, I found GPIOs are used internally in many various 
> add-on cards, like atheros based wireless adapters (ath driver), various TV 
> grabber cards - mostly for i2c setting of tuner parameters etc. Usefullness 
> of covering these with general GPIO framework should be considered, though.
     Yes, I'm aware of this kind of GPIO use. Not sure how it fit into device
tree model though. May be some additional API calls will be required.

> Did you think about ability to use interrupt abilities of GPIO? In my work I 
> added a hook to call a script via devd for pins selected (a special flag or 
> something). This way it is easy to execute a script on a button press.
     Yes, I thought about it but postponed for next stage. My idea was to have
ioctl that would block waiting for interrupt but I like your devd approach better.

Thanks! Looking forward to you review and feedback.

-- 
gonzo