[PATCH] gpio: Add device driver for GRGPIO cores
Andreas Larsson
andreas at gaisler.com
Mon Feb 4 21:27:33 EST 2013
On 2013-02-04 10:24, Linus Walleij wrote:
>>> And do you really have and test this regularly on both LE and BE hardware?
>>> I am worrying a bit about maintenance...
>>
>> I am more than happy to drop that. I will most probably never test this on
>> LE hardware.
>
> Will someone else? I'm more thinking whether it is customary in
> the SPARC drivers to do things like this, then we should follow
> that pattern of course.
It is definitely not customary in SPARC drivers. The module is marked
"depends on OF" in Kconfig though and there seems to be no way to depend
on an endianness. Unless someone instantiates the core in a LE system
there is no reason for it.
>> 2) The grgpio_to_irq function is very hardware specific, and there is of
>> course no gpio_to_irq support in gpio-generic.
>
> Well, the idea about gpio-generic is to use the pieces you need
> IIRC. You may override.
Ah, I see, bgpio_init is exported, so I might be able use that from my
driver to get rid of some functions. There is support for BE I saw now.
It seems broken to me (flips bits, not bytes), but that can be fixed.
>> 3) Running on SPARC, I get Open Firmware information from prom, so there is
>> no platform data to access in the probe function. Of course general Open
>> Firmware support could be added to gpio-generic, but in addition my probe
>> needs to set up very hardware specific things for gpio_to_irq.
>
> We should probably add some way to handle generic GPIO
> with compatible strings etc, but that's way outside my competence
> so OK. Maybe Rob or Grant can say something.
Might be a good idea. However, by just using bgpio_init in a separate
driver (like most other users of bgpio_init), that would not be required
or used by me anyhow.
I'll look into using bgpio_init from my driver.
Cheers,
Andreas Larsson
More information about the devicetree-discuss
mailing list