[QUERY] RZ/V2H pinctrl implementation

[QUERY] RZ/V2H pinctrl implementation

[Lad, Prabhakar]

Hello,

Currently I am implementing a pinctrl driver for the Renesas RZ/V2H
SoC. I will be reusing the RZ/G2L pinctrl driver for this.

On the RZ/V2H SoC there are a couple of settings (like
output-impedance) which vary depending on what power rail it's
connected to.

For example, for the output impedance there are 4 groups of pins.
- Group1:
      Impedance is
          150Ω / 75Ω / 38Ω / 25Ω (at 3.3 V)
          130Ω / 65Ω / 33Ω / 22Ω (at 1.8 V)

- Group 2:
     Impedance is
          50Ω / 40Ω / 33Ω / 25Ω (at 1.8V)

- Group 3:
     Impedance is
         150Ω / 75Ω / 37.5Ω / 25Ω (at 3.3 V)
         130Ω / 65Ω / 33Ω / 22Ω (at 1.8 V)

- Group 4:
      Impedance is
          110Ω / 55Ω / 30Ω / 20Ω (at 1.8 V)
          150Ω / 75Ω / 38Ω / 25Ω (at 1.2 V)

The power rails connected to these pin groups will be connected to PMIC.

Below are the options have been explored,

Option#1
- Passing the power rail information from the PMIC to PFC (pinctrl
driver) so that pinctrl driver can read the voltage level and set the
values accordingly. Here we will be using the
PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS to get/set values
Pros:
  • Debugfs can show the value in ohms
Cons:
  • Race condition at boot between pfc, i2c, and pmic
  • Late time of probing
  • Impossible to validate dt-bindings correctly
  • Manual doesn't say that pfc has access to the power rails, this
could be a challenge
With option #1 I am currently using fixed regulators but I see an
issue when we add a PMIC driver with regulators for example if i2c
pinmux (to which pmic is connected) that itself requires
output-impedance setting.

Option#2
- Specify the voltage in the pinmux/pins child node alongside the
output impedance (using power-source property)
Pros:
  • both driver and bindings can validate the settings
Cons:
  • the figure of the voltage supplied will have been replicated, as
it would be listed in the corresponding power regulator, but also in
the definition of the pin

Option#3
- Have an IP specific compatible ("renesas,v2h-output-impedance") with
value 1, 2, 4 or 6 (which indicates x1, x2, x4, x6 strength)
Pros:
  • Very simple to support and validate.
  • The user cannot really get this wrong
Cons:
  • new proprietary property
  • we would not be using the output impedance property offered by the subsystem

Please share your thoughts what could be the best approach to add
pinctrl support for RZ/V2H

Cheers,
Prabhakar

Re: [QUERY] RZ/V2H pinctrl implementation

[Linus Walleij]

Hi Prabhakar,

mostly these are questions to Geert because he will have the main
interest in keeping the drivers coherent, but I'll pitch in!

On Mon, Mar 18, 2024 at 1:00 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:

> Option#1
> - Passing the power rail information from the PMIC to PFC (pinctrl
> driver) so that pinctrl driver can read the voltage level and set the
> values accordingly. Here we will be using the
> PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS to get/set values
> Pros:
>   • Debugfs can show the value in ohms
> Cons:
>   • Race condition at boot between pfc, i2c, and pmic

This is something drivers simply have to deal with using e.g. deferred
probe. Also, there has been extensive rework to make DT systems
resolve dependencies before probing so that providers are always
probed before consumers, have you looked into this?
There is also the component binding used by some drivers.

>   • Late time of probing

How is this a problem? Everything has to probe eventually.

>   • Impossible to validate dt-bindings correctly

Probably not impossible in theory if it parses and cross-examine stuff
but in practice maybe yes :) Ask the DT maintainers, they are
after all all about describing HW and if there is some HW they can't
describe they would be interested.

NB: describing the HW in the bindings have *nothing* to do with
the Linux implementation of the bindings so it is a separate
issue altogether.

>   • Manual doesn't say that pfc has access to the power rails, this
> could be a challenge

Hm I don't get it.

> Option#2
> - Specify the voltage in the pinmux/pins child node alongside the
> output impedance (using power-source property)
> Pros:
>   • both driver and bindings can validate the settings

You should fix the bindings question first and then think about
the driver.

> Option#3
> - Have an IP specific compatible ("renesas,v2h-output-impedance") with
> value 1, 2, 4 or 6 (which indicates x1, x2, x4, x6 strength)

If you can get it by the DT bindings maintainers I guess it is an option.

Yours,
Linus Walleij

Re: [QUERY] RZ/V2H pinctrl implementation

[Lad, Prabhakar]

CC, DT maintainers.

Hi Linus,

Thank you for the response.

On Thu, Mar 28, 2024 at 3:30 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi Prabhakar,
>
> mostly these are questions to Geert because he will have the main
> interest in keeping the drivers coherent, but I'll pitch in!
>
thank you.

> On Mon, Mar 18, 2024 at 1:00 PM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
>
> > Option#1
> > - Passing the power rail information from the PMIC to PFC (pinctrl
> > driver) so that pinctrl driver can read the voltage level and set the
> > values accordingly. Here we will be using the
> > PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS to get/set values
> > Pros:
> >   • Debugfs can show the value in ohms
> > Cons:
> >   • Race condition at boot between pfc, i2c, and pmic
>
> This is something drivers simply have to deal with using e.g. deferred
> probe. Also, there has been extensive rework to make DT systems
> resolve dependencies before probing so that providers are always
> probed before consumers, have you looked into this?
> There is also the component binding used by some drivers.
>
Basically it's a cyclic dependency instead of hard dependency. For
example consider this case, the power rails are coming from a PMIC
device which is connected via I2C  to the SoC. For I2C to probe we
need the pinmux so this will be deferred until the PFC driver is
ready, the PFC driver won't probe until it has power rail information
from the PMIC.

> >   • Late time of probing
>
> How is this a problem? Everything has to probe eventually.
>
Agreed not a problem.

> >   • Impossible to validate dt-bindings correctly
>
> Probably not impossible in theory if it parses and cross-examine stuff
> but in practice maybe yes :) Ask the DT maintainers, they are
> after all all about describing HW and if there is some HW they can't
> describe they would be interested.
>
> NB: describing the HW in the bindings have *nothing* to do with
> the Linux implementation of the bindings so it is a separate
> issue altogether.
>
Agreed.

> >   • Manual doesn't say that pfc has access to the power rails, this
> > could be a challenge
>
> Hm I don't get it.
>
Basically what I meant was, as per DT we describe the HW blocks since
the power rails are connected to the SoC and not going specifically to
the PFC block passing the regulators to PFC isn't technically correct
(I may be wrong here).

> > Option#2
> > - Specify the voltage in the pinmux/pins child node alongside the
> > output impedance (using power-source property)
> > Pros:
> >   • both driver and bindings can validate the settings
>
> You should fix the bindings question first and then think about
> the driver.
>
OK.

> > Option#3
> > - Have an IP specific compatible ("renesas,v2h-output-impedance") with
> > value 1, 2, 4 or 6 (which indicates x1, x2, x4, x6 strength)
>
> If you can get it by the DT bindings maintainers I guess it is an option.
>
While I was waiting for feedback on this I already posted a RFC series [0].

[0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240326222844.1422948-3-prabhakar.mahadev-lad.rj@bp.renesas.com/

Cheers,
Prabhakar