Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
On Sun, Nov 7, 2010 at 6:56 AM, Nishanth Menon menon.nisha...@gmail.com wrote: Premi, Sanjeev wrote, on 11/07/2010 03:16 AM: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). yep, Good catch :) , 720 is not valid either 800/1GHz :( Thanks for pointing out that I can go up to 800 Mhz. For the record, on my 3730 based system, using: Linux version 2.6.36 (st...@build.sakoman.com) (gcc version 4.3.3 (GCC) ) #1 Thu Nov 4 21:19:18 PDT 2010 The kernel reports the processor as: OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) I tried mpurate settings of 720, 800, and 1000. Though you say it is not valid, an mpurate setting of 720 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/359 MHz An mpurate setting of 800 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/800/359 MHz An mpurate setting of 1000 is not successful and yields: WARNING: at arch/arm/mach-omap2/clock.c:440 omap2_clk_switch_mpurate_at_boot+0x80/0xb4() clock: dpll1_ck: unable to set MPU rate to 1000: -22 I will resubmit the patch changing to 800 for 36XX/37XX. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
Steve Sakoman wrote, on 11/07/2010 11:00 AM: Though you say it is not valid, an mpurate setting of 720 is successful and yields: Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/359 MHz this should be reported to linux-omap for a fix - unless someone has made some assumption in kernel.org that frequency x really means =x ;) might be good to know why if so.. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
Jason Kridner wrote, on 11/05/2010 01:46 AM:
From: Koen Kooik...@dominion.thruhere.net
Patch was updated by Jason Kridnerjkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
Signed-off-by: Jason Kridnerjkrid...@beagleboard.org
not signed-off-by: Koen?
---
board/ti/beagle/beagle.c | 20 +++-
board/ti/beagle/beagle.h |3 ++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 520e57d..93c452e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -176,7 +176,7 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM:
+ case REVISION_XM_A:
printf(Beagle xM Rev A\n);
setenv(beaglerev, xMA);
setenv(mpurate, 1000);
@@ -187,8 +187,26 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
+ case REVISION_XM_B:
+ printf(Beagle xM Rev B\n);
+ setenv(beaglerev, xMB);
+ setenv(mpurate, 1000);
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
+ break;
default:
printf(Beagle unknown 0x%02x\n, get_board_revision());
+ setenv(mpurate, 1000);
It looks to me looking at the file that mpurate usage is CPU based and
NOT board based.. maybe you should use the cpu idendity to decide on
mpurate instead?
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
}
switch (get_expansion_id()) {
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7d8dee0..fa893c4 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -37,7 +37,8 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX 0x6
#define REVISION_C4 0x5
-#define REVISION_XM 0x0
+#define REVISION_XM_A0x0
+#define REVISION_XM_B0x1
/*
* IEN - Input Enable
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon
menon.nisha...@gmail.com wrote:
Jason Kridner wrote, on 11/05/2010 01:46 AM:
From: Koen Kooik...@dominion.thruhere.net
Patch was updated by Jason Kridnerjkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
Signed-off-by: Jason Kridnerjkrid...@beagleboard.org
not signed-off-by: Koen?
---
board/ti/beagle/beagle.c | 20 +++-
board/ti/beagle/beagle.h | 3 ++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 520e57d..93c452e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -176,7 +176,7 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM:
+ case REVISION_XM_A:
printf(Beagle xM Rev A\n);
setenv(beaglerev, xMA);
setenv(mpurate, 1000);
@@ -187,8 +187,26 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
+ case REVISION_XM_B:
+ printf(Beagle xM Rev B\n);
+ setenv(beaglerev, xMB);
+ setenv(mpurate, 1000);
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
+ break;
default:
printf(Beagle unknown 0x%02x\n, get_board_revision());
+ setenv(mpurate, 1000);
It looks to me looking at the file that mpurate usage is CPU based and
NOT board based.. maybe you should use the cpu idendity to decide on
mpurate instead?
I noticed this too. I just submitted a patch for Overo that sets the
mpurate to the cpu maximum (based on cpu type and version) if the
mpurate environment variable is set to auto
This solves an additional issue: with things as they are now, it is
not possible for a user to set the mpurate to a specific value -- it
will always be overwritten. The scheme above allows the user to set a
specific value or to allow u-boot to set the maximum automatically.
Note that for 36xx my patch sets the max to 720 -- this is because
mainline/linux-omap currently does not support 1000. We can adjust
that when kernel support for 1000 appears.
My plan was to submit a similar patch for Beagle.
Steve
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
}
switch (get_expansion_id()) {
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7d8dee0..fa893c4 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -37,7 +37,8 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX 0x6
#define REVISION_C4 0x5
-#define REVISION_XM 0x0
+#define REVISION_XM_A 0x0
+#define REVISION_XM_B 0x1
/*
* IEN - Input Enable
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
Steve Sakoman wrote, on 11/05/2010 11:05 PM: On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon menon.nisha...@gmail.com wrote: Jason Kridner wrote, on 11/05/2010 01:46 AM: From: Koen Kooik...@dominion.thruhere.net Patch was updated by Jason Kridnerjkrid...@beagleboard.org: * Use tabs to match style of other board revisions * Only include board revisions that exist * Default to the same configuration as the latest revision, but without setting 'beaglerev' Signed-off-by: Jason Kridnerjkrid...@beagleboard.org not signed-off-by: Koen? --- board/ti/beagle/beagle.c | 20 +++- board/ti/beagle/beagle.h |3 ++- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 520e57d..93c452e 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -176,7 +176,7 @@ int misc_init_r(void) TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, TWL4030_PM_RECEIVER_DEV_GRP_P1); break; - case REVISION_XM: + case REVISION_XM_A: printf(Beagle xM Rev A\n); setenv(beaglerev, xMA); setenv(mpurate, 1000); @@ -187,8 +187,26 @@ int misc_init_r(void) TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, TWL4030_PM_RECEIVER_DEV_GRP_P1); break; + case REVISION_XM_B: + printf(Beagle xM Rev B\n); + setenv(beaglerev, xMB); + setenv(mpurate, 1000); + MUX_BEAGLE_XM(); + /* Set VAUX2 to 1.8V for EHCI PHY */ + twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED, + TWL4030_PM_RECEIVER_VAUX2_VSEL_18, + TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, + TWL4030_PM_RECEIVER_DEV_GRP_P1); + break; default: printf(Beagle unknown 0x%02x\n, get_board_revision()); + setenv(mpurate, 1000); It looks to me looking at the file that mpurate usage is CPU based and NOT board based.. maybe you should use the cpu idendity to decide on mpurate instead? I noticed this too. I just submitted a patch for Overo that sets the mpurate to the cpu maximum (based on cpu type and version) if the mpurate environment variable is set to auto just for the record, saw this and I liked it :) thanks. This solves an additional issue: with things as they are now, it is not possible for a user to set the mpurate to a specific value -- it will always be overwritten. The scheme above allows the user to set a specific value or to allow u-boot to set the maximum automatically. Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. Errr.. that is not completely true[1](ignoring the lack of upstream DVFS for OMAP3+) - Here is the explanation for it: 36xx family of silicon comes in 4 variants - the ones that support upto 600MHz, ones that do 800MHz, ones that do 1GHz and the ones that do 1.2GHz. the defaults posted upstream enables the least common denominator - 300,600MHz and it leaves it to board files to mention if they have silicon of additional capability- unfortunately, there is no bits that tell the s/w that(for those wondering - yeah s/w folks did try to convince h/w folks for those additional bits.. but after a long debate never succeeded) :( Anyway, to put a long story short - if your board file supports 1GHz, with upstream OPP layer, you do have the flexibility to enable 1GHz OPP - just look at opp_enable[2] usage documentation [3]. I used thermal management as an example here, but no reason why we cant use it as well.. this way, you can infact support cpufreq if you would like to as well. Ref: [1] https://patchwork.kernel.org/patch/266911/ (search for omap36xx_opp_def_list) [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/opp.h;h=5449945d589f994ed5ac25f018ced4a5dc81db30;hb=HEAD#l39 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/power/opp.txt;h=44d87ad3cea9fd345a774e196578a0cc8bf4d779;hb=HEAD#l193 -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
