From: Robin Murphy <robin.murphy@arm.com>
To: "Steven Price" <steven.price@arm.com>,
"Clément Péron" <peron.clem@gmail.com>,
"Mark Brown" <broonie@kernel.org>
Cc: Nishanth Menon <nm@ti.com>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Stephen Boyd <sboyd@kernel.org>,
Viresh Kumar <vireshk@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Subject: Re: Multiple regulators for one device [was drm/panfrost: add devfreq regulator support]
Date: Fri, 17 Apr 2020 12:10:18 +0100 [thread overview]
Message-ID: <5290a7a8-2a0a-cb89-9d62-270393123054@arm.com> (raw)
In-Reply-To: <5e15e7ac-1d9c-d614-8fd9-27525c88cafb@arm.com>
On 2020-04-16 2:42 pm, Steven Price wrote:
[...]
> Perhaps a better approach would be for Panfrost to hand over the struct
> regulator objects it has already got to the OPP framework. I.e. open
> code dev_pm_opp_set_regulators(), but instead of calling
> regulator_get_optional() simply populate the regulators we already have?
>
> The other benefit of that is it would provide a clear hand-over of
> responsibility between Panfrost handling it's own regulators and the OPP
> framework picking up the work. The disadvantage is that Panfrost would
> have to track whether the regulators have been handed over or not.
Sounds like the most logical thing to do is to shuffle things around so
we start by trying to set up an OPP table, then fall back to explicitly
claiming clocks and regulators if necessary. Then we can easily make the
devfreq decision later in probe based on how that turned out.
Robin.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-17 11:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 20:06 [PATCH 1/2] drm/panfrost: missing remove opp table in case of failure Clément Péron
2020-04-11 20:06 ` [PATCH 2/2] drm/panfrost: add devfreq regulator support Clément Péron
2020-04-13 11:33 ` Clément Péron
2020-04-13 13:18 ` Steven Price
2020-04-13 14:18 ` Clément Péron
2020-04-13 14:31 ` Clément Péron
2020-04-13 15:55 ` Steven Price
2020-04-13 16:35 ` Clément Péron
2020-04-13 17:28 ` Clément Péron
2020-04-14 13:10 ` Steven Price
2020-04-14 18:20 ` Clément Péron
2020-04-14 18:55 ` Mark Brown
2020-04-14 19:16 ` Clément Péron
2020-04-16 13:42 ` Multiple regulators for one device [was drm/panfrost: add devfreq regulator support] Steven Price
2020-04-16 14:04 ` Mark Brown
2020-04-17 11:10 ` Robin Murphy [this message]
2020-04-17 12:33 ` Clément Péron
2020-04-19 9:25 ` Clément Péron
2020-04-20 12:32 ` Mark Brown
2020-04-16 13:44 ` [PATCH 2/2] drm/panfrost: add devfreq regulator support Mark Brown
2020-05-02 22:07 ` Clément Péron
2020-05-07 14:30 ` Steven Price
2020-05-09 16:28 ` Clément Péron
2020-05-09 19:40 ` Clément Péron
2020-04-14 13:09 ` Robin Murphy
2020-04-13 13:07 ` [PATCH 1/2] drm/panfrost: missing remove opp table in case of failure Steven Price
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=5290a7a8-2a0a-cb89-9d62-270393123054@arm.com \
--to=robin.murphy@arm.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=broonie@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=peron.clem@gmail.com \
--cc=sboyd@kernel.org \
--cc=steven.price@arm.com \
--cc=tomeu.vizoso@collabora.com \
--cc=vireshk@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 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).