[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation
    David Brownell wrote:

    >That's different from pin mux setup, which for most embedded
    >systems is just making sure the SOC is configured to match
    >what Linux expects. The boot loader usualy does some of that,
    >but it's probably not validated to do more than reliably boot
    >an operating system ... so pin muxing can't realistically
    >report anything as an error. At best, it's a suggestion to
    >update the bootloader someday.

    The ARM platforms I've worked with provide enough read-only information
    to allow you to report the status/assignment of a GPIO line, be it
    input, output, or assigned to one of several peripheral functions. So
    you definitely want to read that stuff and report from it rather than
    just the state of a static array somewhere.

    In fact, at least at first glance there's really no need for a static
    array at all on many chips that I can think of. At most, the
    gpio_request() function should build up a temporary bitmask using
    information read from the hardware, then discard that temporary bitmask
    after the request is completed and the hardware actually configured.

    >No, but letting the second one report the fatal error is a big help.
    >And heck, you've got reasonable chance the first driver will work,
    >if the second doesn't interfere with it! (Or maybe it's the other
    >way around. At least you'd have logged a fatal error message ...)

    If the gpio_request() is reading from the hardware, it could determine
    that a GPIO line was assigned to a peripheral function by the
    bootloader; then it could refuse that request to the caller. The fact
    that we don't have an API to assign the pin to a peripheral function
    would be even less of a concern then, because ordinary GPIO users of the
    pin could still avoid accidentally assigning a peripheral function pin
    to themselves as GPIO.

    >Admittedly, the GPIO controller in those Atmel chips (AVR32,
    >AT91) does have a one-to-one mapping for muxable pins and GPIOs,
    >but that's not a portable notion.

    Can you refer me to a specific chip that is contrary to the AVR32/AT91
    notion, so that I can be sure I'm understanding what you're saying?


    Bill Gatliff

    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 04:15    [W:0.024 / U:2.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site