[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1540568255.2245.11.camel@pengutronix.de>
Date: Fri, 26 Oct 2018 17:37:35 +0200
From: Lucas Stach <l.stach@...gutronix.de>
To: Dmitry Osipenko <digetx@...il.com>,
Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Rob Herring <robh+dt@...nel.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
Marcel Ziswiler <marcel.ziswiler@...adex.com>,
linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage
regulators
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
Powered by blists - more mailing lists