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

[David Brownell <david-b@pacbell.net>]

On Monday 13 November 2006 11:43 am, Bill Gatliff wrote:
> >
> >This API absolutely allows for multiple GPIO controllers ... all it does
> >is say "here are the numbers, handle them".  The platform's implementation
> >of the API is allowed to map to the relevant controller.
> 
> I think what Paul is saying here is that because your reference 
> implementation was "arch-omap" instead of "board-<something>", if I add 
> a PLD with some MMIO GPIO lines then I have to hack global OMAP code.  

Well, "example" implementation.

Linux doesn't handle PLDs as well as it might.  One example in the current
kernel is the original PXA reference platform, Intel's "Lubbock".  It's got
an FPGA with essential IRQs.  Look at the mess involved in coupling those
IRQs into the system ... not just adding a new irq_chip (easy!), but the
way the global PXA IRQ headers need to know about it.

Part of this is just that NR_IRQs is a global constant, and it's not
possible to allocate new IRQ banks after a kernel is built.  Like by
plugging in a few I2C chips with IRQ-capable GPIOs ...

Now, I think the way OMAP handles GPIOs could handle "add an FPGA" pretty
cleanly.  That is admittedly a platform-specific implementation issue ...
but then, so is "add an FPGA".  And in any case, It should be very clear
that such implementation issues don't need to affect the API, and that
right now only the API is being proposed.


> Maybe we should codify an approach for that now, i.e. add to the 
> reference implementation some code that hands off out-of-range GPIO 
> lines to a function in the machine descriptor:
> 
> 
> +static inline int gpio_direction_input(unsigned gpio)
> +	{ if (gpio < OMAP_MAX_ARCH_GPIO) return __gpio_set_direction(gpio, 1);
> +	  else if(mdesc->platform_gpio_set_direction) platform_gpio_set_direction(gpio, 1); }
> 
> 
> ... conveniently neglecting the way you find mdesc.  :)

Nah; look at arch/arm/plat-omap/gpio.c and ignore the mess, but observe
that what you see there is essentially a bunch of "gpio controller"
classes using the ugly "switch(type)" dispatch scheme instead of the
prettier "type->op()" dispatch scheme.  All that stuff needs to be
cleaner, but for now it'd suffice to add a new FPGA typecode.


> I do have a question now.  Is there any reason to consider shared GPIO 
> lines?  If so, then the request_gpio() would need a flag GPIO_SHARED or 
> something.

If two drivers agree to share a line -- how, why? -- they can come to a
private agreement.  We lack even a good example of why drivers would
want to share, much less knowledge that it's a general problem!

- Dave