mbox series

[0/5] pinctrl: allow storing pins, groups & functions in DT

Message ID 20211118132152.15722-1-zajec5@gmail.com (mailing list archive)
Headers show
Series pinctrl: allow storing pins, groups & functions in DT | expand

Message

Rafał Miłecki Nov. 18, 2021, 1:21 p.m. UTC
From: Rafał Miłecki <rafal@milecki.pl>

A week ago I sent
[PATCH RFC] dt-bindings: pinctrl: support specifying pins
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20211110231436.8866-1-zajec5@gmail.com/

From short discussion in that thread it seems that using DT to store
pinctrl pins, groups & functions may be an option. I'd like to ask for
reviewing my patchset implementing that.

Please note it's about describing hardware elements and not actual
programming way. It may be used with pinctrl-single.c one day but it's
designed as a generic solution for data.

Patches 1-4 are for linux-pinctrl.git. Patch 5 I found worth including
as DT big example. It can go through Linus with Florian's Ack or I can
send it to Florian later.

Rafał Miłecki (5):
  dt-bindings: pinctrl: support specifying pins, groups & functions
  dt-bindings: pinctrl: brcm,ns-pinmux: extend example
  pinctrl: add helpers reading pins, groups & functions from DT
  pinctrl: bcm: pinctrl-ns: supoprt DT specified pins, groups &
    functions
  ARM: dts: BCM5301X: add pinctrl pins, groups & functions

 .../bindings/pinctrl/brcm,ns-pinmux.yaml      |  29 ++++-
 .../devicetree/bindings/pinctrl/pinctrl.yaml  |  50 +++++++
 arch/arm/boot/dts/bcm4709.dtsi                |  74 +++++++++++
 arch/arm/boot/dts/bcm47094.dtsi               |  11 +-
 arch/arm/boot/dts/bcm5301x.dtsi               | 123 ++++++++++++++++++
 drivers/pinctrl/bcm/pinctrl-ns.c              |  90 ++++++++-----
 drivers/pinctrl/core.c                        |  89 +++++++++++++
 drivers/pinctrl/core.h                        |   5 +
 drivers/pinctrl/pinmux.c                      |  43 ++++++
 drivers/pinctrl/pinmux.h                      |   2 +
 10 files changed, 475 insertions(+), 41 deletions(-)

Comments

Andy Shevchenko Nov. 18, 2021, 1:52 p.m. UTC | #1
On Thu, Nov 18, 2021 at 3:22 PM Rafał Miłecki <zajec5@gmail.com> wrote:
>
> From: Rafał Miłecki <rafal@milecki.pl>
>
> A week ago I sent
> [PATCH RFC] dt-bindings: pinctrl: support specifying pins
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20211110231436.8866-1-zajec5@gmail.com/
>
> From short discussion in that thread it seems that using DT to store
> pinctrl pins, groups & functions may be an option. I'd like to ask for
> reviewing my patchset implementing that.
>
> Please note it's about describing hardware elements and not actual
> programming way. It may be used with pinctrl-single.c one day but it's
> designed as a generic solution for data.
>
> Patches 1-4 are for linux-pinctrl.git. Patch 5 I found worth including
> as DT big example. It can go through Linus with Florian's Ack or I can
> send it to Florian later.

DT is not the only one,

So, I would like to see some kind of roadmap / vision on how this can
be useful in the ACPI case.
Rafał Miłecki Nov. 18, 2021, 1:59 p.m. UTC | #2
On 18.11.2021 14:52, Andy Shevchenko wrote:
> DT is not the only one,
> 
> So, I would like to see some kind of roadmap / vision on how this can
> be useful in the ACPI case.

Unfortunately I don't do any ACPI development and I also have zero ACPI
experience. I'm not sure how to proceed with this. Does ACPI have some
tables that get translated into DT-like form? Can I emulate that and
test somehow?

Anyone else willing to help on the ACPI part?
Andy Shevchenko Nov. 18, 2021, 4:30 p.m. UTC | #3
On Thu, Nov 18, 2021 at 3:59 PM Rafał Miłecki <zajec5@gmail.com> wrote:
> On 18.11.2021 14:52, Andy Shevchenko wrote:
> > DT is not the only one,
> >
> > So, I would like to see some kind of roadmap / vision on how this can
> > be useful in the ACPI case.
>
> Unfortunately I don't do any ACPI development and I also have zero ACPI
> experience. I'm not sure how to proceed with this. Does ACPI have some
> tables that get translated into DT-like form? Can I emulate that and
> test somehow?
>
> Anyone else willing to help on the ACPI part?

As I elaborated in the subthread of patch 3 you don't need to care
about ACPI _implementation_, only about _design_ that will give no
obstacles to have the ACPI part be implemented. I may do it in case
somebody prepares internal APIs and data structures for the
interaction with FW (descriptions). That said, you don't need to know
the ACPI details at all. Ask questions in case you are in doubt, I
would be happy to help.