[v4,0/5] Add GPIO support for MStar/SigmaStar ARMv7

Message

Daniel Palmer Nov. 29, 2020, 11:07 a.m. UTC

At the moment the MStar/SigmaStar support is only really
capable of shell from an initramfs and not much else.

Most of the interesting drivers are blocked on clock and pinctrl
drivers and those are going to take me a little while to get cleaned
up.

Clock and pinctrl aren't needed for basic GPIO to work (all pins
start off as GPIOs..) and it makes it possible to actually do something
so this series adds everything that is needed for the main GPIO
block in these chips.

Changes since v3:
- Remove unneeded "gpio-ranges-group-names" property from binding yaml.

Changes since v2:

- Numerous style and code cleanups as suggested by Andy Shevchenko,
  Linus Walleij, Marc Zyngier and Rob Herring.

- Pad names moved out of the binding header because they are no longer
  needed there. The pin/pad numbers are still there as I couldn't think
  of a better way to do this. meson8b-gpio.h seems to be similar.

Changes since v1:

- Moves the binding header commit before the yaml commit
  
- Fixes the license on the binding header to include BSD-2-Clause

- The driver has been reworked to use the gpiolib irqchip functionality
  as suggested by Linus[0]. I think I got this right. The gpio controller
  doesn't actually do anything with interrupts itself.. It just happens
  to have 4 lines that are also wired to lines on one of the interrupt
  controllers.

- Now that the driver is an interrupt controller in it's own right for
  the gpio lines that have associated interrupts the binding description
  has been updated to add the interrupt-controller bits and remove the
  description of the interrupt-names that described how the interrupts
  used to be passed in.

Daniel Palmer (5):
  dt-bindings: gpio: Add a binding header for the MSC313 GPIO driver
  dt-bindings: gpio: Binding for MStar MSC313 GPIO controller
  gpio: msc313: MStar MSC313 GPIO driver
  ARM: mstar: Add gpio controller to MStar base dtsi
  ARM: mstar: Fill in GPIO controller properties for infinity

 .../bindings/gpio/mstar,msc313-gpio.yaml      |  59 +++
 MAINTAINERS                                   |   3 +
 arch/arm/boot/dts/mstar-infinity.dtsi         |   7 +
 arch/arm/boot/dts/mstar-v7.dtsi               |  10 +
 drivers/gpio/Kconfig                          |  11 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-msc313.c                    | 460 ++++++++++++++++++
 include/dt-bindings/gpio/msc313-gpio.h        |  53 ++
 8 files changed, 604 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
 create mode 100644 drivers/gpio/gpio-msc313.c
 create mode 100644 include/dt-bindings/gpio/msc313-gpio.h

Comments

Linus Walleij Dec. 5, 2020, 9:42 p.m. UTC | #1

On Sun, Nov 29, 2020 at 12:08 PM Daniel Palmer <[e-mail]> wrote:

> At the moment the MStar/SigmaStar support is only really
> capable of shell from an initramfs and not much else.
>
> Most of the interesting drivers are blocked on clock and pinctrl
> drivers and those are going to take me a little while to get cleaned
> up.
>
> Clock and pinctrl aren't needed for basic GPIO to work (all pins
> start off as GPIOs..) and it makes it possible to actually do something
> so this series adds everything that is needed for the main GPIO
> block in these chips.
>
> Changes since v3:
> - Remove unneeded "gpio-ranges-group-names" property from binding yaml.

OK finished!
Patches 1, 2 & 3 applied to the GPIO tree for v5.11.

Thanks for the good work!

Yours,
Linus Walleij

Daniel Palmer Dec. 7, 2020, 10:55 a.m. UTC | #2

Hi Linus,

On Sun, 6 Dec 2020 at 06:43, Linus Walleij <[e-mail]> wrote:

> OK finished!
> Patches 1, 2 & 3 applied to the GPIO tree for v5.11.

Awesome! Thank you Linus. :)

Arnd and Olof: Sorry for being a noob.. Is there anything I need to do
for patches 4 and 5 (device tree bits)?
They are in the Linux SoC patchwork.

Thanks,

Daniel

Arnd Bergmann Dec. 9, 2020, 4:47 p.m. UTC | #3

On Mon, Dec 7, 2020 at 11:55 AM Daniel Palmer <[e-mail]> wrote:
>
> Hi Linus,
>
> On Sun, 6 Dec 2020 at 06:43, Linus Walleij <[e-mail]> wrote:
>
> > OK finished!
> > Patches 1, 2 & 3 applied to the GPIO tree for v5.11.
>
> Awesome! Thank you Linus. :)
>
> Arnd and Olof: Sorry for being a noob.. Is there anything I need to do
> for patches 4 and 5 (device tree bits)?
> They are in the Linux SoC patchwork.

I've picked them up from there along with the second series of DT changes.

The easiest way for me though is if you include the patches in a pull request
or patch series that can go through the soc tree in one chunk.

       Arnd

Arnd Bergmann Dec. 9, 2020, 8:30 p.m. UTC | #4

From: Arnd Bergmann <[e-mail]>

On Sun, 29 Nov 2020 20:07:57 +0900, Daniel Palmer wrote:
> At the moment the MStar/SigmaStar support is only really
> capable of shell from an initramfs and not much else.
> 
> Most of the interesting drivers are blocked on clock and pinctrl
> drivers and those are going to take me a little while to get cleaned
> up.
> 
> [...]

Applied to arm/dt, thanks!

[4/5] ARM: mstar: Add gpio controller to MStar base dtsi
      commit: 74530d645126c2934b16db135edaef16eff9e35b
[5/5] ARM: mstar: Fill in GPIO controller properties for infinity
      commit: 5b8a05b9e8d10c8df29bb719e73ea8ed916a1eea

       Arnd

Arnd Bergmann Dec. 9, 2020, 9:40 p.m. UTC | #5

On Wed, Dec 9, 2020 at 5:47 PM Arnd Bergmann <[e-mail]> wrote:
>
> On Mon, Dec 7, 2020 at 11:55 AM Daniel Palmer <[e-mail]> wrote:
> >
> > Hi Linus,
> >
> > On Sun, 6 Dec 2020 at 06:43, Linus Walleij <[e-mail]> wrote:
> >
> > > OK finished!
> > > Patches 1, 2 & 3 applied to the GPIO tree for v5.11.
> >
> > Awesome! Thank you Linus. :)
> >
> > Arnd and Olof: Sorry for being a noob.. Is there anything I need to do
> > for patches 4 and 5 (device tree bits)?
> > They are in the Linux SoC patchwork.
>
> I've picked them up from there along with the second series of DT changes.

And I made a mess, as I had not realized that the DT patches depend on
the dt-binding header. I've applied that patch on top now to make my
branch build cleanly again, even though it is not fully bisectable.

        Arnd