linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: "Álvaro Fernández Rojas" <noltari@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Jonas Gorski <jonas.gorski@gmail.com>,
	Necip Fazil Yildiran <fazilyildiran@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/12] pinctrl: add a pincontrol driver for BCM6328
Date: Tue, 2 Mar 2021 16:20:35 +0100	[thread overview]
Message-ID: <CACRpkdbxAQTft8dapGqBDxM8nbkPvK4i95ND0JBFb_riafZSSg@mail.gmail.com> (raw)
In-Reply-To: <20210225164216.21124-3-noltari@gmail.com>

Hi Álvaro,

thanks for your patch!

On Thu, Feb 25, 2021 at 5:42 PM Álvaro Fernández Rojas
<noltari@gmail.com> wrote:

> Add a pincontrol driver for BCM6328. BCM628 supports muxing 32 pins as
> GPIOs, as LEDs for the integrated LED controller, or various other
> functions. Its pincontrol mux registers also control other aspects, like
> switching the second USB port between host and device mode.
>
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>

Thanks for working on this. This SoC definitely need to come upstream.

I think this driver can be simplified a bit and reuse some core infrastructure
to make it more maintainable. It might be a bit of challenge but definitely
worth it!

> +config PINCTRL_BCM6328
> +       bool "Broadcom BCM6328 GPIO driver"
> +       depends on OF_GPIO && (BMIPS_GENERIC || COMPILE_TEST)
> +       select PINMUX
> +       select PINCONF
> +       select GENERIC_PINCONF
> +       select MFD_SYSCON
> +       default BMIPS_GENERIC
> +       help
> +          Say Y here to enable the Broadcom BCM6328 GPIO driver.

I suggest

select GPIO_REGMAP
select GPIOLIB_IRQCHIP
select IRQ_DOMAIN_HIERARCHY

see below.

(...)
> +#include <linux/bitops.h>

Just <linux/bits.h> maybe, if you only use BIT() and GENMASK().

> +#include <linux/gpio.h>
> +#include <linux/of_gpio.h>

Do not include these, just:
#include <linux/gpio/driver.h>

> +#define BCM6328_DIROUT_REG     0x04
> +#define BCM6328_DATA_REG       0x0c
> +#define BCM6328_MODE_REG       0x18

This looks very much like it could use GPIO_REGMAP.
Can you look at:
drivers/gpio/gpio-regmap.c
drivers/gpio/gpio-sl28cpld.c

And see if you can do what that driver is doing and reuse
this core infrastructure?

> +static inline unsigned int bcm6328_bank_pin(unsigned int pin)
> +{
> +       return pin % PINS_PER_BANK;
> +}

I am generally reluctant about registering several banks/instances
of the GPIO if it is possible to just use more devices in the
device tree, like one for each instance.

> +static inline unsigned int bcm6328_reg_off(unsigned int reg, unsigned int pin)
> +{
> +       return reg - (pin / PINS_PER_BANK) * BANK_SIZE;
> +}

Because it leads to this kind of weirdness to split out the devices
from the main device in practice.

> +static int bcm6328_gpio_direction_input(struct gpio_chip *chip,
> +                                       unsigned int pin)
> +{
(...)
> +       /*
> +        * Check with the pinctrl driver whether this pin is usable as
> +        * an input GPIO
> +        */
> +       ret = pinctrl_gpio_direction_input(chip->base + pin);
> +       if (ret)
> +               return ret;

This is very nice.

> +static int bcm6328_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
> +{
> +       char irq_name[7];
> +
> +       sprintf(irq_name, "gpio%d", gpio);
> +
> +       return of_irq_get_byname(chip->of_node, irq_name);
> +}

This is a clear indication that we are dealing with a hierarchical irqchip.

My assumption is that you have one IRQ per GPIO line, so each
GPIO has a dedicated IRQ on the interrupt controller. Correct?

This means:

- Do not add all the interrupts into the device tree by name.

- In Kconfig select GPIOLIB_IRQCHIP, select IRQ_DOMAIN_HIERARCHY

- Populate a simple struct gpio_irq_chip, if no local registers need
  updating on interrupts, just pass interrupts through
        .irq_mask       = irq_chip_mask_parent,
        .irq_unmask     = irq_chip_unmask_parent,
  etc.

- Implement bcm6328_gpio_child_to_parent_hwirq() for this chip
  with hardcoded mappings between the hardware GPIO and interrupt
  lines, using the parent interrupt controller hierarchically. This mapping
  is determined from the compatible-string, and part of the property
  of how the GPIO block is integrated with the SoC. If need be to
  tell different chips apart, more precise compatible strings are needed.

- Examples:
  drivers/gpio/gpio-ixp4xx.c
  drivers/gpio/gpio-sifive.c

If you do this you will notice the core is more helpful to cut down on the
code.

Yours,
Linus Walleij

  reply	other threads:[~2021-03-02 21:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 16:42 [PATCH 00/12] pinctrl: add BCM63XX pincontrol support Álvaro Fernández Rojas
2021-02-25 16:42 ` [PATCH 01/12] Documentation: add BCM6328 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 14:57   ` Linus Walleij
2021-03-02 15:23     ` Linus Walleij
2021-03-02 16:53       ` Álvaro Fernández Rojas
2021-02-25 16:42 ` [PATCH 02/12] pinctrl: add a pincontrol driver for BCM6328 Álvaro Fernández Rojas
2021-03-02 15:20   ` Linus Walleij [this message]
2021-03-02 16:59     ` Álvaro Fernández Rojas
2021-02-25 16:42 ` [PATCH 03/12] Documentation: add BCM6358 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 15:22   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 04/12] pinctrl: add a pincontrol driver for BCM6358 Álvaro Fernández Rojas
2021-03-02 15:25   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 05/12] Documentation: add BCM6362 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 15:26   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 06/12] pinctrl: add a pincontrol driver for BCM6362 Álvaro Fernández Rojas
2021-02-25 18:41   ` kernel test robot
2021-03-02 15:30   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 07/12] Documentation: add BCM6368 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 15:27   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 08/12] pinctrl: add a pincontrol driver for BCM6368 Álvaro Fernández Rojas
2021-03-02 15:27   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 09/12] Documentation: add BCM63268 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 15:28   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 10/12] pinctrl: add a pincontrol driver for BCM63268 Álvaro Fernández Rojas
2021-03-02 15:28   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 11/12] Documentation: add BCM6318 pincontroller binding documentation Álvaro Fernández Rojas
2021-03-02 15:29   ` Linus Walleij
2021-02-25 16:42 ` [PATCH 12/12] pinctrl: add a pincontrol driver for BCM6318 Álvaro Fernández Rojas
2021-03-02 15:30   ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACRpkdbxAQTft8dapGqBDxM8nbkPvK4i95ND0JBFb_riafZSSg@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=fazilyildiran@gmail.com \
    --cc=jonas.gorski@gmail.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noltari@gmail.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).