Rob Herring wrote: > On Fri, May 17, 2024 at 07:48:17AM -0500, Emil Renner Berthing wrote: > > Rob Herring wrote: > > > On Wed, Jan 03, 2024 at 02:28:38PM +0100, Emil Renner Berthing wrote: > > > > Add bindings for the pin controllers on the T-Head TH1520 RISC-V SoC. > > > > > > > > Signed-off-by: Emil Renner Berthing <emil.renner.berthing@xxxxxxxxxxxxx> > > > > --- > > > > .../pinctrl/thead,th1520-pinctrl.yaml | 372 ++++++++++++++++++ > > > > 1 file changed, 372 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml > > > > new file mode 100644 > > > > index 000000000000..d3ad7a7cfdd1 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml > > > > @@ -0,0 +1,372 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/pinctrl/thead,th1520-pinctrl.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: T-Head TH1520 SoC pin controller > > > > + > > > > +maintainers: > > > > + - Emil Renner Berthing <emil.renner.berthing@xxxxxxxxxxxxx> > > > > + > > > > +description: | > > > > + Pinmux and pinconf controller in the T-Head TH1520 RISC-V SoC. > > > > + > > > > + The TH1520 has 3 groups of pads each controlled from different memory ranges. > > > > + Confusingly the memory ranges are named > > > > + PADCTRL_AOSYS -> PAD Group 1 > > > > + PADCTRL1_APSYS -> PAD Group 2 > > > > + PADCTRL0_APSYS -> PAD Group 3 > > > > + > > > > + Each pad can be muxed individually to up to 6 different functions. For most > > > > + pads only a few of those 6 configurations are valid though, and a few pads in > > > > + group 1 does not support muxing at all. > > > > + > > > > + Pinconf is fairly regular except for a few pads in group 1 that either can't > > > > + be configured or has some special functions. The rest have configurable drive > > > > + strength, input enable, schmitt trigger, slew rate, pull-up and pull-down in > > > > + addition to a special strong pull up. > > > > + > > > > + Certain pads in group 1 can be muxed to AUDIO_PA0 - AUDIO_PA30 functions and > > > > + are then meant to be used by the audio co-processor. Each such pad can then > > > > + be further muxed to either audio GPIO or one of 4 functions such as UART, I2C > > > > + and I2S. If the audio pad is muxed to one of the 4 functions then pinconf is > > > > + also configured in different registers. All of this is done from a different > > > > + AUDIO_IOCTRL memory range and is left to the audio co-processor for now. > > > > > > It is still not clear to me if each instance is a different programming > > > model or the same with just different connections. The latter should > > > be the same compatible string. That needs to be answered in *this* > > > patch, not a reply. > > > > Hi Rob, > > > > Sorry for the late response. I honestly don't know exactly what you mean by > > differenty programming models and what the difference is, so I'll need a bit of > > help with what you want me to write here. > > Is the register interface of each instance the same? Looks like it is > from the driver. So normally that's 3 instances of the same compatible. > > > Any driver for the TH1520 SoC (not just Linux) would need some way to discern > > between the 3 pin controllers so they know how many pins to control and what > > pinmux settings are valid. Basically they'd need the data in the three > > th1520_group{1,2,3}_pins arrays in the driver and a way to know which of them > > to use. > > > > https://lore.kernel.org/linux-riscv/20240103132852.298964-3-emil.renner.berthing@xxxxxxxxxxxxx/ > > Why do you need to know how many pins? The DT says configure a pin and > you just configure it. It's not the kernel's job to validate that the DT > is correct. > > Aren't the pin names globally unique? So you just look up the pin name > across all the arrays. Or you can just look up one pin from each > instance to find which th1520_groupN_pins array goes with the instance. > Or just have 1 array. Just to be clear, do you mean to add just one node for all 3 instances like this? padctrl: pinctrl@ffe7f3c000 { compatible = "thead,th1520-pinctrl"; reg = <0xff 0xe7f3c000 0x0 0x1000>, <0xff 0xec007000 0x0 0x1000>, <0xff 0xfff4a000 0x0 0x2000>; reg-names = "group2", "group3", "group1"; clocks = <&apb_clk>, <&apb_clk>, <&aonsys_clk>; clock-names = "group2", "group3", "group1"; }; That will work since we can then register all pins at the same time. But I can't see how it will work when keeping the 3 different nodes since each instance needs to register the pins they control at probe time. So there will need to be some way to tell the 3 different nodes apart. /Emil
