Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

David Brownell wrote:

- Only intended for use with "real" GPIOs that work from IRQ context;
e.g. pins on a SOC that are controlled by chip register access.

- Doesn't handle I2C or SPI based GPIOs. I think we actually need
a different API for those "message based" GPIOs, where synchronous
get/set requires sleeping (and is thus unusable from IRQ context).
That API could be used for "real" GPIOs; the converse is not true.

- No IORESOURCE_GPIO resource type (could be added though).

- Can be trivially implemented today, on many systems (see partial
list above) ... no "provider" or gpiochip API necessary.

- Provided in the form of a working patch, with sample implementation;
known to be viable on multiple architectures and platforms.

- Includes Documentation/gpio.txt

Comments?


If this is done, I think it's essential that a "high-level" API (one that supports message-based GPIO) is provided at the same time. The "high-level" API should be able to address the GPIOs addressed by the low-level API. What we do *not* want is a bunch of stuff using the low-level API when the high-level API would work.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch 2.6.20-rc1 1/6] GPIO core
    ... these calls will be ignored for GPIOs that can't safely ... during earlier API discussions. ... Because "of course" it's legit for debug modes to do all kinds of things, ... And programming interface specs ...
    (Linux-Kernel)
  • Re: [PATCH 1/4 resend] [x86] Add generic GPIO support to x86
    ... Its reasonable to expect that the API will expand over time as it is ... There is nothing wrong with the existing API, ... But on the Geode, GPIOs ...
    (Linux-Kernel)