All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Clément Péron" <peron.clem@gmail.com>
To: Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>
Cc: "open list:ALLWINNER CPUFREQ DRIVER" <linux-pm@vger.kernel.org>,
	Steven Price <steven.price@arm.com>,
	Mark Brown <broonie@kernel.org>
Subject: Question about OPP regulator for Panfrost Devfreq
Date: Sat, 9 May 2020 21:56:42 +0200	[thread overview]
Message-ID: <CAJiuCce9ZxeXnQzEW_3dbBDNZmmtWmKeft0hX+F9+SYu80NU=Q@mail.gmail.com> (raw)

Dear OPP Maintainers,

I'm working on adding DVFS support using the generic OPP framework to Panfrost.
I'm using the dev_pm_opp_set_regulators() to let OPP framework get and
manage the regulator.
https://github.com/clementperon/linux/commit/be310c37b82010e293b7f129ccdcb711a2abb2ce

However it seems that this function only get the regulator but never enable it.
This result that the regulator is disabled later by the
regulator_late_cleanup().

In a previous version I let the Panfrost driver to get and enable the
regulator in addition to OPP but this create a conflict in debugFS
because the regulator is "get" two times.

Quick discussion with Mark Brown point that we should try to avoid
getting two times a regulator as it can create "confusion in your code
with two different parts of the device controlling the same supply
independently."

Is my understanding correct? If yes,
Should we not add a call to regulator_enable() in the
dev_pm_opp_set_regulators() ?

My WIP branch :
https://github.com/clementperon/linux/commits/panfrost_devfreq

Thanks for your help,
Clement

             reply	other threads:[~2020-05-09 19:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09 19:56 Clément Péron [this message]
2020-05-11  5:25 ` Question about OPP regulator for Panfrost Devfreq Viresh Kumar
2020-05-12 20:51   ` Clément Péron
2020-05-13  5:46     ` Viresh Kumar
2020-05-13  8:18       ` Clément Péron
2020-05-13  9:19         ` Viresh Kumar
2020-05-13 10:18           ` Mark Brown
2020-05-13 10:40             ` Viresh Kumar
2020-05-13 11:00               ` Mark Brown
2020-05-13 11:03                 ` Viresh Kumar
2020-05-13 11:36                   ` Clément Péron

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='CAJiuCce9ZxeXnQzEW_3dbBDNZmmtWmKeft0hX+F9+SYu80NU=Q@mail.gmail.com' \
    --to=peron.clem@gmail.com \
    --cc=broonie@kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=sboyd@kernel.org \
    --cc=steven.price@arm.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 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.