Message-ID: <aKCs2jUcYxYHWIB2@pie>
Date: Sat, 16 Aug 2025 16:07:54 +0000
From: Yao Zi <ziyao@...root.org>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: Yinbo Zhu <zhuyinbo@...ngson.cn>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, WANG Xuerui <kernel@...0n.name>,
	Philipp Zabel <p.zabel@...gutronix.de>, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	loongarch@...ts.linux.dev, Mingcong Bai <jeffbai@...c.io>,
	Kexy Biscuit <kexybiscuit@...c.io>
Subject: Re: [PATCH 1/3] dt-bindings: gpio: loongson: Document GPIO
 controller of 2K0300 SoC

On Sat, Aug 16, 2025 at 10:18:57PM +0800, Huacai Chen wrote:
> On Sat, Aug 16, 2025 at 11:51 AM Yao Zi <ziyao@...root.org> wrote:
> >
> > Loongson 2K0300 ships a GPIO controller whose input/output control logic
> > is similar to previous generation of SoCs. Additionally, it acts as an
> > interrupt-controller supporting both level and edge interrupts and has a
> > distinct reset signal.
> >
> > Describe its compatible in devicetree. We enlarge the maximum value of
> > ngpios to 128, since the controller technically supports at most 128
> > pins, although only 106 are routed out of the package. Properties for
> > interrupt-controllers and resets are introduced and limited as 2K0300
> > only.
> >
> > Signed-off-by: Yao Zi <ziyao@...root.org>
> > ---
> >  .../bindings/gpio/loongson,ls-gpio.yaml       | 28 ++++++++++++++++++-
> >  1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > index b68159600e2b..69852444df23 100644
> > --- a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
> > @@ -14,6 +14,7 @@ properties:
> >      oneOf:
> >        - enum:
> >            - loongson,ls2k-gpio
> > +          - loongson,ls2k0300-gpio
> >            - loongson,ls2k0500-gpio0
> >            - loongson,ls2k0500-gpio1
> >            - loongson,ls2k2000-gpio0
> > @@ -36,7 +37,7 @@ properties:
> >
> >    ngpios:
> >      minimum: 1
> > -    maximum: 64
> > +    maximum: 128
> >
> >    "#gpio-cells":
> >      const: 2
> > @@ -49,6 +50,14 @@ properties:
> >      minItems: 1
> >      maxItems: 64
> >
> > +  "#interrupt-cells":
> > +    const: 2
> > +
> > +  interrupt-controller: true
> ls2k300 supports interrupt-controller while others don't?

For these SoCs' GPIO controllers (I didn't carefully check 3A{5,6}00 and
7A{1,2}00), there're three different cases,

1. Controller of 2K0500, 2K1000:

   These controllers have only interrupt enable bits for each GPIO.
   Interrupts are routed directly to the parent interrupt controller and
   there're multiple pins share the same interrupt in the parent, e.g.,
   GPIO 0-31 share interrupt 26 of the second liointc on 2K0500.

   Since we have neither an interrupt status register nor interrupt ack
   bits, it's hard to tell which GPIO line is triggering the interrupt.
   And we even cannot configure the polarity/edge for triggering
   interrupts, thus I don't think these GPIO controller should be
   described as interrupt controllers.

   For these controllers, gpio-loongson-64bit.c implements GPIO
   controller's .to_irq() method which translates GPIO descriptor to
   corresponding IRQ number. This should work as long as there's at most
   one interrupt consumer for each group of GPIOs that share the same
   parent interrupt line.

2. Node controller of 2K1500 and 2K2000:

   These SoCs have GPIO controllers directly attached to the "node" (I
   think it means the CPU core, but am not sure). These controllers are
   similar to the first class, but they have an additional feature that
   the polarity for triggering interrupts could be configured.

   Still we couldn't precisely tell which GPIO line is triggering the
   interrupt, thus it's hard to implement it as a fully-functional
   irqchip, either. But if we don't do so, I cannot come up with a way
   to describe the polarity settings. I'm unsure whether these
   controllers should be implemented as interrupt controllers.

3. South-bridge controller of 2K1500 and 2K2000, and 2K0300's
   controller:

   Reading through the public TRM, I'm sure these're all fully
   functional interrupt controllers, and should be implemented as
   interrupt controllers.

   However, this also means the current binding for 2K1500/2K2000's
   south-bridge controller is WRONG, and a fix it seems to bring in ABI
   breakages (interrupt-controller/interrupt-cells are a must). But
   since I don't have these devices on hand, and they are at least not
   related to the situation of 2K0300, I decided to keep them as-is.

So the answer to the original question is, no, at least 2K1500/2K2000's
south-bridge GPIO controllers are also interrupt controllers according
to their public documentation. But I cannot test my GPIO changes against
them since I don't have such boards, and fixing the binding up may break
the ABI, thus I leave them as-is in this "support for 2K0300" series.

> Huacai

Best regards,
Yao Zi

> > +
> > +  resets:
> > +    maxItems: 1
> > +
> >  required:
> >    - compatible
> >    - reg
> > @@ -58,6 +67,23 @@ required:
> >    - gpio-ranges
> >    - interrupts
> >
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: loongson,ls2k0300-gpio
> > +    then:
> > +      required:
> > +        - "#interrupt-cells"
> > +        - interrupt-controller
> > +        - resets
> > +    else:
> > +      properties:
> > +        "#interrupts-cells": false
> > +        interrupt-controller: false
> > +        resets: false
> > +
> >  additionalProperties: false
> >
> >  examples:
> > --
> > 2.50.1
> >

Powered by blists - more mailing lists