From: Yixun Lan <dlan@gentoo.org>
To: Rob Herring <robh@kernel.org>
Cc: Olof Johansson <olof@lixom.net>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Conor Dooley <conor@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Yangyu Chen <cyy@cyyself.name>,
Jisheng Zhang <jszhang@kernel.org>,
Jesse Taube <mr.bossman075@gmail.com>,
Inochi Amaoto <inochiama@outlook.com>,
Icenowy Zheng <uwu@icenowy.me>,
Meng Zhang <zhangmeng.kevin@linux.spacemit.com>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v4 1/4] dt-bindings: gpio: spacemit: add support for K1 SoC
Date: Tue, 28 Jan 2025 03:17:12 +0000 [thread overview]
Message-ID: <20250128031712-GYB47737@gentoo> (raw)
In-Reply-To: <20250127181726.GA538260-robh@kernel.org>
Hi Rob:
On 12:17 Mon 27 Jan , Rob Herring wrote:
> On Thu, Jan 23, 2025 at 03:19:18PM -0800, Olof Johansson wrote:
> > On Thu, Jan 23, 2025 at 11:30:42AM +0000, Yixun Lan wrote:
> > > Hi Olof:
> > > thanks for your reivew
> > >
> > > On 12:03 Wed 22 Jan , Olof Johansson wrote:
> > > > Hi,
> > > >
> > > > On Tue, Jan 21, 2025 at 11:38:11AM +0800, Yixun Lan wrote:
> > > > > The GPIO controller of K1 support basic functions as input/output,
> > > > > all pins can be used as interrupt which route to one IRQ line,
> > > > > trigger type can be select between rising edge, failing edge, or both.
> > > > > There are four GPIO ports, each consisting of 32 pins.
> > > > >
> > > > > Signed-off-by: Yixun Lan <dlan@gentoo.org>
> > > > > ---
> > > > > .../devicetree/bindings/gpio/spacemit,k1-gpio.yaml | 116 +++++++++++++++++++++
> > > > > 1 file changed, 116 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..dd9459061aecfcba84e6a3c5052fbcddf6c61150
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
> > > > > @@ -0,0 +1,116 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/gpio/spacemit,k1-gpio.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: SpacemiT K1 GPIO controller
> > > > > +
> > > > > +maintainers:
> > > > > + - Yixun Lan <dlan@gentoo.org>
> > > > > +
> > > > > +description:
> > > > > + The controller's registers are organized as sets of eight 32-bit
> > > > > + registers with each set of port controlling 32 pins. A single
> > > > > + interrupt line is shared for all of the pins by the controller.
> > > > > + Each port will be represented as child nodes with the generic
> > > > > + GPIO-controller properties in this bindings file.
> > > >
> > > > There's only one interrupt line for all ports, but you have a binding that
> > > > duplicates them for every set of ports. That seems overly complicated,
> > > > doesn't it? They'd all bind the same handler, so there's no benefit in
> > > > providing the flexibility,.
> > > >
> > > yes, all ports share same interrupt line, but each port has its own
> > > irq related handling register, so it make sense to describe as per gpio irqchip
> > >
> > > also see comments below
> > >
> > > > > +properties:
> > > > > + $nodename:
> > > > > + pattern: "^gpio@[0-9a-f]+$"
> > > > > +
> > > > > + compatible:
> > > > > + const: spacemit,k1-gpio
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + "#address-cells":
> > > > > + const: 1
> > > > > +
> > > > > + "#size-cells":
> > > > > + const: 0
> > > > > +
> > > > > +patternProperties:
> > > > > + "^gpio-port@[0-9a-f]+$":
> > > > > + type: object
> > > > > + properties:
> > > > > + compatible:
> > > > > + const: spacemit,k1-gpio-port
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + gpio-controller: true
> > > > > +
> > > > > + "#gpio-cells":
> > > > > + const: 2
> > > > > +
> > > > > + gpio-ranges: true
> > > > > +
> > > > > + interrupts:
> > > > > + maxItems: 1
> > > > > +
> > > > > + interrupt-controller: true
> > > > > +
> > > > > + "#interrupt-cells":
> > > > > + const: 2
> > > > > + description:
> > > > > + The first cell is the GPIO number, the second should specify interrupt
> > > > > + flag. The controller does not support level interrupts, so flags of
> > > > > + IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_LEVEL_LOW should not be used.
> > > > > + Refer <dt-bindings/interrupt-controller/irq.h> for valid flags.
> > > >
> > > > Same here, since there's no real flexibility between the banks, it might
> > > > make sense to consider a 3-cell GPIO specifier instead, and having
> > > how to handle the fourth gpio port? I would like to have uniform driver for all ports
> > >
> > > > the first cell indicate bank. I could see this argument go in either
> > > > direction, but I'm not sure I understand why to provide a gpio-controller
> > > > per bank.
> > > >
> > >
> > > IIUC, your suggestion here was same as the implementation of patch v3 of this driver[1],
> > > while combining all four ports into one irqchip, which NACKed by maintainer[2].
> > > I tend to agree having a gpio-controller per bank provide more flexibility,
> > > easy to leverage generic gpio framework, even each port can be disabled or enabled,
> > > and IMO having shared irq handler isn't really a problem..
> > >
> > > [1] https://lore.kernel.org/r/20241225-03-k1-gpio-v3-0-27bb7b441d62@gentoo.org
> > > [2] https://lore.kernel.org/r/CACRpkdZPD2C2iPwOX_kW1Ug8jVkdHhhc7iFycHtzj5LQ0XWNgQ@mail.gmail.com
> > > https://lore.kernel.org/r/CACRpkdYgGho=VQabonq4HccEiXBH2qM76K45oDaV1Jyi0xZ-YA@mail.gmail.com
> >
> > Hmm, I don't understand the reasoning there, but it's not my subsystem.
> >
> > It seems worse to me to misdescribe the hardware as separate blocks
> > with a device-tree binding that no longer describes the actual hardware,
> > but it's not up to me.
>
> I agree. It's clearly 1 block given the first 3 banks are interleaved.
>
yes, it's kind of weird hardware design, the first 3 gpio are register interleaved,
while the 4th has independent space
> If Linux can't handle 1 node for N gpio_chip's, then that's a Linux
> problem. Maybe it can, IDK.
I haven't seen somthing like this to register 1 node for multi gpio_chips..
To gpio/pinctrl maintainer (Linus Walleij), do you have suggestion on this?
>The lookup from a DT node to gpio_chip just
> needs to match on more than just DT node pointer, but look at the node
> ptr and arg cells.
>
IIUC, are you suggesting to add a index cells to match additional gpio bank?
so the underlying driver can still register 4 gpio chips?
gpio: gpio@d4019000 {
compatible = "spacemit,k1-gpio";
reg = <0x0 0xd4019000 0x0 0x800>;
interrupt-controller;
#interrupt-cells = <3>; // additional cell
gpio-controller;
#gpio-cells = <3>; // additional cell
...
};
on comsumer side, it will be something like this:
gpios = <&gpio INDEX0 0 GPIO_ACTIVE_HIGH>;
interrupts = <&gpio INDEX0 0 IRQ_TYPE_EDGE_RISING>;
(INDEX0 possiblely can be numeric vale (0, 1, 2, 3) or register base: 0x0 0x4 0x8 0x100)
one thing I'm not sure about how to map the pinctrl pins via "gpio-ranges" to each gpio_chip,
currently, in v4 verion, this info is populated via sub node of gpios (port1, port2 ...)
I will investigate more on this.. but need suggestion to know if I proceed at right direction
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
WARNING: multiple messages have this Message-ID (diff)
From: Yixun Lan <dlan@gentoo.org>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
Meng Zhang <zhangmeng.kevin@linux.spacemit.com>,
linux-gpio@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
linux-kernel@vger.kernel.org, Conor Dooley <conor@kernel.org>,
Yangyu Chen <cyy@cyyself.name>,
linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Jesse Taube <mr.bossman075@gmail.com>,
Jisheng Zhang <jszhang@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Olof Johansson <olof@lixom.net>,
Inochi Amaoto <inochiama@outlook.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [PATCH v4 1/4] dt-bindings: gpio: spacemit: add support for K1 SoC
Date: Tue, 28 Jan 2025 03:17:12 +0000 [thread overview]
Message-ID: <20250128031712-GYB47737@gentoo> (raw)
In-Reply-To: <20250127181726.GA538260-robh@kernel.org>
Hi Rob:
On 12:17 Mon 27 Jan , Rob Herring wrote:
> On Thu, Jan 23, 2025 at 03:19:18PM -0800, Olof Johansson wrote:
> > On Thu, Jan 23, 2025 at 11:30:42AM +0000, Yixun Lan wrote:
> > > Hi Olof:
> > > thanks for your reivew
> > >
> > > On 12:03 Wed 22 Jan , Olof Johansson wrote:
> > > > Hi,
> > > >
> > > > On Tue, Jan 21, 2025 at 11:38:11AM +0800, Yixun Lan wrote:
> > > > > The GPIO controller of K1 support basic functions as input/output,
> > > > > all pins can be used as interrupt which route to one IRQ line,
> > > > > trigger type can be select between rising edge, failing edge, or both.
> > > > > There are four GPIO ports, each consisting of 32 pins.
> > > > >
> > > > > Signed-off-by: Yixun Lan <dlan@gentoo.org>
> > > > > ---
> > > > > .../devicetree/bindings/gpio/spacemit,k1-gpio.yaml | 116 +++++++++++++++++++++
> > > > > 1 file changed, 116 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..dd9459061aecfcba84e6a3c5052fbcddf6c61150
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
> > > > > @@ -0,0 +1,116 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/gpio/spacemit,k1-gpio.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: SpacemiT K1 GPIO controller
> > > > > +
> > > > > +maintainers:
> > > > > + - Yixun Lan <dlan@gentoo.org>
> > > > > +
> > > > > +description:
> > > > > + The controller's registers are organized as sets of eight 32-bit
> > > > > + registers with each set of port controlling 32 pins. A single
> > > > > + interrupt line is shared for all of the pins by the controller.
> > > > > + Each port will be represented as child nodes with the generic
> > > > > + GPIO-controller properties in this bindings file.
> > > >
> > > > There's only one interrupt line for all ports, but you have a binding that
> > > > duplicates them for every set of ports. That seems overly complicated,
> > > > doesn't it? They'd all bind the same handler, so there's no benefit in
> > > > providing the flexibility,.
> > > >
> > > yes, all ports share same interrupt line, but each port has its own
> > > irq related handling register, so it make sense to describe as per gpio irqchip
> > >
> > > also see comments below
> > >
> > > > > +properties:
> > > > > + $nodename:
> > > > > + pattern: "^gpio@[0-9a-f]+$"
> > > > > +
> > > > > + compatible:
> > > > > + const: spacemit,k1-gpio
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + "#address-cells":
> > > > > + const: 1
> > > > > +
> > > > > + "#size-cells":
> > > > > + const: 0
> > > > > +
> > > > > +patternProperties:
> > > > > + "^gpio-port@[0-9a-f]+$":
> > > > > + type: object
> > > > > + properties:
> > > > > + compatible:
> > > > > + const: spacemit,k1-gpio-port
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + gpio-controller: true
> > > > > +
> > > > > + "#gpio-cells":
> > > > > + const: 2
> > > > > +
> > > > > + gpio-ranges: true
> > > > > +
> > > > > + interrupts:
> > > > > + maxItems: 1
> > > > > +
> > > > > + interrupt-controller: true
> > > > > +
> > > > > + "#interrupt-cells":
> > > > > + const: 2
> > > > > + description:
> > > > > + The first cell is the GPIO number, the second should specify interrupt
> > > > > + flag. The controller does not support level interrupts, so flags of
> > > > > + IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_LEVEL_LOW should not be used.
> > > > > + Refer <dt-bindings/interrupt-controller/irq.h> for valid flags.
> > > >
> > > > Same here, since there's no real flexibility between the banks, it might
> > > > make sense to consider a 3-cell GPIO specifier instead, and having
> > > how to handle the fourth gpio port? I would like to have uniform driver for all ports
> > >
> > > > the first cell indicate bank. I could see this argument go in either
> > > > direction, but I'm not sure I understand why to provide a gpio-controller
> > > > per bank.
> > > >
> > >
> > > IIUC, your suggestion here was same as the implementation of patch v3 of this driver[1],
> > > while combining all four ports into one irqchip, which NACKed by maintainer[2].
> > > I tend to agree having a gpio-controller per bank provide more flexibility,
> > > easy to leverage generic gpio framework, even each port can be disabled or enabled,
> > > and IMO having shared irq handler isn't really a problem..
> > >
> > > [1] https://lore.kernel.org/r/20241225-03-k1-gpio-v3-0-27bb7b441d62@gentoo.org
> > > [2] https://lore.kernel.org/r/CACRpkdZPD2C2iPwOX_kW1Ug8jVkdHhhc7iFycHtzj5LQ0XWNgQ@mail.gmail.com
> > > https://lore.kernel.org/r/CACRpkdYgGho=VQabonq4HccEiXBH2qM76K45oDaV1Jyi0xZ-YA@mail.gmail.com
> >
> > Hmm, I don't understand the reasoning there, but it's not my subsystem.
> >
> > It seems worse to me to misdescribe the hardware as separate blocks
> > with a device-tree binding that no longer describes the actual hardware,
> > but it's not up to me.
>
> I agree. It's clearly 1 block given the first 3 banks are interleaved.
>
yes, it's kind of weird hardware design, the first 3 gpio are register interleaved,
while the 4th has independent space
> If Linux can't handle 1 node for N gpio_chip's, then that's a Linux
> problem. Maybe it can, IDK.
I haven't seen somthing like this to register 1 node for multi gpio_chips..
To gpio/pinctrl maintainer (Linus Walleij), do you have suggestion on this?
>The lookup from a DT node to gpio_chip just
> needs to match on more than just DT node pointer, but look at the node
> ptr and arg cells.
>
IIUC, are you suggesting to add a index cells to match additional gpio bank?
so the underlying driver can still register 4 gpio chips?
gpio: gpio@d4019000 {
compatible = "spacemit,k1-gpio";
reg = <0x0 0xd4019000 0x0 0x800>;
interrupt-controller;
#interrupt-cells = <3>; // additional cell
gpio-controller;
#gpio-cells = <3>; // additional cell
...
};
on comsumer side, it will be something like this:
gpios = <&gpio INDEX0 0 GPIO_ACTIVE_HIGH>;
interrupts = <&gpio INDEX0 0 IRQ_TYPE_EDGE_RISING>;
(INDEX0 possiblely can be numeric vale (0, 1, 2, 3) or register base: 0x0 0x4 0x8 0x100)
one thing I'm not sure about how to map the pinctrl pins via "gpio-ranges" to each gpio_chip,
currently, in v4 verion, this info is populated via sub node of gpios (port1, port2 ...)
I will investigate more on this.. but need suggestion to know if I proceed at right direction
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-01-28 3:17 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 3:38 [PATCH v4 0/4] riscv: spacemit: add gpio support for K1 SoC Yixun Lan
2025-01-21 3:38 ` Yixun Lan
2025-01-21 3:38 ` [PATCH v4 1/4] dt-bindings: gpio: spacemit: add " Yixun Lan
2025-01-21 3:38 ` Yixun Lan
2025-01-22 20:03 ` Olof Johansson
2025-01-22 20:03 ` Olof Johansson
2025-01-23 11:30 ` Yixun Lan
2025-01-23 11:30 ` Yixun Lan
2025-01-23 23:19 ` Olof Johansson
2025-01-23 23:19 ` Olof Johansson
2025-01-27 18:17 ` Rob Herring
2025-01-27 18:17 ` Rob Herring
2025-01-28 3:17 ` Yixun Lan [this message]
2025-01-28 3:17 ` Yixun Lan
2025-01-28 16:03 ` Linus Walleij
2025-01-28 16:03 ` Linus Walleij
2025-01-28 16:58 ` Rob Herring
2025-01-28 16:58 ` Rob Herring
2025-01-28 18:50 ` Samuel Holland
2025-01-28 18:50 ` Samuel Holland
2025-02-06 9:18 ` Linus Walleij
2025-02-06 9:18 ` Linus Walleij
2025-02-06 10:39 ` Yixun Lan
2025-02-06 10:39 ` Yixun Lan
2025-02-06 13:31 ` Yixun Lan
2025-02-06 13:31 ` Yixun Lan
2025-02-13 13:07 ` Linus Walleij
2025-02-13 13:07 ` Linus Walleij
2025-02-14 11:54 ` Yixun Lan
2025-02-14 11:54 ` Yixun Lan
2025-02-14 13:08 ` Yixun Lan
2025-02-14 13:08 ` Yixun Lan
2025-02-18 9:44 ` Linus Walleij
2025-02-18 9:44 ` Linus Walleij
2025-02-18 9:55 ` Yixun Lan
2025-02-18 9:55 ` Yixun Lan
2025-02-18 10:17 ` Linus Walleij
2025-02-18 10:17 ` Linus Walleij
2025-02-18 10:59 ` Yixun Lan
2025-02-18 10:59 ` Yixun Lan
2025-01-28 15:47 ` Linus Walleij
2025-01-28 15:47 ` Linus Walleij
2025-01-21 3:38 ` [PATCH v4 2/4] " Yixun Lan
2025-01-21 3:38 ` Yixun Lan
2025-02-07 10:56 ` Yixun Lan
2025-02-07 10:56 ` Yixun Lan
2025-02-15 21:11 ` Alex Elder
2025-02-15 21:11 ` Alex Elder
2025-02-16 12:56 ` Yixun Lan
2025-02-16 12:56 ` Yixun Lan
2025-01-21 3:38 ` [PATCH v4 3/4] riscv: dts: spacemit: add gpio " Yixun Lan
2025-01-21 3:38 ` Yixun Lan
2025-01-21 3:38 ` [PATCH v4 4/4] riscv: dts: spacemit: add gpio LED for system heartbeat Yixun Lan
2025-01-21 3:38 ` Yixun Lan
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=20250128031712-GYB47737@gentoo \
--to=dlan@gentoo.org \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=cyy@cyyself.name \
--cc=devicetree@vger.kernel.org \
--cc=inochiama@outlook.com \
--cc=jszhang@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mr.bossman075@gmail.com \
--cc=olof@lixom.net \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=uwu@icenowy.me \
--cc=zhangmeng.kevin@linux.spacemit.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.