| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPDyKFr7qTU2RPhA_ZrbCayoTTNUEno1zdmvmv+8HBe-Owrfeg@mail.gmail.com>
Date: Thu, 5 Nov 2020 10:45:23 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Dmitry Osipenko <digetx@...il.com>,
Viresh Kumar <viresh.kumar@...aro.org>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Alan Stern <stern@...land.harvard.edu>,
Peter Chen <Peter.Chen@....com>,
Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Lee Jones <lee.jones@...aro.org>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Peter Geis <pgwipeout@...il.com>,
Nicolas Chauvet <kwizart@...il.com>,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
driverdevel <devel@...verdev.osuosl.org>,
Linux USB List <linux-usb@...r.kernel.org>,
linux-pwm@...r.kernel.org,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA
Tegra20/30 SoCs
+ Viresh
On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko <digetx@...il.com> wrote:
>
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core voltage. The voltage must be selected in accordance to a minimum
> requirement of every core hardware unit.
>
> The minimum core voltage requirement depends on:
>
> 1. Clock enable state of a hardware unit.
> 2. Clock frequency.
> 3. Unit's internal idling/active state.
>
> This series is tested on Acer A500 (T20), AC100 (T20), Nexus 7 (T30) and
> Ouya (T30) devices. I also added voltage scaling to the Ventana (T20) and
> Cardhu (T30) boards which are tested by NVIDIA's CI farm. Tegra30 is now up
> to 5C cooler on Nexus 7 and stays cool on Ouya (instead of becoming burning
> hot) while system is idling. It should be possible to improve this further
> by implementing a more advanced power management features for the kernel
> drivers.
>
> The DVFS support is opt-in for all boards, meaning that older DTBs will
> continue to work like they did it before this series. It should be possible
> to easily add the core voltage scaling support for Tegra114+ SoCs based on
> this grounding work later on, if anyone will want to implement it.
>
> WARNING(!) This series is made on top of the memory interconnect patches
> which are currently under review [1]. The Tegra EMC driver
> and devicetree-related patches need to be applied on top of
> the ICC series.
>
> [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=212196
>
> Dmitry Osipenko (30):
> dt-bindings: host1x: Document OPP and voltage regulator properties
> dt-bindings: mmc: tegra: Document OPP and voltage regulator properties
> dt-bindings: pwm: tegra: Document OPP and voltage regulator properties
> media: dt: bindings: tegra-vde: Document OPP and voltage regulator
> properties
> dt-binding: usb: ci-hdrc-usb2: Document OPP and voltage regulator
> properties
> dt-bindings: usb: tegra-ehci: Document OPP and voltage regulator
> properties
> soc/tegra: Add sync state API
> soc/tegra: regulators: Support Tegra SoC device sync state API
> soc/tegra: regulators: Fix lockup when voltage-spread is out of range
> regulator: Allow skipping disabled regulators in
> regulator_check_consumers()
> drm/tegra: dc: Support OPP and SoC core voltage scaling
> drm/tegra: gr2d: Correct swapped device-tree compatibles
> drm/tegra: gr2d: Support OPP and SoC core voltage scaling
> drm/tegra: gr3d: Support OPP and SoC core voltage scaling
> drm/tegra: hdmi: Support OPP and SoC core voltage scaling
> gpu: host1x: Support OPP and SoC core voltage scaling
> mmc: sdhci-tegra: Support OPP and core voltage scaling
> pwm: tegra: Support OPP and core voltage scaling
> media: staging: tegra-vde: Support OPP and SoC core voltage scaling
> usb: chipidea: tegra: Support OPP and SoC core voltage scaling
> usb: host: ehci-tegra: Support OPP and SoC core voltage scaling
> memory: tegra20-emc: Support Tegra SoC device state syncing
> memory: tegra30-emc: Support Tegra SoC device state syncing
> ARM: tegra: Add OPP tables for Tegra20 peripheral devices
> ARM: tegra: Add OPP tables for Tegra30 peripheral devices
> ARM: tegra: ventana: Add voltage supplies to DVFS-capable devices
> ARM: tegra: paz00: Add voltage supplies to DVFS-capable devices
> ARM: tegra: acer-a500: Add voltage supplies to DVFS-capable devices
> ARM: tegra: cardhu-a04: Add voltage supplies to DVFS-capable devices
> ARM: tegra: nexus7: Add voltage supplies to DVFS-capable devices
>
> .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++
> .../bindings/media/nvidia,tegra-vde.txt | 12 +
> .../bindings/mmc/nvidia,tegra20-sdhci.txt | 12 +
> .../bindings/pwm/nvidia,tegra20-pwm.txt | 13 +
> .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 4 +
> .../bindings/usb/nvidia,tegra20-ehci.txt | 2 +
> .../boot/dts/tegra20-acer-a500-picasso.dts | 30 +-
> arch/arm/boot/dts/tegra20-paz00.dts | 40 +-
> .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 386 ++++++++++++++++
> arch/arm/boot/dts/tegra20-ventana.dts | 65 ++-
> arch/arm/boot/dts/tegra20.dtsi | 14 +
> .../tegra30-asus-nexus7-grouper-common.dtsi | 23 +
> arch/arm/boot/dts/tegra30-cardhu-a04.dts | 44 ++
> .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 415 ++++++++++++++++++
> arch/arm/boot/dts/tegra30.dtsi | 13 +
> drivers/gpu/drm/tegra/Kconfig | 1 +
> drivers/gpu/drm/tegra/dc.c | 138 +++++-
> drivers/gpu/drm/tegra/dc.h | 5 +
> drivers/gpu/drm/tegra/gr2d.c | 140 +++++-
> drivers/gpu/drm/tegra/gr3d.c | 136 ++++++
> drivers/gpu/drm/tegra/hdmi.c | 63 ++-
> drivers/gpu/host1x/Kconfig | 1 +
> drivers/gpu/host1x/dev.c | 87 ++++
> drivers/memory/tegra/tegra20-emc.c | 8 +-
> drivers/memory/tegra/tegra30-emc.c | 8 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-tegra.c | 70 ++-
> drivers/pwm/Kconfig | 1 +
> drivers/pwm/pwm-tegra.c | 84 +++-
> drivers/regulator/core.c | 12 +-
> .../soc/samsung/exynos-regulator-coupler.c | 2 +-
> drivers/soc/tegra/common.c | 152 ++++++-
> drivers/soc/tegra/regulators-tegra20.c | 25 +-
> drivers/soc/tegra/regulators-tegra30.c | 30 +-
> drivers/staging/media/tegra-vde/Kconfig | 1 +
> drivers/staging/media/tegra-vde/vde.c | 127 ++++++
> drivers/staging/media/tegra-vde/vde.h | 1 +
> drivers/usb/chipidea/Kconfig | 1 +
> drivers/usb/chipidea/ci_hdrc_tegra.c | 79 ++++
> drivers/usb/host/Kconfig | 1 +
> drivers/usb/host/ehci-tegra.c | 79 ++++
> include/linux/regulator/coupler.h | 6 +-
> include/soc/tegra/common.h | 22 +
> 43 files changed, 2360 insertions(+), 50 deletions(-)
>
> --
> 2.27.0
>
I need some more time to review this, but just a quick check found a
few potential issues...
The "core-supply", that you specify as a regulator for each
controller's device node, is not the way we describe power domains.
Instead, it seems like you should register a power-domain provider
(with the help of genpd) and implement the ->set_performance_state()
callback for it. Each device node should then be hooked up to this
power-domain, rather than to a "core-supply". For DT bindings, please
have a look at Documentation/devicetree/bindings/power/power-domain.yaml
and Documentation/devicetree/bindings/power/power_domain.txt.
In regards to the "sync state" problem (preventing to change
performance states until all consumers have been attached), this can
then be managed by the genpd provider driver instead.
Kind regards
Uffe
Powered by blists - more mailing lists