lkml.org 
[lkml]   [2013]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] gpio: introduce descriptor-based interface
On 01/10/2013 07:08 PM, Arnd Bergmann wrote:
> I've tried to find platforms that don't yet use GPIOLIB and fortunately
> there are very few left:
>
> I found two that provide the generic gpio interfaces when gpiolib
> is disabled, but use gpiolib otherwise for the same hardware,
> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
> I would assume that we can simply remove the non-gpiolib shortcut
> here at cost of a small overhead.

I performed a search on my side too (checking configurations options
which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the
same list. This takes some time btw - many platforms use this combo to
make GPIO support optional. Can I ask how you figured out these two archs?

I'd assume the overhead induced by forcibly compiling GPIOlib is
neglectable, but let's make sure this is ok indeed - Mike, Geert, would
you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in,
effectively making it mandatory to implement the generic GPIO interface
using GPIOlib? Both your implementations support GPIOlib already, but
can also work without it, and that would make that possibility obsolete.

> Then there are a bunch that use gpiolib but have a nontrivial
> implementation of gpio_get_value and other functions. I'm not sure
> if these are a problematic with your code.

AFAICT these all implement an inline path that bypasses GPIOlib when the
GPIO number is known at compile time, for faster bitbanging I presume.
It should be totally harmless to keep them. Unfortunately, I don't think
it would be possible to have a similar trick using handlers.

Thanks,
Alex.


\
 
 \ /
  Last update: 2013-01-14 12:01    [W:0.250 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site