Re: [QUERY] RZ/V2H pinctrl implementation

["Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx>]

CC, DT maintainers.

Hi Linus,

Thank you for the response.

On Thu, Mar 28, 2024 at 3:30 PM Linus Walleij <linus.walleij@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxx/

Cheers,
Prabhakar