Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls | Date | Mon, 13 Nov 2006 11:25:52 -0800 |
| |
On Monday 13 November 2006 9:56 am, Thiago Galesi wrote: > I guess that a kind of "name addressing" would be the way to go, we > need to get to it by "location" (I'm thinking PortA 20, PortB 5 rather > than pin number or some other arbitrary convention; we need a way to > not need to look up what 'Port X pin B' should be called.
That's highly platform-specific. AT91 and AVR32 use that style of addressing ... most others just talk about GPIO numbers. In all cases, the platform can assign _some_ number to each GPIO signal.
> Another thing that may be considered is the ability to get 'pointers' > for GPIOs.
The GPIO identifiers are unsigned integers. If you really crave pointers, you can cast those integers to pointers, and back. But why bother? :)
> And, of course, protecting GPIOs from concurrent accesses
Did you read the proposal? There are *already* two mechanisms for that:
- gpio_request()/gpio_free() ... protecting from concurrent access between drivers, also known as bugs.
- gpio_set_value() ... implementations can lock internally, as needed. ditto gpio_get_value(), but only bizarre hardware would need it.
Re that last, consider two different types of GPIO controller:
* One of them has just one register with the output values, and a RISC CPU without bit set/clear instructions to use on it. So a spinlock is needed to cover reading the register, modifying that value, then rewriting the value.
* Better GPIO controller designs (normal ones) have separate registers for "write mask to set" and "write mask to clear" ... no spinlock needed, the hardware sorts everything out.
I did update the docs to make clear that gpio get/set calls are atomic; hard to imagine single bit operations that aren't, but it's worth removing potential confusion.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |