| Message ID | 1470225957-5692-2-git-send-email-noltari@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
On Wed, Aug 3, 2016 at 2:05 PM, Álvaro Fernández Rojas <noltari@gmail.com> wrote: > From: Christian Lamparter <chunkeey@googlemail.com> > > This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio > chips. > This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345. > It can be used in newer SoCs, without the capability of pin multiplexing. > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> > Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > --- > v2: fix build Aha now I understand why the binding looks like it does. Sorry for being too stupid to understand it was using the generic GPIO MMIO bindings :( I see that it is tempting to use MMIO for this. But surely, with all the registers you left out, this controller can do a bunch of other stuff with the registers you're not using right now. I think the right solution is to use GPIO_GENERIC but create a unque GPIO driver for this hardware. It's just not that simple, if you look at the register map, can this hardware also do open drain? Interrupts? Biasing? etc. Then it needs its own driver, it can use the generic GPIO library but still needs its own driver. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, First of all sorry about not explaining things correctly. El 11/08/2016 a las 13:50, Linus Walleij escribió: > On Wed, Aug 3, 2016 at 2:05 PM, Álvaro Fernández Rojas > <noltari@gmail.com> wrote: > >> From: Christian Lamparter <chunkeey@googlemail.com> >> >> This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio >> chips. >> This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345. >> It can be used in newer SoCs, without the capability of pin multiplexing. >> >> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> >> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> >> --- >> v2: fix build > > Aha now I understand why the binding looks like it does. > > Sorry for being too stupid to understand it was using the > generic GPIO MMIO bindings :( > > I see that it is tempting to use MMIO for this. But surely, > with all the registers you left out, this controller can do a bunch of > other stuff with the registers you're not using right now. Not really, there aren't any other GPIO registers for these two (old) SoCs. However, newer SoCs have pinmux and several other registers, thus the warning about not using them for newer SoCs. > > I think the right solution is to use GPIO_GENERIC but create > a unque GPIO driver for this hardware. It's just not that simple, > if you look at the register map, can this hardware also do open > drain? Interrupts? Biasing? etc. Then it needs its own driver, > it can use the generic GPIO library but still needs its own driver. Please, have a look at: https://gitlab.labs.nic.cz/turris/openwrt/blob/8bfda76892a39c033b5abf2c17035a444fffad08/target/linux/brcm63xx-2.6/files/include/asm-mips/mach-bcm963xx/6345_map_part.h#L141 https://gitlab.labs.nic.cz/turris/openwrt/blob/8bfda76892a39c033b5abf2c17035a444fffad08/target/linux/brcm63xx-2.6/files/include/asm-mips/mach-bcm963xx/6338_map_part.h#L202 As you can see these two SoCs are pretty simple and only direction and data can be configured. As an example, BCM6348 does have pin multiplexing (GPIOMode) and needs a more complex gpio/pinctrl driver: https://gitlab.labs.nic.cz/turris/openwrt/blob/8bfda76892a39c033b5abf2c17035a444fffad08/target/linux/brcm63xx-2.6/files/include/asm-mips/mach-bcm963xx/6348_map_part.h#L255 > > Yours, > Linus Walleij > Regards, Álvaro. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 3, 2016 at 2:05 PM, Álvaro Fernández Rojas <noltari@gmail.com> wrote: > From: Christian Lamparter <chunkeey@googlemail.com> > > This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio > chips. > This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345. > It can be used in newer SoCs, without the capability of pin multiplexing. > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> > Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Excellent patch, especially how it does endianness, applied. Forget my earlier (erroneous) remarks. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpio/gpio-mmio.c b/drivers/gpio/gpio-mmio.c index 6ec144b..d7d03ad 100644 --- a/drivers/gpio/gpio-mmio.c +++ b/drivers/gpio/gpio-mmio.c @@ -573,6 +573,7 @@ static void __iomem *bgpio_map(struct platform_device *pdev, #ifdef CONFIG_OF static const struct of_device_id bgpio_of_match[] = { + { .compatible = "brcm,bcm6345-gpio" }, { .compatible = "wd,mbl-gpio" }, { } }; @@ -593,6 +594,9 @@ static struct bgpio_pdata *bgpio_parse_dt(struct platform_device *pdev, pdata->base = -1; + if (of_device_is_big_endian(pdev->dev.of_node)) + *flags |= BGPIOF_BIG_ENDIAN_BYTE_ORDER; + if (of_property_read_bool(pdev->dev.of_node, "no-output")) *flags |= BGPIOF_NO_OUTPUT;