On Wed, Sep 13, 2023 at 12:37:54PM +0800, Chen-Yu Tsai wrote:
> On Tue, Sep 12, 2023 at 4:07 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> >
> > Top posting to bring Saravana Kannan into this discussion.
> >
> > This looks like a big hack to me, Saravana has been working
> > tirelessly to make the device tree probe order "sort itself out"
> > and I am pretty sure this issue needs to be fixed at the DT
> > core level and not in a driver.
>
> We could merge all the IO domain stuff into the pinctrl node/driver,
> like is done for Allwinner? Maybe that would simplify things a bit?
I thought about this as well. On Rockchip the pinctrl driver and the IO
domain driver even work on the same register space, so putting these
into a single node/driver would even feel more natural than what we have
now.
However, with that the pinctrl node would get the supplies that the IO
domain node now has and we would never get into the probe of the pinctrl
driver due to the circular dependencies.
>
> IIRC on Allwinner SoCs the PMIC pins don't have a separate power rail,
> or if they do they almost certainly use the default I/O rail that is
> always on, and so we omit it to work around the dependency cycle.
I looked into sun50i as an example. This one has two pinctrl nodes, pio
and r_pio. Only the former has supplies whereas the latter, where the
PMIC is connected to, has (found in sun50i-a64-pinephone.dtsi):
&r_pio {
/*
* FIXME: We can't add that supply for now since it would
* create a circular dependency between pinctrl, the regulator
* and the RSB Bus.
*
* vcc-pl-supply = <®_aldo2>;
*/
};
At least it show me that I am not the first one who has this problem ;)
We could add the supplies to the pingroup subnodes of the pinctrl driver
to avoid that, but as Saravana already menioned, that would feel like
overkill.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
