[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.095 / U:6.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site