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@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.
> • 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
