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?
b.g.
--
Bill Gatliff
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
