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. 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/ Another solution would be to just have one compatible value, and then let the driver figure out which of the 3 pin controllers it's probing from the base physical memory address. That would work fine. A third solution would be to encode the data in those three arrays into the device tree, but I thought we didn't want to encode register information in device trees. /Emil
