linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Quentin Schulz <foss+kernel@0leil.net>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>
Subject: Re: [RFC PATCH 0/1] Making Rockchip IO domains dependency from other devices explicit
Date: Tue, 23 Aug 2022 01:43:46 +0200	[thread overview]
Message-ID: <2696616.PYKUYFuaPT@diego> (raw)
In-Reply-To: <CACRpkdZXTtar73-HP8_wcAsCYw7JOgPwkXZt-_3s0GdoggBABw@mail.gmail.com>

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 <foss+kernel@0leil.net> 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
> 





      reply	other threads:[~2022-08-22 23:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  9:52 [RFC PATCH 0/1] Making Rockchip IO domains dependency from other devices explicit Quentin Schulz
2022-08-02  9:52 ` [RFC PATCH 1/1] pinctrl: rockchip: add support for per-pinmux io-domain dependency Quentin Schulz
2022-08-11  7:52   ` Michael Riesch
2022-08-11  8:45     ` Quentin Schulz
2022-08-11  9:26       ` Heiko Stübner
2022-08-11 10:21         ` Quentin Schulz
2023-02-15 10:23   ` Sascha Hauer
2023-02-21 12:14     ` Quentin Schulz
2023-02-22 12:05       ` Sascha Hauer
2022-08-22  8:38 ` [RFC PATCH 0/1] Making Rockchip IO domains dependency from other devices explicit Linus Walleij
2022-08-22 23:43   ` Heiko Stübner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2696616.PYKUYFuaPT@diego \
    --to=heiko@sntech.de \
    --cc=foss+kernel@0leil.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=rafael@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).