[RFC] GPIODEV API (extension to Generic GPIO API)

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Kernel lists,

      This is updated and reworked API previously proposed at
http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback
(suggestions to use established kernel terminology/naming convention
and drop macros). There are also actual tested patches provided this
time, not just pseudocode. So:

Purpose: An extension to 2.6.21-introduced Generic GPIO API, to
provide ability to handle (several) additional platform GPIO chips,
in efficient manner.

Design principles:

1. The new lightweight API is built on top of Generic GPIO API.
Reason: there was previously a proposal to add such capabilities
to Generic GPIO API from the start (thread at
http://lkml.org/lkml/2007/1/1/87), but other requirements were given
more priority at that time, like being able to perform constant
optimization on Generic GPIO API calls, and reduce them to the direct
platform GPIO registers access in this case. To not affect this
beneficial trait, a new lightweight API is introduced, which uses the
same high-level interface, but trades such constant optimizations for
(runtime) extensibility and generalization to any GPIO-providing
device (whereas Generic GPIO API as it is implemented now for few ARM
architectures handles only GPIOs builtin to a CPU).

2. "World is not flat". The real system is structured as following: it
is set of interconnected chips, and some chips have GPIO pins. The
proposed API preserves this target domain model, and doesn't try to
build abstraction on top of it, (like flattening this structured model
so there were scalar GPIO number). Surprisingly (actually, by design),
this solves few issues, inefficiencies, or hardcoded assumptions
which, for example, "flat GPIO namespace" approach has.

3. What is discussed at the end of previous paragraph, achieved by
using "smart", self-describing GPIO identifiers. These identifiers are
vector (actually, 2-element, i.e. pair), and can be seen either as
belonging to structured namespace, where at first level there're GPIO
devices, and at the second - GPIO pins, IDs of which are consequently
local to a given device. Or, as a simple 2D-coordinate, with GPIO chip
as the first coordinate, and GPIO pin as the second.

  "Self-describedness" is achieved by using a reference (i.e. pointer)
to GPIO device object as the first component, and defining a set of
GPIO operations each such device can perform, with operations being
accessible as method calls on device.


  Summing up, technical benefits of proposed solution are:

Minimizes centralized code needed to manage GPIO devices. Actually,
it doesn't minimize it, but eliminates it at all. From the patches which
will follow, it is visible, that there whole 0 bytes of in-kernel
bureaucracies which do superfluous things like adding or subtracting
various magic "base" numbers, searching thru the lists (more often
linearly than binarily), or at least using hashes with hardcoded capacity
and bucket sizes.

Structured namespace approach leads to better scalability - any number
of GPIO devices can be present in system, and there're no hardcoded
limit of any kind.

"Smart" identifiers (== device method approach) leads to good and
jitter-free performance/latency characteristics: there are no lookups
of any kind per se, to find a device which will perform a request -
it is implicitly encoded in GPIO identifiers on which API operates.
The operation call is also as efficient as something extensible can
get - that's indirect function call by pointer.



Final note: The approach/pattern/paradigm discussed here can be reused
for more things than just GPIO API, that's to the large part reason
one this approach is being proposed and argued at all.

Patches follow.

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

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