Messages in this thread | | | Date | Tue, 15 Feb 2011 19:41:32 +0000 | From | Alan Cox <> | Subject | Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction |
| |
> My understanding is that currently if some platform wants to toggle pins > back and forth between alt_func and GPIO, it needs to handle that logic > itself. If platform code is handling that toggling, I'd think the GPIO
Yes - which is broken as you can't abstract it to the drivers which is the whole point of GPIO. Anyway put that bit aside - for the get method it's not actually important since we need an unknown state anyway and alt_func is unknown or similar.
> > That would fix that problem and at least allow the > > reporting side of GPIO in use for something else to be handled as a > > platform thing even though it can't be handled properly. > > I don't follow. I don't think I'm grasping what you want for alt_func > pins in the short term. Do you want them to be exported to the GPIO > sysfs filesystem and shown as "unavailable"? If so, what advantage does > that have over not allowing them to be exported/reserved in the first > place?
You can see what state they are in. Otherwise you have to clone the GPIO sysfs to expose private platform specific magic to indicate that.
Anyway first step is to allow 'Unknown' to be reported by a get_direction method. The direction of a pin in some magic platform owned state is defacto 'unknown'.
Not having a get_direction method doesn't help as we don't support changing the methods on the fly (which is horrid for locking and best kept that way) so we need a way to return input/output/beats me
| |