mbox series

[0/2] Enable MMIO GPIO on BCMBCA

Message ID 20240917-bcmbca-gpio-mmio-v1-0-674bae8664cc@linaro.org
Headers show
Series Enable MMIO GPIO on BCMBCA | expand

Message

Linus Walleij Sept. 17, 2024, 12:44 p.m. UTC
The Broadcom BCA (Broadband Access) SoC:s all have a dirt-simple
MMIO GPIO.

It's exposed as a direction register per 32-bit block at
(base) and a data register per 32-bit block at (block+0x20).

However I wouldn't want to use any of the old compatibles
becaus for this undocumented SoC I have a gut feeling that
there may be registers we don't know about at (block+0x40)
etc and a separate compatible will be needed to slot in
a more elaborate driver later.

Let's do this the hard way and create a new compatible,
and probe regular MMIO with that for now.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Linus Walleij (2):
      dt-bindings: gpio: Add BCMBCA to MMIO compatibles
      gpio: mmio: Support BCMBCA GPIO compatible

 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml | 1 +
 drivers/gpio/gpio-mmio.c                              | 1 +
 2 files changed, 2 insertions(+)
---
base-commit: 98f7e32f20d28ec452afb208f9cffc08448a2652
change-id: 20240917-bcmbca-gpio-mmio-5da863cf5a5d

Best regards,

Comments

William Zhang Sept. 17, 2024, 6:13 p.m. UTC | #1
Hi Linus,

> -----Original Message-----
> From: Linus Walleij <linus.walleij@linaro.org>
> Sent: Tuesday, September 17, 2024 5:45 AM
> To: Bartosz Golaszewski <brgl@bgdev.pl>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; William Zhang <william.zhang@broadcom.com>;
> Florian Fainelli <florian.fainelli@broadcom.com>
> Cc: linux-gpio@vger.kernel.org; devicetree@vger.kernel.org; Linus Walleij
> <linus.walleij@linaro.org>
> Subject: [PATCH 0/2] Enable MMIO GPIO on BCMBCA
>
> The Broadcom BCA (Broadband Access) SoC:s all have a dirt-simple
> MMIO GPIO.
>
> It's exposed as a direction register per 32-bit block at
> (base) and a data register per 32-bit block at (block+0x20).
>
> However I wouldn't want to use any of the old compatibles
> becaus for this undocumented SoC I have a gut feeling that
> there may be registers we don't know about at (block+0x40)
> etc and a separate compatible will be needed to slot in
> a more elaborate driver later.
>
For the BCMBCA SoCs(ARM based Broadcom broadband SoCs),
there is no need to access any register at block+0x40 and beyond
for gpio function to work.   So I think the existing the brcm,bcm6345-gpio
fits the bill very well and don't need a new compatible IMHO.  It is
the same tradition/rule for other blocks like wdt, nand controller
and etc.  We use the oldest chip name that has the common IP.

If we upstream more elaborated driver later,  it will be a dedicated gpio
controller driver and not use this basic mmio gpio and we can have
the new compatible.

> Let's do this the hard way and create a new compatible,
> and probe regular MMIO with that for now.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Linus Walleij (2):
>       dt-bindings: gpio: Add BCMBCA to MMIO compatibles
>       gpio: mmio: Support BCMBCA GPIO compatible
>
>  Documentation/devicetree/bindings/gpio/gpio-mmio.yaml | 1 +
>  drivers/gpio/gpio-mmio.c                              | 1 +
>  2 files changed, 2 insertions(+)
> ---
> base-commit: 98f7e32f20d28ec452afb208f9cffc08448a2652
> change-id: 20240917-bcmbca-gpio-mmio-5da863cf5a5d
>
> Best regards,
> --
> Linus Walleij <linus.walleij@linaro.org>
Linus Walleij Sept. 17, 2024, 7:03 p.m. UTC | #2
On Tue, Sep 17, 2024 at 8:13 PM William Zhang
<william.zhang@broadcom.com> wrote:

> If we upstream more elaborated driver later,  it will be a dedicated gpio
> controller driver and not use this basic mmio gpio and we can have
> the new compatible.

Thinking of it, in that case the driver would just use one reg = <>
property for the whole I/O range used by the chip and then it need
a new compatible anyway. Let's drop this for now. I'll switch over
to the old compatible.

It seems the approach taken with this SoC is a combination of
simple GPIO and a separate extint (external interrupt) unit, so
it does not need GPIOs to be able to trigger interrupts, which
was my major worry.

Yours,
Linus Walleij
William Zhang Sept. 19, 2024, 12:42 a.m. UTC | #3
On 09/17/2024 12:03 PM, Linus Walleij wrote:
> On Tue, Sep 17, 2024 at 8:13 PM William Zhang
> <william.zhang@broadcom.com> wrote:
> 
>> If we upstream more elaborated driver later,  it will be a dedicated gpio
>> controller driver and not use this basic mmio gpio and we can have
>> the new compatible.
> 
> Thinking of it, in that case the driver would just use one reg = <>
> property for the whole I/O range used by the chip and then it need
> a new compatible anyway. Let's drop this for now. I'll switch over
> to the old compatible.
> 
> It seems the approach taken with this SoC is a combination of
> simple GPIO and a separate extint (external interrupt) unit, so
> it does not need GPIOs to be able to trigger interrupts, which
> was my major worry.
> 
I am looking into this and we should be able to support an irq chip for
this gpio controller that control external interrupt controller. So any
gpio that is configured in external interrupt controller can trigger
an interrupt.

Will post such driver for review when it is ready.

> Yours,
> Linus Walleij
>