From: Lucas Stach <l.stach@pengutronix.de>
To: Dmitry Osipenko <digetx@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators
Date: Fri, 26 Oct 2018 17:37:35 +0200 [thread overview]
Message-ID: <1540568255.2245.11.camel@pengutronix.de> (raw)
In-Reply-To: <ba782346-6ac0-7bf3-e187-00d2634b145b@gmail.com>
Am Freitag, den 26.10.2018, 15:03 +0300 schrieb Dmitry Osipenko:
[...]
> > On the other hand, the tegra20 cpufreq driver is common across a lot of boards.
> > What will happen if the DT for some of the boards isn't correct and missed the
> > necessary regulator node ?
>
> AFAIK, there is assumption that bootloader should setup regulators in
> a way that kernel could work properly at max clock rates. Otherwise
> things won't work.
This isn't true. The assumption is that the bootloader sets up the
regulators such that stable operation at the CPU speed used by the
bootloader is guaranteed.
Often the bootloader doesn't know about specific SKUs, so drives things
at a rate/voltage that is safe across all SKUs [1], in which case the
bootloader is totally unaware of the voltage needed to run the CPU at
highest possible clock frequency.
Regards,
Lucas
[1] http://git.denx.de/?p=u-boot.git;a=commit;h=2364e151e432b4ccf32dc9e6147121253d4ff86d
next prev parent reply other threads:[~2018-10-26 15:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-21 20:54 [RFC PATCH v2 00/17] CPUFREQ OPP's, DVFS and Tegra30 support by tegra20-cpufreq driver Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators Dmitry Osipenko
2018-10-22 5:36 ` Viresh Kumar
2018-10-22 11:29 ` Dmitry Osipenko
2018-10-22 11:32 ` Viresh Kumar
2018-10-22 12:12 ` Dmitry Osipenko
2018-10-24 6:41 ` Viresh Kumar
2018-10-26 12:03 ` Dmitry Osipenko
2018-10-26 15:37 ` Lucas Stach [this message]
2018-10-28 12:58 ` Dmitry Osipenko
2018-10-29 6:53 ` Viresh Kumar
2018-10-30 15:48 ` Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 02/17] soc/tegra: fuse: Export tegra_get_chip_id() Dmitry Osipenko
2018-10-21 21:33 ` Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 03/17] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30 Dmitry Osipenko
2018-11-05 21:30 ` Rob Herring
2018-11-08 16:48 ` Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 04/17] cpufreq: tegra20: Support OPP, thermal cooling, DVFS and Tegra30 Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 05/17] ARM: tegra: Create tegra20-cpufreq device on Tegra30 Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 06/17] ARM: dts: tegra20: Add CPU Operating Performance Points Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 07/17] ARM: dts: tegra30: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 08/17] ARM: dts: tegra20: colibri: Setup voltage regulators for DVFS Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 09/17] ARM: dts: tegra20: harmony: " Dmitry Osipenko
2018-10-22 15:33 ` Stephen Warren
2018-10-22 22:59 ` Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 10/17] ARM: dts: tegra20: paz00: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 11/17] ARM: dts: tegra20: seaboard: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 12/17] ARM: dts: tegra20: tamonten: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 13/17] ARM: dts: tegra20: ventana: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 14/17] ARM: dts: tegra30: apalis: " Dmitry Osipenko
2018-10-21 20:54 ` [RFC PATCH v2 15/17] ARM: dts: tegra30: beaver: " Dmitry Osipenko
2018-10-21 20:55 ` [RFC PATCH v2 16/17] ARM: dts: tegra30: cardhu: " Dmitry Osipenko
2018-10-21 20:55 ` [RFC PATCH v2 17/17] ARM: dts: tegra30: colibri: " 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=1540568255.2245.11.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=marcel.ziswiler@toradex.com \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=viresh.kumar@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).