Patchwork [v2,2/2] ARM: imx: enable imx6q-cpufreq support

login
register
mail settings
Submitter Shawn Guo
Date Jan. 10, 2013, 2:41 p.m.
Message ID <20130110144121.GC8680@S2101-09.ap.freescale.net>
Download mbox | patch
Permalink /patch/211026/
State New
Headers show

Comments

Shawn Guo - Jan. 10, 2013, 2:41 p.m.
On Thu, Jan 10, 2013 at 02:02:53PM +0000, Bedia, Vaibhav wrote:
> On Thu, Jan 10, 2013 at 18:50:55, Shawn Guo wrote:
> > On Thu, Jan 10, 2013 at 01:02:30PM +0000, Bedia, Vaibhav wrote:
> > > In the current approach the OPP data is split across DT and kernel code. If you take the
> > > other approach all OPP entries can reside in DT and for someone just looking at that file
> > > there's no confusion about what the kernel could potentially support. Whether a particular
> > > an OPP should be supported is best decided at runtime.
> > > 
> > Listing the OPP that some Si rev can not support in DT is also
> > a confusion to people who is just looking at DTS.  To me, the approach
> > is not really doing anything better on this aspect.
> > 
> 
> I still think putting the OPP data in a single place is better.
> 
Okay, I agree with you on that and plan to commit the following changes.
But no, still no platform hook.

Shawn
Bedia, Vaibhav - Jan. 11, 2013, 4:43 a.m.
On Thu, Jan 10, 2013 at 20:11:25, Shawn Guo wrote:
> On Thu, Jan 10, 2013 at 02:02:53PM +0000, Bedia, Vaibhav wrote:
> > On Thu, Jan 10, 2013 at 18:50:55, Shawn Guo wrote:
> > > On Thu, Jan 10, 2013 at 01:02:30PM +0000, Bedia, Vaibhav wrote:
> > > > In the current approach the OPP data is split across DT and kernel code. If you take the
> > > > other approach all OPP entries can reside in DT and for someone just looking at that file
> > > > there's no confusion about what the kernel could potentially support. Whether a particular
> > > > an OPP should be supported is best decided at runtime.
> > > > 
> > > Listing the OPP that some Si rev can not support in DT is also
> > > a confusion to people who is just looking at DTS.  To me, the approach
> > > is not really doing anything better on this aspect.
> > > 
> > 
> > I still think putting the OPP data in a single place is better.
> > 
> Okay, I agree with you on that and plan to commit the following changes.
> But no, still no platform hook.
> 

Fair enough.

Regards,
Vaibhav

Patch

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 17c5618..231a32c 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -38,6 +38,7 @@ 
                        next-level-cache = <&L2>;
                        operating-points = <
                                /* kHz    uV */
+                               1200000 1275000
                                996000  1250000
                                792000  1150000
                                396000  950000
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 16f9a13..2f974f5 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -235,9 +235,9 @@  static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)

        val = readl_relaxed(base + OCOTP_CFG3);
        val >>= OCOTP_CFG3_SPEED_SHIFT;
-       if ((val & 0x3) == OCOTP_CFG3_SPEED_1P2GHZ)
-               if (opp_add(cpu_dev, 1200000000, 1275000))
-                       pr_warn("failed to add 1.2 GHz operating point\n");
+       if ((val & 0x3) != OCOTP_CFG3_SPEED_1P2GHZ)
+               if (opp_disable(cpu_dev, 1200000000))
+                       pr_warn("failed to disable 1.2 GHz OPP\n");

 put_node:
        of_node_put(np);