From: Linus Walleij <linus.walleij@linaro.org>
To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Tomer Maimon <tmaimon77@gmail.com>, Joel Stanley <joel@jms.id.au>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/8] pinctrl: nuvoton: Add driver for WPCM450
Date: Fri, 4 Jun 2021 11:31:07 +0200 [thread overview]
Message-ID: <CACRpkdb=8e=D9JdwxA+oPGj80WnsV86apuECBp1m-Edd+hKPFQ@mail.gmail.com> (raw)
In-Reply-To: <20210602120329.2444672-6-j.neuschaefer@gmx.net>
Hi Jonathan!
thanks for your patch!
On Wed, Jun 2, 2021 at 2:04 PM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> This driver is heavily based on the one for NPCM7xx, because the WPCM450
> is a predecessor of those SoCs.
>
> The biggest difference is in how the GPIO controller works. In the
> WPCM450, the GPIO registers are not organized in multiple banks, but
> rather placed continually into the same register block, and the driver
> reflects this.
This is unfortunate because now you can't use GPIO_GENERIC anymore.
> Some functionality implemented in the hardware was (for now) left unused
> in the driver, specifically blinking and pull-up/down.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
(...)
> +config PINCTRL_WPCM450
> + bool "Pinctrl and GPIO driver for Nuvoton WPCM450"
> + depends on (ARCH_WPCM450 || COMPILE_TEST) && OF
> + select PINMUX
> + select PINCONF
> + select GENERIC_PINCONF
> + select GPIOLIB
> + select GPIO_GENERIC
You are not using GPIO_GENERIC
> +struct wpcm450_port {
> + /* Range of GPIOs in this port */
> + u8 base;
> + u8 length;
> +
> + /* Register offsets (0 = register doesn't exist in this port) */
> + u8 cfg0, cfg1, cfg2;
> + u8 blink;
> + u8 dataout, datain;
> +};
If you used to have "GPIO banks" and you now have
"GPIO ports" what is the difference? Why can't these ports
just be individula gpio_chip:s with their own device tree
nodes inside the pin controller node?
If you split it up then you can go back to using
GPIO_GENERIC with bgpio_init() again which is a
big win.
All you seem to be doing is setting consecutive
bits in a register by offset, which is what GPIO_GENERIC
is for, just that it assumes offset is always from zero.
If you split it into individual gpio_chips per register
then you get this nice separation and code reuse.
> +static const struct wpcm450_port *to_port(int offset)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(wpcm450_ports); i++)
> + if (offset >= wpcm450_ports[i].base &&
> + offset - wpcm450_ports[i].base < wpcm450_ports[i].length)
> + return &wpcm450_ports[i];
> + return NULL;
> +}
Then you would also get away from this awkward thing.
> +static u32 port_mask(const struct wpcm450_port *port, int offset)
> +{
> + return BIT(offset - port->base);
> +}
And awkwardness like this.
Generally splitting up gpio_chips is a very good idea.
> +static int event_bitmask(int gpio)
> +{
> + if (gpio >= 0 && gpio < 16)
> + return BIT(gpio);
> + if (gpio == 24 || gpio == 25)
> + return BIT(gpio - 8);
> + return -EINVAL;
> +}
> +
> +static int event_bitnum_to_gpio(int num)
> +{
> + if (num >= 0 && num < 16)
> + return num;
> + if (num == 16 || num == 17)
> + return num + 8;
> + return -EINVAL;
> +}
This is also a sign that you have several gpio_chips in practice
and now you need all this awkwardness to get back to which
GPIO is which instead of handling it in a per-chip manner.
This can be done in different ways, the most radical is to have
the pin control driver spawn child devices for each GPIO
block/bank/port with its own driver, but it can also just register
the individual gpio_chips.
Yours,
Linus Walleij
next prev parent reply other threads:[~2021-06-04 9:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 12:03 [PATCH 0/8] Nuvoton WPCM450 pinctrl and GPIO driver Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 1/8] dt-bindings: arm/npcm: Add binding for global control registers (GCR) Jonathan Neuschäfer
2021-06-04 8:00 ` Linus Walleij
2021-06-13 9:20 ` Jonathan Neuschäfer
2021-06-15 23:43 ` Rob Herring
2021-06-19 10:08 ` Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 2/8] MAINTAINERS: Match all of bindings/arm/npcm/ as part of NPCM architecture Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 3/8] ARM: dts: wpcm450: Add global control registers (GCR) node Jonathan Neuschäfer
2021-06-04 8:01 ` Linus Walleij
2021-06-13 9:23 ` Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 4/8] dt-bindings: pinctrl: Add Nuvoton WPCM450 Jonathan Neuschäfer
2021-06-04 9:35 ` Linus Walleij
2021-06-13 9:53 ` Jonathan Neuschäfer
2021-06-15 23:45 ` Rob Herring
2021-06-19 10:17 ` Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 5/8] pinctrl: nuvoton: Add driver for WPCM450 Jonathan Neuschäfer
2021-06-02 12:50 ` Andy Shevchenko
2021-06-12 23:20 ` Jonathan Neuschäfer
2021-06-13 10:06 ` Andy Shevchenko
2021-06-13 19:08 ` Jonathan Neuschäfer
2021-06-02 14:31 ` kernel test robot
2021-06-03 18:33 ` kernel test robot
2021-06-04 9:31 ` Linus Walleij [this message]
2021-06-13 10:26 ` Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 6/8] ARM: dts: wpcm450: Add pinctrl node Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 7/8] ARM: dts: wpcm450: Add pin functions Jonathan Neuschäfer
2021-06-02 12:03 ` [PATCH 8/8] ARM: dts: wpcm450-supermicro-x9sci-ln4f: Add GPIO LEDs and buttons Jonathan Neuschäfer
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='CACRpkdb=8e=D9JdwxA+oPGj80WnsV86apuECBp1m-Edd+hKPFQ@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=j.neuschaefer@gmx.net \
--cc=joel@jms.id.au \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=robh+dt@kernel.org \
--cc=tmaimon77@gmail.com \
/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).