devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: linux-omap@vger.kernel.org,
	"Kevin Hilman" <khilman@deeprootsystems.com>,
	"Benoît Cousson" <b-cousson@ti.com>,
	"Shawn Guo" <shawn.guo@linaro.org>, Keerthy <j-keerthy@ti.com>,
	devicetree-discuss@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org, cpufreq@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
Date: Fri, 15 Mar 2013 10:48:57 +0530	[thread overview]
Message-ID: <5142AF41.7070003@ti.com> (raw)
In-Reply-To: <1363294695-658-1-git-send-email-nm@ti.com>

On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> migrating the cpufreq support only through device tree (part of the effort
> to migrate away from non-DT configurations for OMAP). Unfortunately, as already
> known, we have a bunch of legacy code and mutually dependent device tree
> conversion that is pending.
> Key features pending:
> A) clock framework transition to DT - this should happen soon, so this series hacks
> the clock node for the time being as suggested in review of original series
> B) on processors that use voltage controller, voltage processor (VC/VP hardware
> loop using I2C_SR path) - we have started work on transitioning them to regulator
> framework driven by DT.
> C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> 
> As a result of these pending features:
> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
> associated at the moment - fortunately, we boot at highest voltage, so things still
> work.
> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
> those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
> where certain OPPs need enabling based on efuse programmed bit sequences - since it
> is an add-on work, it is not addressed here.
> 
Thanks for looking into it.

> Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
> converted to CCF, we could remove the DT regulator requirements there as well.
> 
> Key benefit of the series is to allow all relevant TI platforms now to use a single
> cpufreq driver and equivalent frameworks in addition be part of the transition to
> DT. As a result of this series, CPUFreq feature will not be available for non-DT
> boot systems.
> 
As commented by Jon on internal thread, I am also against the idea of dropping
non-DT support now. Till we migrate to 100 % DT, it is best to keep support
alive. Especial OMAP3 based devices.

Why don't you take phased approach and have both supported for time being.
Then once we move to DT only, we just drop the non-DT support as we plan
to do for many more stuff.

BTW, we are using only CPUFreq driver before this series as well. I guess you
mean the common CPUFReq drivers used by other ARM SOCs.

Regards,
Santosh

  parent reply	other threads:[~2013-03-15  5:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 20:58 [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver Nishanth Menon
2013-03-14 20:58 ` [PATCH 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree Nishanth Menon
2013-03-14 21:43   ` Jon Hunter
2013-03-14 20:58 ` [PATCH 2/8] ARM: dts: OMAP36xx: " Nishanth Menon
2013-03-14 21:44   ` Jon Hunter
2013-03-15 13:56     ` Nishanth Menon
2013-03-15 14:26       ` Jon Hunter
2013-03-15 14:38         ` Nishanth Menon
2013-03-15 14:58           ` Jon Hunter
2013-03-15 15:02             ` Nishanth Menon
2013-03-14 20:58 ` [PATCH 3/8] ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU Nishanth Menon
2013-03-14 20:58 ` [PATCH 4/8] ARM: dts: OMAP443x: move CPU OPP tables to device tree Nishanth Menon
2013-03-14 20:58 ` [PATCH 5/8] ARM: dts: omap4-panda: move generic sections to panda-common Nishanth Menon
2013-03-14 20:58 ` [PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree Nishanth Menon
2013-03-14 21:49   ` Jon Hunter
2013-03-15 14:08     ` Nishanth Menon
2013-03-14 20:58 ` [PATCH 7/8] ARM: OMAP3+: use cpu0-cpufreq driver Nishanth Menon
2013-03-14 20:58 ` [PATCH 8/8] cpufreq: omap: remove omap-cpufreq Nishanth Menon
2013-03-15  4:51   ` Viresh Kumar
2013-03-15 14:24     ` Nishanth Menon
2013-03-14 21:42 ` [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver Jon Hunter
2013-03-15 13:52   ` Nishanth Menon
2013-03-15  5:18 ` Santosh Shilimkar [this message]
2013-03-15 14:21   ` Nishanth Menon
2013-03-15 14:56     ` Jon Hunter
2013-03-15 15:00       ` Nishanth Menon

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=5142AF41.7070003@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=b-cousson@ti.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=j-keerthy@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=shawn.guo@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).