devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Mark Brown <broonie@kernel.org>
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: Thu, 19 Nov 2020 17:22:43 +0300	[thread overview]
Message-ID: <332ab946-daee-bb83-24ab-0bda4fd8e1ef@gmail.com> (raw)
In-Reply-To: <20201116133311.GB4739@sirena.org.uk>

16.11.2020 16:33, Mark Brown пишет:
> On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 20:28, Mark Brown пишет:
> 
>>>> What should we do?
> 
>>> As I keep saying the consumer driver should be enumerating the voltages
>>> it can set, if it can't find any and wants to continue then it can just
>>> skip setting voltages later on.  If only some are unavailable then it
>>> probably wants to eliminate those specific OPPs instead.
> 
>> I'm seeing a dummy regulator as a helper for consumer drivers which
>> removes burden of handling an absent (optional) regulator. Is this a
>> correct understanding of a dummy regulator?
> 
>> Older DTBs don't have a regulator and we want to keep them working. This
>> is equal to a physically absent regulator and in this case it's an
>> optional regulator, IMO.
> 
> No, you are failing to understand the purpose of this code.  To
> reiterate unless the device supports operating with the supply
> physically absent then the driver should not be attempting to use
> regulator_get_optional().  That exists specifically for the case where
> the supply may be absent, nothing else.  The dummy regulator is there
> precisely for the case where the system does not describe supplies that
> we know are required for the device to function, it fixes up that
> omission so we don't need to open code handling of this in every single
> consumer driver.

The original intention of regulator_get_optional() is clear to me, but
nothing really stops drivers from slightly re-purposing this API, IMO.

Drivers should be free to assume that if regulator isn't defined by
firmware, then it's physically absent if this doesn't break anything. Of
course in some cases it's unsafe to make such assumptions. I think it's
a bit unpractical to artificially limit API usage without a good reason,
i.e. if nothing breaks underneath of a driver.

> Regulators that are present but not described by the firmware are a
> clearly different case to regulators that are not physically there,
> hardware with actually optional regulators will generally require some
> configuration for this case.
> 

I have good news. After spending some more time on trying out different
things, I found that my previous assumption about the fixed-regulator
was wrong, it actually accepts voltage changes, i.e. regulator consumer
doesn't get a error on a voltage-change. This is exactly what is needed
for the OPP core to work properly.

This means that there is no need to add special quirks to work around
absent regulators, we will just add a fixed regulator to the DTs which
don't specify a real regulator. The OPP core will perform voltage
checking and filter out unsupported OPPs. The older DTBs will continue
to work as well.

  reply	other threads:[~2020-11-19 14:23 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
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 [this message]
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=332ab946-daee-bb83-24ab-0bda4fd8e1ef@gmail.com \
    --to=digetx@gmail.com \
    --cc=Peter.Chen@nxp.com \
    --cc=adrian.hunter@intel.com \
    --cc=broonie@kernel.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --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).