From: Quentin Schulz <[email protected]>
This is a follow-up to the mail sent almost two months ago asking for
guidance: https://lore.kernel.org/lkml/[email protected]/
This is what I could come up with but I'm not too happy about it so feel
free to give some ideas or other possible implementations that would
have less downsides than this one.
Some background on IO domains on Rockchip:
On some Rockchip SoCs, some SoC pins are split in what are called IO
domains.
An IO domain is supplied power externally, by regulators from a PMIC for
example. This external power supply is then used by the IO domain as
"supply" for the IO pins if they are outputs.
Each IO domain can configure which voltage the IO pins will be operating
on (1.8V or 3.3V).
There already exists an IO domain driver for Rockchip SoCs[1]. This
driver allows to explicit the relationship between the external power
supplies and IO domains[2]. This makes sure the regulators are enabled
by the Linux kernel so the IO domains are supplied with power and
correctly configured as per the supplied voltage.
This driver is a regulator consumer and does not offer any other
interface for device dependency.
However, IO pins belonging to an IO domain need to have this IO domain
correctly configured before they are being used otherwise they do not
operate correctly (in our case, a pin configured as output clock was
oscillating between 0 and 150mV instead of the expected 1V8).
In order to make this dependency transparent to the consumer of those
pins and not add Rockchip-specific code to third party drivers (a camera
driver in our case), it is hooked into the pinctrl driver which is
Rockchip-specific obviously.
Unfortunately, the dependency is not about the ultimate presence of the
io-domain devices but more that prior to being able to use pins,
the io-domain devices need to be probed. However of_find_device_by_node
does not provide this information, hence the check whether the
platform_device actually has its drvdata structure set (it defaults to
NULL until it is filled by the driver during the probe of the device).
Moreover, this dependency needs to be explicit on a pinmux level
and postponed after the probe of the pinctrl driver because a circular
dependency is observed otherwise with the following:
pinctrl device depends on the io-domain device which depends on
regulators from a PMIC on i2c which requires the i2c bus pins to be
muxed from the pinctrl device.
Instead, the pinmux dependency on IO domain is checked in set_mux
callback and returns EPROBE_DEFER if the IO domain device hasn't probed
yet.
I wanted to add the appropriate rockchip,io-domains DT property to
existing pinmux DT node. However, *all* of PX30's belong to an IO
domain, including the i2c bus on which the PMIC supplying the power to
the IO domain is on. Since the PMIC can be virtually on any i2c bus, a
specific pinmux cannot be omitted or ignored, therefore none are added
and it's up to the board maintainers to add them themselves. This is
also assumed only necessary for IO domain that are configured
differently by the bootloader or by register defaults (3V3 for
RK3399/PX30) than their expected values in Linux and whose supplied
power is fixed (e.g. not expected to be able to change from 3V3 to 1V8).
The hope is to not have to handle the io domain configuration in
the bootloader as it is currently done, c.f.
https://elixir.bootlin.com/u-boot/latest/source/board/theobroma-systems/puma_rk3399/puma-rk3399.c#L28
(we'll need an additional IO domain configuration for a camera soon).
However, this still relies on IO domains defaults or bootloader
configuration to be able to omit some IO domain<->pinmux relationships
to avoid circular dependencies.
I don't know how well this RFC implementation would work with
suspend/resume.
[1] drivers/soc/rockchip/io-domain.c
[2] Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
Cheers,
Quentin
Quentin Schulz (1):
pinctrl: rockchip: add support for per-pinmux io-domain dependency
drivers/pinctrl/pinctrl-rockchip.c | 19 +++++++++++++++++++
drivers/pinctrl/pinctrl-rockchip.h | 1 +
2 files changed, 20 insertions(+)
--
2.37.1
On Tue, Aug 2, 2022 at 11:53 AM Quentin Schulz <[email protected]> wrote:
> Some background on IO domains on Rockchip:
>
> On some Rockchip SoCs, some SoC pins are split in what are called IO
> domains.
>
> An IO domain is supplied power externally, by regulators from a PMIC for
> example. This external power supply is then used by the IO domain as
> "supply" for the IO pins if they are outputs.
>
> Each IO domain can configure which voltage the IO pins will be operating
> on (1.8V or 3.3V).
>
> There already exists an IO domain driver for Rockchip SoCs[1]. This
> driver allows to explicit the relationship between the external power
> supplies and IO domains[2]. This makes sure the regulators are enabled
> by the Linux kernel so the IO domains are supplied with power and
> correctly configured as per the supplied voltage.
> This driver is a regulator consumer and does not offer any other
> interface for device dependency.
What makes me confused about the patch is the relationship, if any,
between this "IO domain" and generic power domains (genpd) that has
been worked on for ~10 years.
I am worried that we are reinventing the world.
While my intuitive feeling is that genpd power domains are only on-chip
and not considering off-chip pins, I am not so sure that it warrants
its own abstraction and want to know whether this can be retrofit into
genpd rather than inventing this?
Documentation/devicetree/bindings/power/power-domain.yaml
include/linux/pm_domain.h
Yours,
Linus Walleij
Hi Linus,
Am Montag, 22. August 2022, 10:38:11 CEST schrieb Linus Walleij:
> On Tue, Aug 2, 2022 at 11:53 AM Quentin Schulz <[email protected]> wrote:
>
> > Some background on IO domains on Rockchip:
> >
> > On some Rockchip SoCs, some SoC pins are split in what are called IO
> > domains.
> >
> > An IO domain is supplied power externally, by regulators from a PMIC for
> > example. This external power supply is then used by the IO domain as
> > "supply" for the IO pins if they are outputs.
> >
> > Each IO domain can configure which voltage the IO pins will be operating
> > on (1.8V or 3.3V).
> >
> > There already exists an IO domain driver for Rockchip SoCs[1]. This
> > driver allows to explicit the relationship between the external power
> > supplies and IO domains[2]. This makes sure the regulators are enabled
> > by the Linux kernel so the IO domains are supplied with power and
> > correctly configured as per the supplied voltage.
> > This driver is a regulator consumer and does not offer any other
> > interface for device dependency.
>
> What makes me confused about the patch is the relationship, if any,
> between this "IO domain" and generic power domains (genpd) that has
> been worked on for ~10 years.
>
> I am worried that we are reinventing the world.
In a nutshell, the Rockchip io-domains handle the voltages of specific
pin-groups. I.e. mostly it is just switching between 1.8V and 3.3V .
The voltage itself is always set in a (i2c-)regulator but there is a
separate step necessary to tell the soc this information.
3.3 -> 1.8: set regulator to 1.8, tell io-domain "we're at 1.8 now"
1.8 -> 3.3: tell io-domain "3.3", set regulator to 3.3.
There is supposedly a soc-health-issue if you set the regulator to 3.3
while the io-domain thinks it's at 1.8 .
So the io-domain driver right now, just attaches to the regulator, catches
the voltage-change events and sets the io-domain setting accordingly.
What Quentin is trying to solve is a probe-dependency issue that can
happen when stuff is built into the kernel, the regulator has probed
the regulator using driver has probed, but the io.domain driver hasn't,
as that also only attached to the regulator as described above.
Heiko
> While my intuitive feeling is that genpd power domains are only on-chip
> and not considering off-chip pins, I am not so sure that it warrants
> its own abstraction and want to know whether this can be retrofit into
> genpd rather than inventing this?
>
> Documentation/devicetree/bindings/power/power-domain.yaml
> include/linux/pm_domain.h
>
> Yours,
> Linus Walleij
>