From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Dmitry Osipenko" <digetx@gmail.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Peter Chen" <Peter.Chen@nxp.com>,
"Mark Brown" <broonie@kernel.org>,
"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>,
"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 <linux-samsung-soc@vger.kernel.org>,
driverdevel <devel@driverdev.osuosl.org>,
"Linux USB List" <linux-usb@vger.kernel.org>,
linux-pwm@vger.kernel.org,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
DTML <devicetree@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
Date: Thu, 5 Nov 2020 16:43:01 +0530 [thread overview]
Message-ID: <20201105111301.2hxfx2tnmf2saakp@vireshk-i7> (raw)
In-Reply-To: <CAPDyKFpQG98d6foc1U6fp3YEBdZ1vLqY9cmWxpUwXoKgDn+ojQ@mail.gmail.com>
On 05-11-20, 11:56, Ulf Hansson wrote:
> On Thu, 5 Nov 2020 at 11:40, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Btw, how do we identify if it is a power domain or a regulator ?
To be honest, I was a bit afraid and embarrassed to ask this question,
and was hoping people to make fun of me in return :)
> Good question. It's not a crystal clear line in between them, I think.
And I was relieved after reading this :)
> A power domain to me, means that some part of a silicon (a group of
> controllers or just a single piece, for example) needs some kind of
> resource (typically a power rail) to be enabled to be functional, to
> start with.
Isn't this what a part of regulator does as well ? i.e.
enabling/disabling of the regulator or power to a group of
controllers.
Over that the regulator does voltage/current scaling as well, which
normally the power domains don't do (though we did that in
performance-state case).
> If there are operating points involved, that's also a
> clear indication to me, that it's not a regular regulator.
Is there any example of that? I hope by OPP you meant both freq and
voltage here. I am not sure if I know of a case where a power domain
handles both of them.
> Maybe we should try to specify this more exactly in some
> documentation, somewhere.
I think yes, it is very much required. And in absence of that I think,
many (or most) of the platforms that also need to scale the voltage
would have modeled their hardware as a regulator and not a PM domain.
What I always thought was:
- Module that can just enable/disable power to a block of SoC is a
power domain.
- Module that can enable/disable as well as scale voltage is a
regulator.
And so I thought that this patchset has done the right thing. This
changed a bit with the qcom stuff where the IP to be configured was in
control of RPM and not Linux and so we couldn't add it as a regulator.
If it was controlled by Linux, it would have been a regulator in
kernel for sure :)
--
viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Peter Chen" <Peter.Chen@nxp.com>,
DTML <devicetree@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Dmitry Osipenko" <digetx@gmail.com>,
"Lee Jones" <lee.jones@linaro.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
driverdevel <devel@driverdev.osuosl.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"Nicolas Chauvet" <kwizart@gmail.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
linux-pwm@vger.kernel.org, "Mark Brown" <broonie@kernel.org>,
linux-tegra <linux-tegra@vger.kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Linux USB List" <linux-usb@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Peter Geis" <pgwipeout@gmail.com>
Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
Date: Thu, 5 Nov 2020 16:43:01 +0530 [thread overview]
Message-ID: <20201105111301.2hxfx2tnmf2saakp@vireshk-i7> (raw)
In-Reply-To: <CAPDyKFpQG98d6foc1U6fp3YEBdZ1vLqY9cmWxpUwXoKgDn+ojQ@mail.gmail.com>
On 05-11-20, 11:56, Ulf Hansson wrote:
> On Thu, 5 Nov 2020 at 11:40, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Btw, how do we identify if it is a power domain or a regulator ?
To be honest, I was a bit afraid and embarrassed to ask this question,
and was hoping people to make fun of me in return :)
> Good question. It's not a crystal clear line in between them, I think.
And I was relieved after reading this :)
> A power domain to me, means that some part of a silicon (a group of
> controllers or just a single piece, for example) needs some kind of
> resource (typically a power rail) to be enabled to be functional, to
> start with.
Isn't this what a part of regulator does as well ? i.e.
enabling/disabling of the regulator or power to a group of
controllers.
Over that the regulator does voltage/current scaling as well, which
normally the power domains don't do (though we did that in
performance-state case).
> If there are operating points involved, that's also a
> clear indication to me, that it's not a regular regulator.
Is there any example of that? I hope by OPP you meant both freq and
voltage here. I am not sure if I know of a case where a power domain
handles both of them.
> Maybe we should try to specify this more exactly in some
> documentation, somewhere.
I think yes, it is very much required. And in absence of that I think,
many (or most) of the platforms that also need to scale the voltage
would have modeled their hardware as a regulator and not a PM domain.
What I always thought was:
- Module that can just enable/disable power to a block of SoC is a
power domain.
- Module that can enable/disable as well as scale voltage is a
regulator.
And so I thought that this patchset has done the right thing. This
changed a bit with the qcom stuff where the IP to be configured was in
control of RPM and not Linux and so we couldn't add it as a regulator.
If it was controlled by Linux, it would have been a regulator in
kernel for sure :)
--
viresh
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Peter Chen" <Peter.Chen@nxp.com>,
DTML <devicetree@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Dmitry Osipenko" <digetx@gmail.com>,
"Lee Jones" <lee.jones@linaro.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
driverdevel <devel@driverdev.osuosl.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"Nicolas Chauvet" <kwizart@gmail.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
linux-pwm@vger.kernel.org, "Mark Brown" <broonie@kernel.org>,
linux-tegra <linux-tegra@vger.kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Linux USB List" <linux-usb@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Peter Geis" <pgwipeout@gmail.com>
Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
Date: Thu, 5 Nov 2020 16:43:01 +0530 [thread overview]
Message-ID: <20201105111301.2hxfx2tnmf2saakp@vireshk-i7> (raw)
In-Reply-To: <CAPDyKFpQG98d6foc1U6fp3YEBdZ1vLqY9cmWxpUwXoKgDn+ojQ@mail.gmail.com>
On 05-11-20, 11:56, Ulf Hansson wrote:
> On Thu, 5 Nov 2020 at 11:40, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Btw, how do we identify if it is a power domain or a regulator ?
To be honest, I was a bit afraid and embarrassed to ask this question,
and was hoping people to make fun of me in return :)
> Good question. It's not a crystal clear line in between them, I think.
And I was relieved after reading this :)
> A power domain to me, means that some part of a silicon (a group of
> controllers or just a single piece, for example) needs some kind of
> resource (typically a power rail) to be enabled to be functional, to
> start with.
Isn't this what a part of regulator does as well ? i.e.
enabling/disabling of the regulator or power to a group of
controllers.
Over that the regulator does voltage/current scaling as well, which
normally the power domains don't do (though we did that in
performance-state case).
> If there are operating points involved, that's also a
> clear indication to me, that it's not a regular regulator.
Is there any example of that? I hope by OPP you meant both freq and
voltage here. I am not sure if I know of a case where a power domain
handles both of them.
> Maybe we should try to specify this more exactly in some
> documentation, somewhere.
I think yes, it is very much required. And in absence of that I think,
many (or most) of the platforms that also need to scale the voltage
would have modeled their hardware as a regulator and not a PM domain.
What I always thought was:
- Module that can just enable/disable power to a block of SoC is a
power domain.
- Module that can enable/disable as well as scale voltage is a
regulator.
And so I thought that this patchset has done the right thing. This
changed a bit with the qcom stuff where the IP to be configured was in
control of RPM and not Linux and so we couldn't add it as a regulator.
If it was controlled by Linux, it would have been a regulator in
kernel for sure :)
--
viresh
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-11-05 11:13 UTC|newest]
Thread overview: 325+ 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 ` Dmitry Osipenko
2020-11-04 23:43 ` Dmitry Osipenko
2020-11-04 23:43 ` [PATCH v1 01/30] dt-bindings: host1x: Document OPP and voltage regulator properties Dmitry Osipenko
2020-11-04 23:43 ` Dmitry Osipenko
2020-11-04 23:43 ` Dmitry Osipenko
2020-11-09 18:57 ` Rob Herring
2020-11-09 18:57 ` Rob Herring
2020-11-09 18:57 ` Rob Herring
2020-11-11 11:45 ` Ulf Hansson
2020-11-11 11:45 ` Ulf Hansson
2020-11-11 11:45 ` Ulf Hansson
2020-11-04 23:43 ` [PATCH v1 02/30] dt-bindings: mmc: tegra: " Dmitry Osipenko
2020-11-04 23:43 ` Dmitry Osipenko
2020-11-04 23:43 ` Dmitry Osipenko
2020-11-09 18:58 ` Rob Herring
2020-11-09 18:58 ` Rob Herring
2020-11-09 18:58 ` Rob Herring
2020-11-04 23:44 ` [PATCH v1 03/30] dt-bindings: pwm: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-09 19:00 ` Rob Herring
2020-11-09 19:00 ` Rob Herring
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-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-09 19:01 ` Rob Herring
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-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-09 19:01 ` Rob Herring
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-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-09 19:01 ` Rob Herring
2020-11-09 19:01 ` Rob Herring
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-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-10 20:47 ` Thierry Reding
2020-11-10 20:47 ` Thierry Reding
2020-11-10 20:47 ` Thierry Reding
2020-11-10 21:22 ` Dmitry Osipenko
2020-11-10 21:22 ` Dmitry Osipenko
2020-11-10 21:22 ` Dmitry Osipenko
2020-11-10 21:32 ` Dmitry Osipenko
2020-11-10 21:32 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-10 20:29 ` Thierry Reding
2020-11-10 20:29 ` Thierry Reding
2020-11-10 20:29 ` Thierry Reding
2020-11-10 20:32 ` Mark Brown
2020-11-10 20:32 ` Mark Brown
2020-11-10 20:32 ` Mark Brown
2020-11-10 21:23 ` Dmitry Osipenko
2020-11-10 21:23 ` Dmitry Osipenko
2020-11-10 21:23 ` Dmitry Osipenko
2020-11-11 11:55 ` Mark Brown
2020-11-11 11:55 ` Mark Brown
2020-11-11 11:55 ` Mark Brown
2020-11-12 16:59 ` Dmitry Osipenko
2020-11-12 16:59 ` Dmitry Osipenko
2020-11-12 16:59 ` Dmitry Osipenko
2020-11-12 17:16 ` Mark Brown
2020-11-12 17:16 ` Mark Brown
2020-11-12 17:16 ` Mark Brown
2020-11-12 19:16 ` Dmitry Osipenko
2020-11-12 19:16 ` Dmitry Osipenko
2020-11-12 19:16 ` Dmitry Osipenko
2020-11-12 20:01 ` Mark Brown
2020-11-12 20:01 ` Mark Brown
2020-11-12 20:01 ` Mark Brown
2020-11-12 22:37 ` Dmitry Osipenko
2020-11-12 22:37 ` Dmitry Osipenko
2020-11-12 22:37 ` Dmitry Osipenko
2020-11-13 14:29 ` Mark Brown
2020-11-13 14:29 ` Mark Brown
2020-11-13 14:29 ` Mark Brown
2020-11-13 15:55 ` Dmitry Osipenko
2020-11-13 15:55 ` Dmitry Osipenko
2020-11-13 15:55 ` Dmitry Osipenko
2020-11-13 16:15 ` Mark Brown
2020-11-13 16:15 ` Mark Brown
2020-11-13 16:15 ` Mark Brown
2020-11-13 17:13 ` Dmitry Osipenko
2020-11-13 17:13 ` Dmitry Osipenko
2020-11-13 17:13 ` Dmitry Osipenko
2020-11-13 17:28 ` Mark Brown
2020-11-13 17:28 ` Mark Brown
2020-11-13 17:28 ` Mark Brown
2020-11-15 17:42 ` Dmitry Osipenko
2020-11-15 17:42 ` Dmitry Osipenko
2020-11-15 17:42 ` Dmitry Osipenko
2020-11-16 13:33 ` Mark Brown
2020-11-16 13:33 ` Mark Brown
2020-11-16 13:33 ` Mark Brown
2020-11-19 14:22 ` Dmitry Osipenko
2020-11-19 14:22 ` Dmitry Osipenko
2020-11-19 14:22 ` Dmitry Osipenko
2020-11-19 15:19 ` Mark Brown
2020-11-19 15:19 ` Mark Brown
2020-11-19 15:19 ` Mark Brown
2020-11-13 17:30 ` Thierry Reding
2020-11-13 17:30 ` Thierry Reding
2020-11-13 17:30 ` Thierry Reding
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-10 21:50 ` Dmitry Osipenko
2020-11-10 21:50 ` Dmitry Osipenko
2020-11-10 21:50 ` Dmitry Osipenko
2020-11-11 9:28 ` Dan Carpenter
2020-11-11 9:28 ` Dan Carpenter
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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 14/30] drm/tegra: gr3d: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 15/30] drm/tegra: hdmi: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 16/30] gpu: host1x: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 17/30] mmc: sdhci-tegra: Support OPP and " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-05 9:58 ` Viresh Kumar
2020-11-05 9:58 ` Viresh Kumar
2020-11-05 9:58 ` Viresh Kumar
2020-11-05 14:18 ` Dmitry Osipenko
2020-11-05 14:18 ` Dmitry Osipenko
2020-11-05 14:18 ` Dmitry Osipenko
2020-11-06 6:15 ` Viresh Kumar
2020-11-06 6:15 ` Viresh Kumar
2020-11-06 6:15 ` Viresh Kumar
2020-11-06 13:17 ` Dmitry Osipenko
2020-11-06 13:17 ` Dmitry Osipenko
2020-11-06 13:41 ` Frank Lee
2020-11-06 13:41 ` Frank Lee
2020-11-09 5:00 ` Viresh Kumar
2020-11-09 5:00 ` Viresh Kumar
2020-11-09 5:00 ` Viresh Kumar
2020-11-09 5:08 ` Dmitry Osipenko
2020-11-09 5:08 ` Dmitry Osipenko
2020-11-09 5:08 ` Dmitry Osipenko
2020-11-09 5:10 ` Viresh Kumar
2020-11-09 5:10 ` Viresh Kumar
2020-11-09 5:10 ` Viresh Kumar
2020-11-09 5:19 ` Dmitry Osipenko
2020-11-09 5:19 ` Dmitry Osipenko
2020-11-09 5:19 ` Dmitry Osipenko
2020-11-09 5:35 ` Viresh Kumar
2020-11-09 5:35 ` Viresh Kumar
2020-11-09 5:35 ` Viresh Kumar
2020-11-09 5:44 ` Dmitry Osipenko
2020-11-09 5:44 ` Dmitry Osipenko
2020-11-09 5:44 ` Dmitry Osipenko
2020-11-09 5:53 ` Viresh Kumar
2020-11-09 5:53 ` Viresh Kumar
2020-11-09 5:53 ` Viresh Kumar
2020-11-09 11:20 ` Frank Lee
2020-11-09 11:20 ` Frank Lee
2020-11-09 11:20 ` Frank Lee
2020-12-22 8:54 ` Viresh Kumar
2020-12-22 8:54 ` Viresh Kumar
2020-12-22 8:54 ` Viresh Kumar
2020-11-04 23:44 ` [PATCH v1 18/30] pwm: tegra: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-10 20:50 ` Thierry Reding
2020-11-10 20:50 ` Thierry Reding
2020-11-10 20:50 ` Thierry Reding
2020-11-10 21:17 ` Dmitry Osipenko
2020-11-10 21:17 ` Dmitry Osipenko
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 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 20/30] usb: chipidea: tegra: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 21/30] usb: host: ehci-tegra: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-05 16:07 ` Alan Stern
2020-11-05 16:07 ` Alan Stern
2020-11-05 16:07 ` Alan Stern
2020-11-05 17:54 ` Dmitry Osipenko
2020-11-05 17:54 ` Dmitry Osipenko
2020-11-05 17:54 ` Dmitry Osipenko
2020-11-05 18:02 ` Dmitry Osipenko
2020-11-05 18:02 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 23/30] memory: tegra30-emc: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 27/30] ARM: tegra: paz00: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 28/30] ARM: tegra: acer-a500: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 29/30] ARM: tegra: cardhu-a04: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` [PATCH v1 30/30] ARM: tegra: nexus7: " Dmitry Osipenko
2020-11-04 23:44 ` Dmitry Osipenko
2020-11-04 23:44 ` 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 1:45 ` Michał Mirosław
2020-11-05 1:45 ` Michał Mirosław
2020-11-05 13:57 ` Dmitry Osipenko
2020-11-05 13:57 ` Dmitry Osipenko
2020-11-05 13:57 ` Dmitry Osipenko
2020-11-05 9:45 ` Ulf Hansson
2020-11-05 9:45 ` Ulf Hansson
2020-11-05 9:45 ` Ulf Hansson
2020-11-05 10:06 ` Viresh Kumar
2020-11-05 10:06 ` Viresh Kumar
2020-11-05 10:06 ` Viresh Kumar
2020-11-05 10:34 ` Ulf Hansson
2020-11-05 10:34 ` Ulf Hansson
2020-11-05 10:34 ` Ulf Hansson
2020-11-05 10:40 ` Viresh Kumar
2020-11-05 10:40 ` Viresh Kumar
2020-11-05 10:40 ` Viresh Kumar
2020-11-05 10:56 ` Ulf Hansson
2020-11-05 10:56 ` Ulf Hansson
2020-11-05 10:56 ` Ulf Hansson
2020-11-05 11:13 ` Viresh Kumar [this message]
2020-11-05 11:13 ` Viresh Kumar
2020-11-05 11:13 ` Viresh Kumar
2020-11-05 12:52 ` Ulf Hansson
2020-11-05 12:52 ` Ulf Hansson
2020-11-05 12:52 ` Ulf Hansson
2020-11-05 15:22 ` Dmitry Osipenko
2020-11-05 15:22 ` Dmitry Osipenko
2020-11-05 15:22 ` Dmitry Osipenko
2020-11-08 12:19 ` Dmitry Osipenko
2020-11-08 12:19 ` Dmitry Osipenko
2020-11-08 12:19 ` Dmitry Osipenko
2020-11-09 4:43 ` Viresh Kumar
2020-11-09 4:43 ` Viresh Kumar
2020-11-09 4:43 ` Viresh Kumar
2020-11-09 4:47 ` Dmitry Osipenko
2020-11-09 4:47 ` Dmitry Osipenko
2020-11-09 4:47 ` Dmitry Osipenko
2020-11-09 5:10 ` Dmitry Osipenko
2020-11-09 5:10 ` Dmitry Osipenko
2020-11-09 5:10 ` Dmitry Osipenko
2020-11-09 5:12 ` Viresh Kumar
2020-11-09 5:12 ` Viresh Kumar
2020-11-09 5:12 ` Viresh Kumar
2020-11-11 11:38 ` Ulf Hansson
2020-11-11 11:38 ` Ulf Hansson
2020-11-11 11:38 ` Ulf Hansson
2020-11-12 19:57 ` Dmitry Osipenko
2020-11-12 19:57 ` Dmitry Osipenko
2020-11-12 19:57 ` Dmitry Osipenko
2020-11-12 20:43 ` Thierry Reding
2020-11-12 20:43 ` Thierry Reding
2020-11-12 20:43 ` Thierry Reding
2020-11-12 22:14 ` Dmitry Osipenko
2020-11-12 22:14 ` Dmitry Osipenko
2020-11-12 22:14 ` Dmitry Osipenko
2020-11-13 14:45 ` Ulf Hansson
2020-11-13 14:45 ` Ulf Hansson
2020-11-13 14:45 ` Ulf Hansson
2020-11-13 16:00 ` Dmitry Osipenko
2020-11-13 16:00 ` Dmitry Osipenko
2020-11-13 16:00 ` Dmitry Osipenko
2020-11-13 16:35 ` Thierry Reding
2020-11-13 16:35 ` Thierry Reding
2020-11-13 16:35 ` Thierry Reding
2020-11-15 16:29 ` Dmitry Osipenko
2020-11-15 16:29 ` Dmitry Osipenko
2020-11-15 16:29 ` Dmitry Osipenko
2020-12-01 13:57 ` Mark Brown
2020-12-01 13:57 ` Mark Brown
2020-12-01 13:57 ` Mark Brown
2020-12-01 14:17 ` Dmitry Osipenko
2020-12-01 14:17 ` Dmitry Osipenko
2020-12-01 14:17 ` Dmitry Osipenko
2020-12-01 14:34 ` Mark Brown
2020-12-01 14:34 ` Mark Brown
2020-12-01 14:34 ` Mark Brown
2020-12-01 14:44 ` Dmitry Osipenko
2020-12-01 14:44 ` Dmitry Osipenko
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=20201105111301.2hxfx2tnmf2saakp@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--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=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 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.