All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"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: Sun, 13 Jun 2021 12:26:37 +0200	[thread overview]
Message-ID: <YMXdXY+R4e1m3nbx@latitude> (raw)
In-Reply-To: <CACRpkdb=8e=D9JdwxA+oPGj80WnsV86apuECBp1m-Edd+hKPFQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]

On Fri, Jun 04, 2021 at 11:31:07AM +0200, Linus Walleij wrote:
> 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

I'll remove the this line (depending on the outcome of the rest of the
discussion).

> 
> > +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?

The naming difference is a fairly arbitrary choice by me.

The real difference is in how the GPIO registers are laid out.
On NPCM7xx, there are blocks of registers at +0, +0x1000, +0x2000,
etc., and within a block, the registers have the same offsets.
On WPCM450, the registers are all mushed together as tightly as
possible[1], so that (a) the ports/banks don't start at nice addresses,
and (b) the register layout can't be predicted from the offset of the
first register in a port (because not all ports have all registers).

> 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.

Indeed, if I keep the wpcm450_ports table but use it to call bgpio_init()
with the right register addresses, I think bgpio_init() can work.


Thanks,
Jonathan Neuschäfer


[1]: https://github.com/neuschaefer/wpcm450/wiki/GPIOs-and-pinmux#gpio

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Tomer Maimon" <tmaimon77@gmail.com>,
	"OpenBMC Maillist" <openbmc@lists.ozlabs.org>,
	"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>
Subject: Re: [PATCH 5/8] pinctrl: nuvoton: Add driver for WPCM450
Date: Sun, 13 Jun 2021 12:26:37 +0200	[thread overview]
Message-ID: <YMXdXY+R4e1m3nbx@latitude> (raw)
In-Reply-To: <CACRpkdb=8e=D9JdwxA+oPGj80WnsV86apuECBp1m-Edd+hKPFQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]

On Fri, Jun 04, 2021 at 11:31:07AM +0200, Linus Walleij wrote:
> 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

I'll remove the this line (depending on the outcome of the rest of the
discussion).

> 
> > +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?

The naming difference is a fairly arbitrary choice by me.

The real difference is in how the GPIO registers are laid out.
On NPCM7xx, there are blocks of registers at +0, +0x1000, +0x2000,
etc., and within a block, the registers have the same offsets.
On WPCM450, the registers are all mushed together as tightly as
possible[1], so that (a) the ports/banks don't start at nice addresses,
and (b) the register layout can't be predicted from the offset of the
first register in a port (because not all ports have all registers).

> 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.

Indeed, if I keep the wpcm450_ports table but use it to call bgpio_init()
with the right register addresses, I think bgpio_init() can work.


Thanks,
Jonathan Neuschäfer


[1]: https://github.com/neuschaefer/wpcm450/wiki/GPIOs-and-pinmux#gpio

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-06-13 10:26 UTC|newest]

Thread overview: 56+ 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 ` 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-02 12:03   ` Jonathan Neuschäfer
2021-06-04  8:00   ` Linus Walleij
2021-06-04  8:00     ` Linus Walleij
2021-06-13  9:20     ` Jonathan Neuschäfer
2021-06-13  9:20       ` Jonathan Neuschäfer
2021-06-15 23:43   ` Rob Herring
2021-06-15 23:43     ` Rob Herring
2021-06-19 10:08     ` Jonathan Neuschäfer
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   ` 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-02 12:03   ` Jonathan Neuschäfer
2021-06-04  8:01   ` Linus Walleij
2021-06-04  8:01     ` Linus Walleij
2021-06-13  9:23     ` Jonathan Neuschäfer
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-02 12:03   ` Jonathan Neuschäfer
2021-06-04  9:35   ` Linus Walleij
2021-06-04  9:35     ` Linus Walleij
2021-06-13  9:53     ` Jonathan Neuschäfer
2021-06-13  9:53       ` Jonathan Neuschäfer
2021-06-15 23:45   ` Rob Herring
2021-06-15 23:45     ` Rob Herring
2021-06-19 10:17     ` Jonathan Neuschäfer
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:03   ` Jonathan Neuschäfer
2021-06-02 12:50   ` Andy Shevchenko
2021-06-02 12:50     ` Andy Shevchenko
2021-06-12 23:20     ` Jonathan Neuschäfer
2021-06-12 23:20       ` Jonathan Neuschäfer
2021-06-13 10:06       ` Andy Shevchenko
2021-06-13 10:06         ` Andy Shevchenko
2021-06-13 19:08         ` Jonathan Neuschäfer
2021-06-13 19:08           ` Jonathan Neuschäfer
2021-06-02 14:31   ` kernel test robot
2021-06-02 14:31     ` kernel test robot
2021-06-02 14:31     ` kernel test robot
2021-06-03 18:33   ` kernel test robot
2021-06-03 18:33     ` kernel test robot
2021-06-03 18:33     ` kernel test robot
2021-06-04  9:31   ` Linus Walleij
2021-06-04  9:31     ` Linus Walleij
2021-06-13 10:26     ` Jonathan Neuschäfer [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   ` 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   ` 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
2021-06-02 12:03   ` 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=YMXdXY+R4e1m3nbx@latitude \
    --to=j.neuschaefer@gmx.net \
    --cc=devicetree@vger.kernel.org \
    --cc=joel@jms.id.au \
    --cc=linus.walleij@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.