On So, Jul 22, 2018 at 9:41 PM, Linus Walleij
<linus.walleij@xxxxxxxxxx> wrote:
After looking at the patch set again I think the following is going to
be simplest
to proceed:
1. Look carefully at drivers like gpio-ftgpio010.c or gpio-pl061.c
2. Rewrite the driver to use GPIO_GENERIC instead of the "mm"
stuff.
3. Use GPIOLIB_IRQCHIP and implement IRQ support.
4. Think about how to handle the dual GPIO.
Yours,
Linus Walleij
Ok, having looked at some current GPIO implementations, it is still not
quite clear to me how to best support dual GPIOs.
Right now, I see the following two options:
* Using two gpio_chip structs (one for each channel). This would be the
most
straigt forward solution but I don't see how it should work to
register two
gpio_chips for a given device. Also I don't know where address
translation
happens (where I could choose which of the gpio_chips to pass in).
* Rolling your own solution. This would essentially be not using
bgpio_init()
and instead storing enough information in the struct to be able to
identify
the channel based on the gpio number. This is what is currently done,
but
as you said, it should be rewritten to *reuse* already implemented
stuff.
Sadly, the gpio-xilinx is currently one out of three devices where
#gpio-cells is allowed to be larger than 2, so rather an exception.
In the long term, adding multi-channel support to gpio-mmio.c would be
nice.
Regards,
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
