All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
To: Mark Brown <broonie@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: RFC power domain vs generic supply regulator
Date: Thu, 5 Aug 2021 19:39:42 +0200	[thread overview]
Message-ID: <CAOf5uw=BZ98KGskd-C4NyHQozi7kpca4ZCQE9c8wxkg-W0Aewg@mail.gmail.com> (raw)
In-Reply-To: <20210805172300.GR26252@sirena.org.uk>

Hi Mark

On Thu, Aug 5, 2021 at 7:23 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Jun 08, 2021 at 08:01:20AM +0200, Michael Nazzareno Trimarchi wrote:
>
> > I'm trying to understand how to deal with devices that do not provide
> > a supply handle connection using the device tree, or if there is a
> > generic way
> > to connect to a regulator. The pinctrl has a generic binding inside
> > dd.c that allow to mux pinout during probing or it allows to define a
> > power domain,
> > According to the code I read the power domain can be only connected to
> > the SoC power domain but in general a generic power domain can be
> > connected
> > to any source aka a regulator. For example and spi-nor can be powered
> > but a gpio regulator or any kind of supply connection and bunch of
> > devices
> > can just need a supply if they are probed or binded runtime. Can
> > someone give me feedback on this topic?
>
> I'm having a really hard time parsing the issue you're trying to solve
> here.  Power domains and regulators are different things, power domains
> represent blocks with a SoC which have some kind of power control which
> may involve a combination of things, the drivers for the devices within
> those domains generally just do runtime PM and then let the driver core
> figure out what's going on with them.  Regulators are for things with
> physical supplies that can be seen in the schematic for the board, in
> general anything that uses a regulator should explicitly say so in its
> binding - supporting some sort of generic mapping isn't great since it
> means that we don't have any control over which regulator is which and
> that makes it hard to add control of the regulators later.  Power
> domanis may possibly have regulators among the resources they use but
> that would just be a normal device binding for the power domain.  All of
> this is orthogonal to when drivers for devices get loaded, that can
> happen at any point while the system is running and doesn't really
> affect how the relationships are described.

So in short you said that if I have a device that has no definition of
supply in his
documentation, this device needs to support the supply in his binding
and make to sense
to create something like:

generic-supply = <&regulator_device>;

and let dd to pick them up

Michael




-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

  reply	other threads:[~2021-08-05 17:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08  6:01 RFC power domain vs generic supply regulator Michael Nazzareno Trimarchi
2021-08-05 17:23 ` Mark Brown
2021-08-05 17:39   ` Michael Nazzareno Trimarchi [this message]
2021-08-05 17:58     ` Mark Brown

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='CAOf5uw=BZ98KGskd-C4NyHQozi7kpca4ZCQE9c8wxkg-W0Aewg@mail.gmail.com' \
    --to=michael@amarulasolutions.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.