mbox series

[0/3] Make Rockchip IO domains dependency from other devices explicit

Message ID 20230904115816.1237684-1-s.hauer@pengutronix.de (mailing list archive)
Headers show
Series Make Rockchip IO domains dependency from other devices explicit | expand

Message

Sascha Hauer Sept. 4, 2023, 11:58 a.m. UTC
This is a continuation of the patch posted by Quentin Schulz here [1]

This series aims to solve a problem with Rockchip IO domains. On many
Rockchip SoCs the pins are driven by external supplies normally
controlled by regulators of a PMIC. There are multiple voltages allowed
for the regulators; additionally the chosen voltage has to be programmed
into SoC registers. There already is a driver [2] handling setting these
registers. The driver works by registering a notifier on the regulators.
Whenever a regulator is about to change its voltage then the notifier will
program the IO domain registers suitably for the new voltage.

The problem is that there is no dependency between pins and the IO
domain driver which means that it can happen that a pin is used before
the IO domain driver has been probed. In that case the pin can end up
being non functional as neither the regulator has been configured
correctly nor the SoC registers have been adjusted to the regulators
voltage.

One way to ensure correct probing order is to defer probing of devices
in the pinctrl driver until the IO domain driver has been probed. We
can't do this for all devices though, as that would introduce a cyclic
dependency when for example the I2C port needed to access the PMIC for
the regulators is part of a IO domain itself.

This series solves these problems similarly to Quentins patch. With
Quentins patch we would have to add rockchip,io-domain properties for
all pin group nodes we wish to honor the IO domain dependency for. We
could put these properties into the board dts files which would mean
that we either only add the properties to nodes which actually byte us,
or that we would have to add the properties to all possible pin groups
except the ones needed to access the PMIC. We could also put these
properties into the dtsi files, but that would mean a board has to add a
/delete-property/ rockchip,io-domain to the pin groups needed to access
the PMIC to avoid circular dependencies.

The approach chosen here is slightly different. First of all this series
doesn't change the current behaviour without board specific dts changes.
To activate the IO domain dependency handling, a board has to add a
rockchip,io-domains property to the pinctrl node. When this property is
present all pins are assumed to need the IO domain driver. Pin groups
needed to access the PMIC can then be given a rockchip,io-domain-boot-on
property. When this property is given then the IO domain is assumed to
be correctly configured by the boot loader. It should be added to all
pin groups needed to access the PMIC to avoid cyclic dependencies. Patch
3/3 contains a usage example for the Radxa Rock-3a.

Sascha

[1] https://lore.kernel.org/lkml/20220802095252.2486591-1-foss+kernel@0leil.net/
[2] drivers/soc/rockchip/io-domain.c

Sascha Hauer (3):
  pinctrl: rockchip: add support for io-domain dependency
  dt-bindings: pinctrl: rockchip: Add io domain properties
  arm64: dts: rockchip: rock-3a: add io domain properties

 .../bindings/pinctrl/rockchip,pinctrl.yaml    | 13 +++-
 .../boot/dts/rockchip/rk3568-rock-3a.dts      | 11 ++++
 drivers/pinctrl/pinctrl-rockchip.c            | 64 +++++++++++++++++++
 drivers/pinctrl/pinctrl-rockchip.h            |  3 +
 4 files changed, 90 insertions(+), 1 deletion(-)

Comments

Jonas Karlman Sept. 5, 2023, 11:34 a.m. UTC | #1
Hi Sascha,

On 2023-09-04 13:58, Sascha Hauer wrote:
> This is a continuation of the patch posted by Quentin Schulz here [1]
> 
> This series aims to solve a problem with Rockchip IO domains. On many
> Rockchip SoCs the pins are driven by external supplies normally
> controlled by regulators of a PMIC. There are multiple voltages allowed
> for the regulators; additionally the chosen voltage has to be programmed
> into SoC registers. There already is a driver [2] handling setting these
> registers. The driver works by registering a notifier on the regulators.
> Whenever a regulator is about to change its voltage then the notifier will
> program the IO domain registers suitably for the new voltage.
> 
> The problem is that there is no dependency between pins and the IO
> domain driver which means that it can happen that a pin is used before
> the IO domain driver has been probed. In that case the pin can end up
> being non functional as neither the regulator has been configured
> correctly nor the SoC registers have been adjusted to the regulators
> voltage.
> 
> One way to ensure correct probing order is to defer probing of devices
> in the pinctrl driver until the IO domain driver has been probed. We
> can't do this for all devices though, as that would introduce a cyclic
> dependency when for example the I2C port needed to access the PMIC for
> the regulators is part of a IO domain itself.
> 
> This series solves these problems similarly to Quentins patch. With
> Quentins patch we would have to add rockchip,io-domain properties for
> all pin group nodes we wish to honor the IO domain dependency for. We
> could put these properties into the board dts files which would mean
> that we either only add the properties to nodes which actually byte us,
> or that we would have to add the properties to all possible pin groups
> except the ones needed to access the PMIC. We could also put these
> properties into the dtsi files, but that would mean a board has to add a
> /delete-property/ rockchip,io-domain to the pin groups needed to access
> the PMIC to avoid circular dependencies.
> 
> The approach chosen here is slightly different. First of all this series
> doesn't change the current behaviour without board specific dts changes.
> To activate the IO domain dependency handling, a board has to add a
> rockchip,io-domains property to the pinctrl node. When this property is
> present all pins are assumed to need the IO domain driver. Pin groups
> needed to access the PMIC can then be given a rockchip,io-domain-boot-on
> property. When this property is given then the IO domain is assumed to
> be correctly configured by the boot loader. It should be added to all
> pin groups needed to access the PMIC to avoid cyclic dependencies. Patch
> 3/3 contains a usage example for the Radxa Rock-3a.

FYI, I have sent out a series that ports the IO domain driver to U-Boot.
This was needed to have working Ethernet on RK356x devices that use a
1.8V PHY. Initially only RK356x support have been ported but support for
other SoCs should follow in the future. Vendor U-Boot also initialize
the IO domain configuration based on the voltage reported by the
supplying regulator.

So at least for the example board IO domains should be configured when
entering linux while booting using a future version of mainline U-Boot.

https://lore.kernel.org/u-boot/20230821223020.3918620-1-jonas@kwiboo.se/

Regards,
Jonas

> 
> Sascha
> 
> [1] https://lore.kernel.org/lkml/20220802095252.2486591-1-foss+kernel@0leil.net/
> [2] drivers/soc/rockchip/io-domain.c
> 
> Sascha Hauer (3):
>   pinctrl: rockchip: add support for io-domain dependency
>   dt-bindings: pinctrl: rockchip: Add io domain properties
>   arm64: dts: rockchip: rock-3a: add io domain properties
> 
>  .../bindings/pinctrl/rockchip,pinctrl.yaml    | 13 +++-
>  .../boot/dts/rockchip/rk3568-rock-3a.dts      | 11 ++++
>  drivers/pinctrl/pinctrl-rockchip.c            | 64 +++++++++++++++++++
>  drivers/pinctrl/pinctrl-rockchip.h            |  3 +
>  4 files changed, 90 insertions(+), 1 deletion(-)
>