On Fri, 19 Oct 2007 21:32:08 +0000 (UTC)
Jordan Crouse <jordan.crouse@amd.com> wrote:

quoted text
> > This one was discussed mostly on the ARM mailing-list and finally
> > made his way to the mainline kernel. Though it lacks some functions
> > to change for instance a entire GPIO line and not a single bit, it
> > is used on ARM and MIPS systems so I would conform with this one
> > for now because it is used by at least two or more architectures.  

Make that four: AVR32 and Blackfin use the generic GPIO API too.

quoted text
> Its reasonable to expect that the API will expand over time as it is
> thrust into new situations.  There is nothing wrong with the existing
> API, it does an admirable job of simple GPIO frobbing.  But on the
> Geode, GPIOs can do much more then just simple input and output.  We
> can cause events, use input filtering for debouncing, set various
> drain options, and more.

There are many other architectures that can do things like that. But
since there are lots of variations in this kind of functionality from
architecture to architecture (and even chip to chip), it has been
excluded from the generic GPIO API.

quoted text
> And these are not bullet points from the
> datasheet that we want to implement for completeness; these functions
> are actually being used right now in the kernel on real hardware.

How is it used? In many cases, you can get away with simply configuring
the port with the required features like debouncing, pullup, drain
options, etc. in the platform setup code where you can freely use
platform-specific port configuration calls.

quoted text
> Just because other architectures haven't found a need to expand the
> API doesn't mean that we shouldn't expand it now.  And bear in mind,
> the Geode isn't unique - I'll bet beers that there are MIPS and ARM
> architectures that have these features too, and they would use the
> API if it existed.

These features are certainly being utilized in the platform setup code
on various platforms. I guess the current API might be too simple for
drivers that need to reconfigure the port on the fly, but I haven't
really seen any such drivers so far.

For example, the generic i2c-gpio driver supports three different ways
of driving the i2c lines depending on how the port was configured by
the platform.

Håvard
-
unsubscribe notice
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/