Messages in this thread | | | Date | Wed, 22 Nov 2006 12:55:17 +0900 | From | Paul Mundt <> | Subject | Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls |
| |
On Tue, Nov 21, 2006 at 09:36:17PM -0600, Bill Gatliff wrote: > David Brownell wrote: > >I know some folk say they "need" to remux after boot in > >non-exceptional cases, but the ability to do that (or not) really > >seems like a separate discussion. > > I don't need to REmux, but I don't want to bother setting up the routing > manually at all. I think the GPIO management stuff can do it properly > on my behalf, given the information we have to acquire to get the GPIO > API to work in the first place. > You can't really have one without the other, and if you're going to add that sort of functionality, it's not strictly tied to the GPIOs.
> Kind of like with request_irq() and enable_irq(). The driver is saying, > "I don't care what's actually behind this interrupt source X, I just > want it routed over to me". If we commit to hiding the muxing behind > the API, instead of defining a new, parallel API, we get that kind of > mentality for GPIO as well. > As soon as a driver comes along and says that it wants, say, GPIO 42, which happens to be an alternate pin function for pin #128, you've effectively coupled the two, especially since the underlying refcounting is more applicable to the pin function than the GPIO itself.
And this is something where you will have to remux, or at least force that GPIOs availability through the board setup code, but there's little point in dealing with mux issues in the board setup code at all if this is done dynamically based off of the driver requirements and subsequent refcounting.
Static muxing is something that no longer makes any sense. Devices are piling more and more desired functions under mux, and that's not going away. - 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/
| |