[lkml]   [2006]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    On Monday 20 November 2006 10:09 pm, Paul Mundt wrote:
    > On Mon, Nov 20, 2006 at 09:35:38PM -0800, David Brownell wrote:
    > > On Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
    > > > It seems like the point
    > > > here is to help a driver find and assert their GPIO _pin_ so that the
    > > > driver can can talk to the attached external hardware.
    > >
    > > Updating the GPIO controller is always (all architectures!) done in terms
    > > of a number mapping to some controller and a bit number, not a pin. The
    > > drivers never care about pins.
    > >
    > > The only thing that cares about pins is board setup code -- briefly.
    > >
    > That's rather simplifying things.

    Not much. The only counterexample I know about just now is wanting
    to use a UART.RX pin as a wakeup GPIO, even when the baud rate clock
    is turned off during sleep ... only on development platforms.

    > There is a need to layer a pin mux API underneath the GPIO API to deal
    > with these sorts of things, but that's obviously up to the platform to
    > take care of, and I think your API is a fairly good staging ground for
    > building up the layering in the platform parts.

    Not entirely "mine" ... except in the writeup of the abstraction that's
    already in wide use (with different syntax).

    If we can agree on syntax, and factoring pin mux separately (however it
    gets implemented) I think the immediate goal is satisfied.

    > Claiming that we set the pins once in the board setup code and then
    > forget about it is not realistic. I can't imagine anyone with many
    > different pin functions under mux (OMAP2 does too) seriously taking that
    > position.

    It's realistic in a couple dozen different systems I've seen, including
    ones using OMAP2. Isn't that serious enough? :)

    > So given that, I would argue that drivers _do_ care about the pins, just
    > not through the GPIO API.

    I'm not quite sure what you're getting at with that any more, but so long
    as you agree that it makes sense to have a GPIO API with more or less the
    syntax I collected, distinct from pin mux/setup/reconfig, we're in close
    enough agreement to move forward to whatever.

    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.

    - Dave

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-21 22:23    [W:0.033 / U:244.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site