From: Mark Brown <broonie@kernel.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Peter Chen" <Peter.Chen@nxp.com>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Lee Jones" <lee.jones@linaro.org>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Peter Geis" <pgwipeout@gmail.com>,
"Nicolas Chauvet" <kwizart@gmail.com>,
linux-samsung-soc@vger.kernel.org, devel@driverdev.osuosl.org,
linux-usb@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling
Date: Fri, 13 Nov 2020 14:29:37 +0000 [thread overview]
Message-ID: <20201113142937.GB4828@sirena.org.uk> (raw)
In-Reply-To: <ce9e2d9f-917e-fb8a-7323-f3bf1a367e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?
> > Of course not, we can't know if the requested new voltage is valid - the
> > driver would have to have explict support for handling situations where
> > it's not possible to change the voltage (which it can detect through
> > enumerating the values it wants to set at startup).
> > [Requesting the same supply multiple times]
> But how driver is supposed to recognize that it's a dummy or buggy
> regulator if it rejects all voltages?
It's not clear if it matters - it's more a policy decision on the part
of the driver about what it thinks safe error handling is. If it's not
possible to read voltages from the regulator the consumer driver has to
decide what it thinks it's safe for it to do, either way it has no idea
what the actual current voltage is. It could assume that it's something
that supports all the use cases it wants to use and just carry on with
no configuration of voltages, it could decide that it might not support
everything and not make any changes to be safe, or do something like
try to figure out that if we're currently at a given OPP that's the top
OPP possible. Historically when we've not had regulator control in
these drivers so they have effectively gone with the first option of
just assuming it's a generally safe value, this often aligns with what
the power on requirements for SoCs are so it's not unreasonable.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-11-13 14:29 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 23:43 [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs Dmitry Osipenko
2020-11-04 23:43 ` [PATCH v1 01/30] dt-bindings: host1x: Document OPP and voltage regulator properties Dmitry Osipenko
2020-11-09 18:57 ` Rob Herring
2020-11-11 11:45 ` Ulf Hansson
2020-11-04 23:43 ` [PATCH v1 02/30] dt-bindings: mmc: tegra: " Dmitry Osipenko
2020-11-09 18:58 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 03/30] dt-bindings: pwm: " Dmitry Osipenko
2020-11-09 19:00 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 04/30] media: dt: bindings: tegra-vde: " Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 05/30] dt-binding: usb: ci-hdrc-usb2: " Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 06/30] dt-bindings: usb: tegra-ehci: " Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 07/30] soc/tegra: Add sync state API Dmitry Osipenko
2020-11-10 20:47 ` Thierry Reding
2020-11-10 21:22 ` Dmitry Osipenko
2020-11-10 21:32 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 08/30] soc/tegra: regulators: Support Tegra SoC device " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 09/30] soc/tegra: regulators: Fix lockup when voltage-spread is out of range Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 10/30] regulator: Allow skipping disabled regulators in regulator_check_consumers() Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling Dmitry Osipenko
2020-11-10 20:29 ` Thierry Reding
2020-11-10 20:32 ` Mark Brown
2020-11-10 21:23 ` Dmitry Osipenko
2020-11-11 11:55 ` Mark Brown
2020-11-12 16:59 ` Dmitry Osipenko
2020-11-12 17:16 ` Mark Brown
2020-11-12 19:16 ` Dmitry Osipenko
2020-11-12 20:01 ` Mark Brown
2020-11-12 22:37 ` Dmitry Osipenko
2020-11-13 14:29 ` Mark Brown [this message]
2020-11-13 15:55 ` Dmitry Osipenko
2020-11-13 16:15 ` Mark Brown
2020-11-13 17:13 ` Dmitry Osipenko
2020-11-13 17:28 ` Mark Brown
2020-11-15 17:42 ` Dmitry Osipenko
2020-11-16 13:33 ` Mark Brown
2020-11-19 14:22 ` Dmitry Osipenko
2020-11-19 15:19 ` Mark Brown
2020-11-13 17:30 ` Thierry Reding
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-10 21:50 ` Dmitry Osipenko
2020-11-11 9:28 ` Dan Carpenter
2020-11-04 23:44 ` [PATCH v1 12/30] drm/tegra: gr2d: Correct swapped device-tree compatibles Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 13/30] drm/tegra: gr2d: Support OPP and SoC core voltage scaling Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 14/30] drm/tegra: gr3d: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 15/30] drm/tegra: hdmi: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 16/30] gpu: host1x: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and " Dmitry Osipenko
2020-11-05 9:58 ` Viresh Kumar
2020-11-05 14:18 ` Dmitry Osipenko
2020-11-06 6:15 ` Viresh Kumar
2020-11-06 13:17 ` Dmitry Osipenko
2020-11-06 13:41 ` Frank Lee
2020-11-09 5:00 ` Viresh Kumar
2020-11-09 5:08 ` Dmitry Osipenko
2020-11-09 5:10 ` Viresh Kumar
2020-11-09 5:19 ` Dmitry Osipenko
2020-11-09 5:35 ` Viresh Kumar
2020-11-09 5:44 ` Dmitry Osipenko
2020-11-09 5:53 ` Viresh Kumar
2020-11-09 11:20 ` Frank Lee
2020-12-22 8:54 ` Viresh Kumar
2020-11-04 23:44 ` [PATCH v1 18/30] pwm: tegra: " Dmitry Osipenko
2020-11-10 20:50 ` Thierry Reding
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 19/30] media: staging: tegra-vde: Support OPP and SoC " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 20/30] usb: chipidea: tegra: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 21/30] usb: host: ehci-tegra: " Dmitry Osipenko
2020-11-05 16:07 ` Alan Stern
2020-11-05 17:54 ` Dmitry Osipenko
2020-11-05 18:02 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 22/30] memory: tegra20-emc: Support Tegra SoC device state syncing Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 23/30] memory: tegra30-emc: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 24/30] ARM: tegra: Add OPP tables for Tegra20 peripheral devices Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 25/30] ARM: tegra: Add OPP tables for Tegra30 " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 26/30] ARM: tegra: ventana: Add voltage supplies to DVFS-capable devices Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 27/30] ARM: tegra: paz00: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 28/30] ARM: tegra: acer-a500: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 29/30] ARM: tegra: cardhu-a04: " Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 30/30] ARM: tegra: nexus7: " Dmitry Osipenko
2020-11-05 1:45 ` [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs Michał Mirosław
2020-11-05 13:57 ` Dmitry Osipenko
2020-11-05 9:45 ` Ulf Hansson
2020-11-05 10:06 ` Viresh Kumar
2020-11-05 10:34 ` Ulf Hansson
2020-11-05 10:40 ` Viresh Kumar
2020-11-05 10:56 ` Ulf Hansson
2020-11-05 11:13 ` Viresh Kumar
2020-11-05 12:52 ` Ulf Hansson
2020-11-05 15:22 ` Dmitry Osipenko
2020-11-08 12:19 ` Dmitry Osipenko
2020-11-09 4:43 ` Viresh Kumar
2020-11-09 4:47 ` Dmitry Osipenko
2020-11-09 5:10 ` Dmitry Osipenko
2020-11-09 5:12 ` Viresh Kumar
2020-11-11 11:38 ` Ulf Hansson
2020-11-12 19:57 ` Dmitry Osipenko
2020-11-12 20:43 ` Thierry Reding
2020-11-12 22:14 ` Dmitry Osipenko
2020-11-13 14:45 ` Ulf Hansson
2020-11-13 16:00 ` Dmitry Osipenko
2020-11-13 16:35 ` Thierry Reding
2020-11-15 16:29 ` Dmitry Osipenko
[not found] ` <160683107675.35139.13466076210885462180.b4-ty@kernel.org>
2020-12-01 14:17 ` Dmitry Osipenko
2020-12-01 14:34 ` Mark Brown
2020-12-01 14:44 ` Dmitry Osipenko
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=20201113142937.GB4828@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Peter.Chen@nxp.com \
--cc=adrian.hunter@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=krzk@kernel.org \
--cc=kwizart@gmail.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=pgwipeout@gmail.com \
--cc=robh+dt@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--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).