lkml.org 
[lkml]   [2008]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Latest gpio gumph
    Date
    On Wednesday 28 May 2008, Haavard Skinnemoen wrote:
    > >
    > > * gpio_direction_output() should disable the pullups just like
    > > at32_select_gpio(... AT32_GPIOF_OUTPUT) does, for consistency
    > > between those alternative initialization paths.
    >
    > But then we need to keep track of whether pullups used to be enabled so
    > that we can re-enable it in gpio_direction_input(), don't we?

    "Need"? I'd figure that changing direction like that would be
    uncommon without something determining signal level (like an
    external driver or pullup) ... and if nothing did so, then it'd
    be important to use the AVR32-private API with pullup control.


    > I can't see the harm of keeping the pullup enabled while the port is
    > configured as output. For consistency, I'd rather honor the pullup flag
    > in at32_select_gpio() regardless of AT32_GPIOF_OUTPUT.

    I guess I don't like the idea of facilitating the constant current
    waste that implies if output is being driven low. Even if it's not
    a huge current waste! (These pullups being a lot weaker than I'd
    have expected, at typically 190 kOhm.) No big deal here I guess.

    For an open drain output it's probably less of an issue, unless
    there are too many pullups.


    > > * On the odd chance some code uses a pin as a GPIO IRQ without
    > > calling gpio_request() or gpio_direction_input(), the debug
    > > dump should still show its pin status.
    >
    > Hmm. I guess that makes sense, though I would be lying if I said I care
    > all that much. I think gpiolib is going pretty far to accommodate buggy
    > drivers that don't call gpio_request() as it is.

    For diagnostic/debug code, I'd say it's reasonably useful to cope
    with buglets like that.

    I actually observed that happening. Setup code was passing the irq
    to the driver, and everything worked fine because the reset default
    was fine. I happened to notice that /sys/kernel/debug/gpio output
    didn't match up to /proc/interrupts (bug) ... but it would have been
    much faster to see the bug if the listing for that pin had a "?" label
    showing that it hadn't been requested.

    - Dave



    \
     
     \ /
      Last update: 2008-05-28 11:05    [W:0.024 / U:3.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site