Re: cpuidle and SW sleep
On Wed, Oct 15, 2014 at 10:25 AM, Ran Shalit wrote: > Hello, > > Is there anyone who can please explain the relation between SW sleep > (such as udelay), to change of C-state as done by cpuidle ? These are two different things, Ran. udelay is a way to put simple delay between two functions. The cpu will continue to perform other operations in a multithreded platform. CPUIdle sleep states are mainly to achieve power saving by programming cpus to difference states depending on how much time (estimated) a cpu is going to be idle with algorithm. So each state will have latency associated with it - enter, exit latency. If the cpu idle time falls within any of C-state's latency that will be programmed. In different state cpu will be programmed with different modes to achieve diff power saving. > How is wakeup done ? As far as I understand udelay is sw delay not HW. System Wake up can be achieved by programming a wakeup source such as keypad. > > Thanks for you comments, > Ran > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks and Regards Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 03:17 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Is that with the patch applied or without it? If without, please post the log messages from a boot after you apply the patch. - Paul These logs are with the patch shared by you. Looks to me like it boots fine. If you had hwmod debugging enabled, your kernel should have crashed after omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 omap-hsuart.2: ttyO2 at MMIO 0x4902 (irq = 74) is a OMAP UART2 ... but it didn't crash there. I'm not seeing any hwmod debug messages though, so you probably don't have DEBUG defined in omap_hwmod.c. So, I suspect whatever problem you're seeing is unrelated to the problem that the patch was intended to solve. - Paul The hwmod debug messages will be seen when I enable them on the go with: echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control This will show lots of logs as below ending with UART3 clock disabling and a hang. omap_hwmod:omap_hwmod: uart1: idling omap_hwmod:omap_hwmod: uart1: disabling clocks omap_hwmod:omap_hwmod: uart2: idling omap_hwmod:omap_hwmod: uart2: disabling clocks omap_hwmod:omap_hwmod: uart1: enabling omap_hwmod:omap_hwmod: uart1: enabling clocks omap_hwmod:omap_hwmod: uart2: enabling omap_hwmod:omap_hwmod: uart2: enabling clocks omap_hwmod:omap_hwmod: uart3: idling omap_hwmod:omap_hwmod: uart3: disabling clock - Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 03:17 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Is that with the patch applied or without it? If without, please post the log messages from a boot after you apply the patch. - Paul These logs are with the patch shared by you. Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 12:49 PM, Paul Walmsley wrote: On Tue, 5 Oct 2010, Pramod wrote: I applied this patch on my kernel which is based on android-2.6.32 enabling dynamic printks. I still see the console hang after enabling the logs in hwmod. I am using zoom3 board. Can you please let me know which defconfig from lo master branch can be used to test on zoom3? I would like to test this patch with lo master branch and zoom3. Could you please paste your boot log messages here? - Paul Hi paul, These are the boot log messages. Uncompressing Linux.. .. done, booting the kernel. Initializing cgroup subsys cpu Linux version 2.6.32.9-1-g8d10978-dirty (d...@dw-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #23 PREEMPT Tue Oct 5 12:25:20 IST 2010 CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP Zoom3 board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c06c1968, node_mem_map c07cb000 Normal zone: 1024 pages used for memmap Normal zone: 0 pages reserved Normal zone: 130048 pages, LIFO batch:31 DIE ID: 5C320156087C06005013 OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) omap_sam_base (VA) == 0xfe40 omap_sram_start (PA) == 0x4020 omap_sram_size (SIZE) == 0x1 SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Reserving 14745600 bytes SDRAM for VRAM Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=172.24.137.0:/home/dw/l25.x/25.INC3.1/myfs,nolock,wsize=1024,rsize=1024 init=/init ip=dhcp videoout=omap24xx vout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram=0:4M earlyprintk loglevel=8 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256MB 256MB = 512MB total Memory: 491008KB available (6180K code, 1352K data, 224K init, 0K highmem) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xe080 - 0xf800 ( 376 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .init : 0xc0008000 - 0xc004 ( 224 kB) .text : 0xc004 - 0xc0649000 (6180 kB) .data : 0xc0674000 - 0xc06ce3d0 ( 361 kB) Hierarchical RCU implementation. NR_IRQS:402 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz Reprogramming SDRC clock to 4 Hz GPMC revision 5.0 OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) Mount-cache hash table entries: 512 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 mux: Setting signal i2c2_scl.i2c2_scl 0x0118 -> 0x0100 mux: Setting signal i2c2_sda.i2c2_sda 0x0118 -> 0x0100 mux: Setting signal i2c3_scl.i2c3_scl 0x0118 -> 0x0100 mux: Setting signal i2c3_sda.i2c3_sda 0x0118 -> 0x0100 mux: Setting signal uart3_cts_rctx.gpio_163 0x0108 -> 0x011c mux: Setting signal cam_xclka.gpio_96 0x0004 -> 0x0004 mux: Setting signal cam_wen.gpio_167 0x0004 -> 0x0004 mux: Setting signal mcspi1_cs2.mcspi1_cs2 0x0108 -> 0x0108 mux: Setting signal cam_hs.gpio_94 0x010c -> 0x0104 mux: Setting signal cam_xclka.gpio_96 0x0004 -> 0x0004 mux: Setting signal gpmc_ncs5.gpio_56 0x0004 -> 0x0004 mux: Setting signal cam_vs.gpio_95 0x0114 -> 0x0004 mux: Setting signal sys_nirq.sys_nirq 0x0118 -> 0x4118 mux: Setting signal cam_pclk.gpio_97 0x0114 -> 0x011c mux: Setting signal cam_d2.gpio101 0x0104 -> 0x0004 mux: Setting signal mcbsp1_clkx.gpio162 0x011c -> 0x0104 mux: Setting signal etk_clk.etk_clk 0x001b -> 0x011a mux: Setting signal mcspi1_cs1.mcspi1_cs1 0x000b -> 0x011b mux: Setting signal etk_d4.etk_d4 0x0103 -> 0x011a mux: Setting signal etk_d5.etk_d5 0x0103 -> 0x011a mux: Setting signal etk_d6.etk_d6 0x0103 -> 0x011a mux: Setting signal etk_d3.etk_d3 0x0103 -> 0x011a (wl12xx): Connectivity board init (wl12xx): Connectivity board init for OMAP3+WL127x (wl12xx): wl127x_vio_leakage_fix (wl12xx): Adding Connectivity platform device (wl12xx): Configuring Connectiv
Re: beagle hangs in uart3 disabling clocks
On Tuesday 05 October 2010 11:44 AM, Paul Walmsley wrote:
Hello Lei,
On Tue, 5 Oct 2010, Ming Lei wrote:
2010/10/5 Kevin Hilman:
Ming Lei writes:
2010/10/4 Kevin Hilman:
Why? What do you need from the PM branch that is not in l-o master?
Seems master branch works fine for me, my beagle board doesn't hang
uart3 disabling clocks.
Master branch and PM branch have exactly the same functionality for
UART hwmods. The problem was that you manually enabled DEBUG in
omap_hwmod.c.
Yes, you are correct. If DEBUG in omap_hwmod.c is enabled manually,
and pass the parameter of 'earlyprintk loglevel=8' to kernel from bootloader,
this issue can be triggered even with master branch.
Does this experimental patch solve the problem, even if DEBUG is enabled
in the hwmod code?
- Paul
Hi Paul,
I applied this patch on my kernel which is based on android-2.6.32
enabling dynamic printks. I still see the console hang after enabling
the logs in hwmod.
I am using zoom3 board. Can you please let me know which defconfig from
lo master branch can be used to test on zoom3? I would like to test this
patch with lo master branch and zoom3.
Thanks,
Pramod
From d928bd31c9c4ad16a044b244ef3d2ad3ed648f6f Mon Sep 17 00:00:00 2001
From: Paul Walmsley
Date: Tue, 5 Oct 2010 00:11:27 -0600
Subject: [PATCH] RFC: omap serial: block console output while resetting
earlyconsole UART
Currently, no attempt is made to block console output while the
earlyconsole UART is unavailable. This can result in silent crashes
that are very difficult to debug due to the lack of console output.
This patch holds the console semaphore while resetting the active console
UART, which causes all console output during that time to be buffered and
then transmitted after the console semaphore is released.
Not-yet-signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/serial.c | 100 ++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 338e46a..577f8f9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -28,10 +28,13 @@
#include
#include
+#include
+
#ifdef CONFIG_SERIAL_OMAP
#include
#endif
+#include
#include
#include
#include
@@ -39,6 +42,8 @@
#include
#include
+#include
+
#include "prm.h"
#include "pm.h"
#include "cm.h"
@@ -51,6 +56,8 @@
#define UART_ERRATA_FIFO_FULL_ABORT (0x1<< 0)
#define UART_ERRATA_i202_MDR1_ACCESS (0x1<< 1)
+#define uart_id_to_ttys_id(u) (u - 1)
+
/*
* NOTE: By default the serial timeout is disabled as it causes lost
characters
* over the serial ports. This means that the UART clocks will stay on until
@@ -106,6 +113,83 @@ static LIST_HEAD(uart_list);
static u8 num_uarts;
/*
+ * early_console_uart: if earlyconsole is enabled and active, the UART
+ * ID (e.g., 1, 2, 3, 4) will be stored here. '0' means earlyconsole
+ * is disabled or some problem occurred during earlyconsole handling.
+ */
+static int early_console_uart;
+
+#define for_each_console(con) \
+ for (con = console_drivers; con != NULL; con = con->next)
+
+/* XXX belongs in kernel/printk.c or some earlyconsole file */
+/* XXX The "earlycon" string is an ugly hack */
+int _is_early_console_enabled(void)
+{
+ int ret = 0;
+ struct console *c;
+
+ acquire_console_sem();
+ for_each_console(c)
+ if (!strcmp("earlycon", c->name))
+ ret = 1;
+ release_console_sem();
+
+ return ret;
+}
+
+/* XXX document */
+static int _get_early_console_uart(void)
+{
+ u32 v;
+ int u = -EINVAL;
+
+ v = __raw_readl(phys_to_virt(OMAP_UART_INFO));
+ /* XXX see the OMAP debug-macro.S for this table */
+ switch (v) {
+ case 0:
+ case OMAP2UART1:
+ u = 1;
+ break;
+ case OMAP2UART2:
+ u = 2;
+ break;
+ case OMAP2UART3:
+ case OMAP3UART3:
+ case OMAP4UART3:
+ u = 3;
+ break;
+ case OMAP3UART4:
+ case OMAP4UART4:
+ u = 4;
+ break;
+ case ZOOM_UART:
+ WARN(1, "omap serial: ZOOM UART in use - does that go through "
+"the OMAP serial code?\n");
+ break;
+ default:
+ WARN(1, "omap serial: unknown serial port in use!\n");
+ }
+
+ return u;
+}
+
+/* XXX document */
+static void _store_early_console_uart_id(void)
+{
+ int uart_id;
+
+ if (_is_early_console_enabled()) {
+ uart_id = _get_early_console_uart();
+ if (uart_id> 0) {
+ early_console_uart = uart_id;
+ pr_info("omap serial: early console active on UART%d
(ttyS%
Re: beagle hangs in uart3 disabling clocks
Hi Sanjeev, I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: [snip]..[snip] Texas Instruments X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle Board + LPDDR/NAND DRAM: 128 MB NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... I am seeing the same issue with console on UART3 on zoom3 board. The bootloaders are older. Can you please share a link to latest bootloader which will have zoom3 support. I am using L25_INC3.x android kernel. The board hangs as soon as it boots the kernel. Enabling the logs shows us that the hang occurs when UART3 clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has anyone observed this issue on any of omap boards? ~sanjeev -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix compilation warnings
On Friday 01 October 2010 09:30 PM, Kevin Hilman wrote:
pramod.gu...@ti.com writes:
From: Pramod Gurav
patch is missing
- more descriptive subject
- more descriptive changelog (preferably incluing compilation error)
- signoff (should've been noticed when running checkpatch)
And after the '---', which tree this applies to since it does not apply
to current l-o master. In fact, it appears that all these issues have
already been fixed in l-o master.
I was working out of l-o pm branch. Sorry for the confusion!
Kevin
---
arch/arm/mach-omap2/board-omap4panda.c |2 --
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
}
static void __init omap4_panda_init(void)
{
- int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
int __init omap_mux_init_gpio(int gpio, int val)
{
struct omap_mux_entry *e;
- struct omap_mux *gpio_mux;
+ struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f6c03a7..22f175f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2223,7 +2223,7 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i< gpio_bank_count; i++) {
struct gpio_bank *bank =&gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
int j;
for (j = 0; j< hweight_long(bank->dbck_enable_mask); j++)
@@ -2291,7 +2291,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i< gpio_bank_count; i++) {
struct gpio_bank *bank =&gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
int j;
for (j = 0; j< hweight_long(bank->dbck_enable_mask); j++)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Fix compilation warnings
From: Pramod Gurav
---
arch/arm/mach-omap2/board-omap4panda.c |2 --
arch/arm/mach-omap2/mux.c |2 +-
arch/arm/plat-omap/gpio.c |4 ++--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c03d1d5..96f5bbb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void)
}
static void __init omap4_panda_init(void)
{
- int status;
-
omap4_panda_i2c_init();
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index ab403b2..6c2f8f0 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -87,7 +87,7 @@ static char *omap_mux_options;
int __init omap_mux_init_gpio(int gpio, int val)
{
struct omap_mux_entry *e;
- struct omap_mux *gpio_mux;
+ struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index f6c03a7..22f175f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2223,7 +2223,7 @@ void omap2_gpio_prepare_for_idle(int power_state)
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
@@ -2291,7 +2291,7 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
int j;
for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
Hello Paul, Can you please push these patches if you don't you are OK with them? - Thanks and Best Regards Pramod Gurav > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Gurav , Pramod > Sent: Friday, April 23, 2010 7:53 PM > To: linux-omap@vger.kernel.org; Paul Walmsley; Kevin Hilman > Cc: Sripathy, Vishwanath; K, Ambresh > Subject: RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall > latency during DVFS > > Hi Paul, > > Please let me know if you have any comments on the patches below. > The comments from Kevin, Ambresh and Sergio have been addressed in the > last version of the patches and few in these patches. > > > -Original Message- > > From: Gurav , Pramod > > Sent: Thursday, April 01, 2010 10:47 PM > > To: linux-omap@vger.kernel.org > > Cc: Gurav , Pramod > > Subject: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency > > during DVFS > > > > From: Pramod Gurav > > > > The patch has the changes to calculate the dpll3 clock stabilization > > delay dynamically. The SRAM delay is calibrated during bootup using the > > gptimers and used while calculating the stabilization delay. By using > > the dynamic method the dependency on the type of cache being used is > > removed. > > > > Formula to calculate the DVFS latency for 3430 and 3630 are different. > > The second patch implements the formula for later. > > > > This Version of patches adds optimisation to the formula implementation. > > > > Teerth Reddy (1): > > OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS > > Pramod Gurav (1): > > OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 > > > > arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 71 > > +++- > > arch/arm/mach-omap2/clock34xx.h|2 + > > arch/arm/mach-omap2/clock3xxx.c|2 +- > > arch/arm/mach-omap2/clock3xxx.h|1 + > > arch/arm/mach-omap2/clock3xxx_data.c | 13 ++ > > arch/arm/mach-omap2/sram34xx.S |8 > > arch/arm/plat-omap/include/plat/sram.h |4 ++ > > arch/arm/plat-omap/sram.c | 51 +++ > > 8 files changed, 140 insertions(+), 12 deletions(-) > > > > - > Thanks and Best Regards > Pramod Gurav > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
Hi Paul, Please let me know if you have any comments on the patches below. The comments from Kevin, Ambresh and Sergio have been addressed in the last version of the patches and few in these patches. > -Original Message- > From: Gurav , Pramod > Sent: Thursday, April 01, 2010 10:47 PM > To: linux-omap@vger.kernel.org > Cc: Gurav , Pramod > Subject: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency > during DVFS > > From: Pramod Gurav > > The patch has the changes to calculate the dpll3 clock stabilization > delay dynamically. The SRAM delay is calibrated during bootup using the > gptimers and used while calculating the stabilization delay. By using > the dynamic method the dependency on the type of cache being used is > removed. > > Formula to calculate the DVFS latency for 3430 and 3630 are different. > The second patch implements the formula for later. > > This Version of patches adds optimisation to the formula implementation. > > Teerth Reddy (1): > OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS > Pramod Gurav (1): > OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 > > arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 71 > +++- > arch/arm/mach-omap2/clock34xx.h|2 + > arch/arm/mach-omap2/clock3xxx.c|2 +- > arch/arm/mach-omap2/clock3xxx.h|1 + > arch/arm/mach-omap2/clock3xxx_data.c | 13 ++ > arch/arm/mach-omap2/sram34xx.S |8 > arch/arm/plat-omap/include/plat/sram.h |4 ++ > arch/arm/plat-omap/sram.c | 51 +++++++ > 8 files changed, 140 insertions(+), 12 deletions(-) - Thanks and Best Regards Pramod Gurav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630
To calculate the dpll3 M2 clock stabilization delay dynamically and wait
time for L3 M2 clock stabilization are different for 3430 & 3630 and is
as follows:
3430: 4*REFCLK + 8*CLKOUTX2
3630: 2*SYS_CLK + 10*CLKOUTX2
REFCLK & CLKOUTX2 are derived from M, N, M2 and DPLL reference clock.
Incase of 3430 a 2usec and 3630 1usec buffer time is added for safety.
Signed-off-by: Pramod Gurav
Signed-off-by: Vishwanath Sripathy
Signed-off-by: Ambresh K
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 6ad18f2..af0807a 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -39,6 +39,12 @@
#defineSHIFT_DPLL_M16
#defineSHIFT_DPLL_N8
#defineSHIFT_DPLL_M2 27
+
+/*
+ * While calculating M2 stabilization delay, especially the formula
+ * used for 3630 computes to zero. So to avoid calculation truncating to
+ * zero, SCALING_FACTOR is used appropriately.
+ */
#defineSCALING_FACTOR 10
/*
@@ -107,12 +113,21 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sys_clk = (1 << SCALING_FACTOR) / sys_clk_rate;
clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (n + 1) * sys_clk;
- switch_latency = (4 * refclk) + (8 * clkoutx2);
-
- /* Adding 2000 ns to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2000;
+ /*
+* wait time for L3 clk stabilization
+* for OMAP3430 = 4*REFCLK + 8*CLKOUTX2
+* for OMAP3630 = 2*REFCLK + 8*CLKOUTX2
+*/
+ if (cpu_is_omap3630()) {
+ switch_latency = (2 * sys_clk) + (10 * clkoutx2);
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+ } else {
+ refclk = (n + 1) * sys_clk;
+ switch_latency = (4 * refclk) + (8 * clkoutx2);
+ /* Adding 2000 ns to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2000;
+ }
/*
* Calculate the number of MPU cycles
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy
The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed. Hence there is no need of loop based calculation.
The wait time for L3 clock stabilization is calculated using the formula
= 4*REFCLK + 8*CLKOUTX2,
which uses the M, N and M2 read from the registers.
Since this gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3.
Signed-off-by: Teerth Reddy
Signed-off-by: Romit Dasgupta
Signed-off-by: Pramod Gurav
Signed-off-by: Vishwanath Sripathy
Signed-off-by: Ambresh K
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 56 +--
arch/arm/mach-omap2/clock34xx.h|2 +
arch/arm/mach-omap2/clock3xxx.c|2 +-
arch/arm/mach-omap2/clock3xxx.h|1 +
arch/arm/mach-omap2/clock3xxx_data.c | 13 +++
arch/arm/mach-omap2/sram34xx.S |8
arch/arm/plat-omap/include/plat/sram.h |4 ++
arch/arm/plat-omap/sram.c | 51 +
8 files changed, 125 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b2b1e37..6ad18f2 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,13 +24,22 @@
#include
#include
#include
+#include
#include "clock.h"
#include "clock3xxx.h"
#include "clock34xx.h"
#include "sdrc.h"
-#define CYCLES_PER_MHZ 100
+#defineCYCLES_PER_MHZ 100
+
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2 27
+#defineSCALING_FACTOR 10
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
@@ -51,10 +60,14 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
{
u32 new_div = 0;
u32 unlock_dll = 0;
- u32 c;
- unsigned long validrate, sdrcrate, _mpurate;
+ u32 c, delay_sram;
+ u32 clk_sel_regval, sys_clk;
+ u32 m, n, m2;
+ u32 sys_clk_rate, sdrc_clk_stab;
+ u32 refclk, clkoutx2, switch_latency;
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
+ unsigned long validrate, sdrcrate, _mpurate;
int ret;
if (!clk || !rate)
@@ -79,16 +92,37 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
unlock_dll = 1;
}
+ clk_sel_regval = __raw_readl(clk->clksel_reg);
+
+ /* Get the M, N and M2 values required for getting sdrc clk stab */
+ m = (clk_sel_regval >> SHIFT_DPLL_M) & DPLL_M_MASK;
+ n = (clk_sel_regval >> SHIFT_DPLL_N) & DPLL_N_MASK;
+ m2 = (clk_sel_regval >> SHIFT_DPLL_M2) & DPLL_M2_MASK;
+
+ sys_clk_rate = (sys_ck_p->rate) / CYCLES_PER_MHZ;
+
+ _mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
+
+ delay_sram = delay_sram_val();
+ sys_clk = (1 << SCALING_FACTOR) / sys_clk_rate;
+ clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
+
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (n + 1) * sys_clk;
+ switch_latency = (4 * refclk) + (8 * clkoutx2);
+
+ /* Adding 2000 ns to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2000;
+
/*
-* XXX This only needs to be done when the CPU frequency changes
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
*/
- _mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
- c = (_mpurate << SDRC_MPURATE_SCALE) >> SDRC_MPURATE_BASE_SHIFT;
- c += 1; /* for safety */
- c *= SDRC_MPURATE_LOOPS;
- c >>= SDRC_MPURATE_SCALE;
- if (c == 0)
- c = 1;
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2)) >> SCALING_FACTOR;
+
+ pr_debug("m = %d, n = %d, m2 =%d\n", m, n, m2);
+ pr_debug("switch_latency = %d, sys_clk_rate = %d, cycles = %d\n",
+ switch_latency, sys_clk_rate, c);
pr_debug("clock: changing CORE DPLL rate from %lu to %lu\n", clk->rate,
validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 628e8de..a9f2204 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi
[PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
From: Pramod Gurav The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. Formula to calculate the DVFS latency for 3430 and 3630 are different. The second patch implements the formula for later. This Version of patches adds optimisation to the formula implementation. Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (1): OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 71 +++- arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 ++ arch/arm/mach-omap2/sram34xx.S |8 arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 +++ 8 files changed, 140 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy
The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed.
The wait time for L3 clock stabilization is calculated using the formula
= 4*REFCLK + 8*CLKOUTX2,
which uses the M, N and M2 read from the registers.
Since this gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3.
Signed-off-by: Teerth Reddy
Signed-off-by: Pramod Gurav
Signed-off-by: Vishwanath Sripathy
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 54 +++-
arch/arm/mach-omap2/clock34xx.h|2 +
arch/arm/mach-omap2/clock3xxx.c|2 +-
arch/arm/mach-omap2/clock3xxx.h|1 +
arch/arm/mach-omap2/clock3xxx_data.c | 13
arch/arm/mach-omap2/sram34xx.S |8 +
arch/arm/plat-omap/include/plat/sram.h |4 ++
arch/arm/plat-omap/sram.c | 51 ++
8 files changed, 126 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b2b1e37..29421b1 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,13 +24,21 @@
#include
#include
#include
+#include
#include "clock.h"
#include "clock3xxx.h"
#include "clock34xx.h"
#include "sdrc.h"
-#define CYCLES_PER_MHZ 100
+#defineCYCLES_PER_MHZ 100
+
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2 27
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
@@ -56,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
int ret;
+ u32 clk_sel_regval;
+ u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
+ u32 sys_clk_rate, sdrc_clk_stab;
+ u32 refclk, clkoutx2, switch_latency;
+ unsigned int delay_sram;
if (!clk || !rate)
return -EINVAL;
@@ -79,16 +92,41 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
unlock_dll = 1;
}
+ clk_sel_regval = __raw_readl(clk->clksel_reg);
+
+ /* Get the M, N and M2 values required for getting sdrc clk stab */
+ core_dpll_mul_m = (clk_sel_regval >> SHIFT_DPLL_M) & DPLL_M_MASK;
+ core_dpll_div_n = (clk_sel_regval >> SHIFT_DPLL_N) & DPLL_N_MASK;
+ core_dpll_clkoutdiv_m2 = (clk_sel_regval >> SHIFT_DPLL_M2) &
+ DPLL_M2_MASK;
+ sys_clk_rate = clk_get_rate(sys_ck_p);
+
+ sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
+
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ (sys_clk_rate * core_dpll_mul_m * 2);
+ switch_latency = refclk + 8 * clkoutx2;
+
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
+
+ delay_sram = delay_sram_val();
+
/*
-* XXX This only needs to be done when the CPU frequency changes
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
*/
+
_mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
- c = (_mpurate << SDRC_MPURATE_SCALE) >> SDRC_MPURATE_BASE_SHIFT;
- c += 1; /* for safety */
- c *= SDRC_MPURATE_LOOPS;
- c >>= SDRC_MPURATE_SCALE;
- if (c == 0)
- c = 1;
+
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+
+ pr_debug("m = %d, n = %d, m2 =%d\n", core_dpll_mul_m, core_dpll_div_n,
+ core_dpll_clkoutdiv_m2);
+ pr_debug("switch_latency = %d, sys_clk_rate = %d, cycles = %d\n",
+ switch_latency, sys_clk_rate, c);
pr_debug("clock: changing CORE DPLL rate from %lu to %lu\n", clk->rate,
validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 628e8de..a9f2204 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_
[PATCH v2 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
1usec buffer time is added for safety.
Signed-off-by: Vishwanath Sripathy
Signed-off-by: Pramod Gurav
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 60 ++--
1 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 29421b1..58979ec 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -40,6 +40,9 @@
#defineSHIFT_DPLL_N8
#defineSHIFT_DPLL_M2 27
+#defineAVOID_TRUNC_10001000
+#defineAVOID_TRUNC_100 100
+
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
*
@@ -67,7 +70,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
u32 clk_sel_regval;
u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
u32 sys_clk_rate, sdrc_clk_stab;
- u32 refclk, clkoutx2, switch_latency;
+ u32 refclk, clkoutx2, switch_latency, dpll_lock_freq;
unsigned int delay_sram;
if (!clk || !rate)
@@ -100,28 +103,47 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
core_dpll_clkoutdiv_m2 = (clk_sel_regval >> SHIFT_DPLL_M2) &
DPLL_M2_MASK;
sys_clk_rate = clk_get_rate(sys_ck_p);
-
sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
- clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
- (sys_clk_rate * core_dpll_mul_m * 2);
- switch_latency = refclk + 8 * clkoutx2;
-
- /* Adding 2us to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2;
-
- delay_sram = delay_sram_val();
-
- /*
-* Calculate the number of MPU cycles
-* to wait for SDRC to stabilize
-*/
-
_mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
+ delay_sram = delay_sram_val();
- c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ if (cpu_is_omap3630()) {
+ /*
+* wait time for L3 clk stabilization =
+* 2*SYS_CLK + 10*CLKOUTX2
+*/
+ /*
+* To avoid truncation of floating values, AVOID_TRUNC_1000 &
+* AVOID_TRUNC_100 are multiplied and divided appropriately
+*/
+ refclk = 2 * (AVOID_TRUNC_1000 / sys_clk_rate);
+ dpll_lock_freq = (AVOID_TRUNC_1000 * AVOID_TRUNC_100 *
+ (core_dpll_div_n + 1))/
+ (2 * sys_clk_rate * core_dpll_mul_m);
+ clkoutx2 = 10 * (dpll_lock_freq * core_dpll_clkoutdiv_m2) /
+ AVOID_TRUNC_100;
+ switch_latency = refclk + clkoutx2;
+
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+ c = ((sdrc_clk_stab * _mpurate) /
+ (delay_sram * 2 * AVOID_TRUNC_1000));
+ } else {
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ (sys_clk_rate * core_dpll_mul_m * 2);
+ switch_latency = refclk + 8 * clkoutx2;
+
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
+ /*
+* Calculate the number of MPU cycles to wait for
+* SDRC to stabilize
+*/
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ }
pr_debug("m = %d, n = %d, m2 =%d\n", core_dpll_mul_m, core_dpll_div_n,
core_dpll_clkoutdiv_m2);
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. To calculate the dpll3 M2 clock stabilization delay dynamically and wait time for L3 M2 clock stabilization are different for 3430 & 3630 and is as follows: 3430: 4*REFCLK + 8*CLKOUTX2 3630: 2*SYS_CLK + 10*CLKOUTX2 REFCLK & CLKOUTX2 are derived from M, N, M2 and DPLL reference clock. Incase of 3430 a 2usec and 3630 1usec buffer time is added for safety. Below is the summery of the comments from the commumnity, those are addressed in this version of patch: 1. Change in ASM code to reduce overhead of a instruction 2. Replaced magic numbers with proper macros 3. Code style changes Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (2): OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 80 arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 + arch/arm/mach-omap2/sram34xx.S |8 +++ arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 8 files changed, 150 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3630: SDRC: Change in DVFS Latency Formula for OMAP3630
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
Signed-off-by: Vishwanath Sripathy
Signed-off-by: Pramod Gurav
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 53 +++
1 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 3f61eb2..eee0332 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -67,7 +67,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
u32 clk_sel_regval;
u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
u32 sys_clk_rate, sdrc_clk_stab;
- u32 refclk, clkoutx2, switch_latency;
+ u32 refclk, clkoutx2, switch_latency, dpll_lock_freq;
unsigned int delay_sram;
if (!clk || !rate)
@@ -103,25 +103,50 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
- clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ if (cpu_is_omap3630()) {
+ /*
+* wait time for L3 clk stabilization =
+* 2*SYS_CLK + 10*CLKOUTX2
+*/
+ /* Avoid truncation of float values */
+ refclk = 2000 / sys_clk_rate;
+ dpll_lock_freq = (1000 * 100 * (core_dpll_div_n + 1))/
+ (2 * sys_clk_rate * core_dpll_mul_m);
+ clkoutx2 = 10 * (dpll_lock_freq * core_dpll_clkoutdiv_m2) / 100;
+ switch_latency = refclk + clkoutx2;
+
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+
+ delay_sram = delay_sram_val();
+ /*
+* Calculate the number of MPU cycles to wait for
+* SDRC to stabilize
+*/
+ _mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
+
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2 * 1000));
+ } else {
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2*/
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
(sys_clk_rate * core_dpll_mul_m * 2);
- switch_latency = refclk + 8 * clkoutx2;
+ switch_latency = refclk + 8 * clkoutx2;
- /* Adding 2us to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2;
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
- delay_sram = delay_sram_val();
+ delay_sram = delay_sram_val();
- /*
-* Calculate the number of MPU cycles
-* to wait for SDRC to stabilize
-*/
+ /*
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
+*/
+ _mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
- _mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
- c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ }
pr_debug("m = %d, n = %d, m2 =%d\n", core_dpll_mul_m, core_dpll_div_n,
core_dpll_clkoutdiv_m2);
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy
The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed.
The wait time for L3 clock stabilization is calculated using the formula
= 4*REFCLK + 8*CLKOUTX2,
which uses the M, N and M2 read from the registers.
Since this gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3.
Signed-off-by: Teerth Reddy
Signed-off-by: Romit Dasgupta
Signed-off-by: Pramod Gurav
Signed-off-by: Vishwanath Sripathy
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 52 +++
arch/arm/mach-omap2/clock34xx.h|2 +
arch/arm/mach-omap2/clock3xxx_data.c | 12 +++
arch/arm/mach-omap2/sram34xx.S | 11 +++
arch/arm/plat-omap/include/plat/sram.h |4 ++
arch/arm/plat-omap/sram.c | 49 ++
6 files changed, 123 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b2b1e37..3f61eb2 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "clock.h"
#include "clock3xxx.h"
@@ -32,6 +33,13 @@
#define CYCLES_PER_MHZ 100
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2 27
+
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
*
@@ -56,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
int ret;
+ u32 clk_sel_regval;
+ u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
+ u32 sys_clk_rate, sdrc_clk_stab;
+ u32 refclk, clkoutx2, switch_latency;
+ unsigned int delay_sram;
if (!clk || !rate)
return -EINVAL;
@@ -79,16 +92,41 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
unlock_dll = 1;
}
+ clk_sel_regval = __raw_readl(clk->clksel_reg);
+
+ /* Get the M, N and M2 values required for getting sdrc clk stab */
+ core_dpll_mul_m = (clk_sel_regval >> SHIFT_DPLL_M) & DPLL_M_MASK;
+ core_dpll_div_n = (clk_sel_regval >> SHIFT_DPLL_N) & DPLL_N_MASK;
+ core_dpll_clkoutdiv_m2 = (clk_sel_regval >> SHIFT_DPLL_M2) &
+ DPLL_M2_MASK;
+ sys_clk_rate = clk_get_rate(clk_get(NULL, "sys_ck"));
+
+ sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
+
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ (sys_clk_rate * core_dpll_mul_m * 2);
+ switch_latency = refclk + 8 * clkoutx2;
+
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
+
+ delay_sram = delay_sram_val();
+
/*
-* XXX This only needs to be done when the CPU frequency changes
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
*/
+
_mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
- c = (_mpurate << SDRC_MPURATE_SCALE) >> SDRC_MPURATE_BASE_SHIFT;
- c += 1; /* for safety */
- c *= SDRC_MPURATE_LOOPS;
- c >>= SDRC_MPURATE_SCALE;
- if (c == 0)
- c = 1;
+
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+
+ pr_debug("m = %d, n = %d, m2 =%d\n", core_dpll_mul_m, core_dpll_div_n,
+ core_dpll_clkoutdiv_m2);
+ pr_debug("switch_latency = %d, sys_clk_rate = %d, cycles = %d\n",
+ switch_latency, sys_clk_rate, c);
pr_debug("clock: changing CORE DPLL rate from %lu to %lu\n", clk->rate,
validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 628e8de..a9f2204 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
+unsigned int delay_sram_val(void);
+
#endif
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 57522de
[PATCH 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. Formula to calculate the DVFS latency for 3430 and 3630 are different. The second patch implements the formula for later. Below is the summery of the comments from the commumnity, those are addressed by these patches: 1. Subject of the patch mentioned as OMAP3: SDRC: instead of OMAP3: PM. 2. The first available dmtimer is requested dynamically instead of statically requesting a dmtimer. Thus hardcoding is avoided. 3. Excluded use of direct physical address of dmtimer. Instead used dmtimer APIs. 3. Only the counter loop is run in ASM. 4. Restructuring of formula for DVFS latency for 3430. 5. Adding new implementation for DVFS latency for 3630. Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (2): OMAP3630: SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 83 arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx_data.c | 12 + arch/arm/mach-omap2/sram34xx.S | 11 arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 49 +++ 6 files changed, 151 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: struct dmtimer definition not available in header file
Hi Benoit, Kelvin, > >> OMAP2_L4_IO_ADDRESS(gpt_phys_base + > >> OMAP_TIMER_COUNTER_OFFSET); > >> > >> gt_rate = clk_get_rate(omap_dm_timer_get_fclk(gpt)); > >> omap_dm_timer_set_load_start(gpt, 0, 0); > >> > >>. > >>. > >>. > >> } > >> > >> I am not able to reference *gpt as the file does not know about struct > >omap_dm_timer. I have included plat/dmtimer.h. > >> > >> Why doesn't the dmtimer struct definition appear in plat/dmtimer.h ? > >> Is there any reason for this? > > > >The declaration appears there, but the definition is hidden. > > > >In fact, it is is hidden to prevent exactly the type of thing you're > >trying to do, and to provide all access to DM timer details via the DM > >timer API. > > > >Looking at your example, I'm guessing you're trying to implement one > >of my ideas for the SDRC delay calculation by passing the base address > >to the assembly routine. > > > >As I suggested in my original patch, the better way to do this would > >be to extend the dmtimer API, and use C instead of assembly. > > Considering the accuracy needed in that case and the number of iteration > (1), I clearly don't think we need to ack the dmtimer API to read the > timer value in ASM. > Using the regular omap_dm_timer_read_counter before and after calling the > ASM function will be enough. > Moreover the current ASM function can be simplify to reduce the overhead. > Thank you. I am trying with DMtimer API. I will even reduce the dmtimer part of ASM code and run only the loop in ASM. Thanks and Regards Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
struct dmtimer definition not available in header file
Hi All,
I am using dmtimer in my code. Code looks like this:
{
static struct omap_dm_timer *gpt;
void * __iomem gpt10_counter_reg;
unsigned long gpt_phys_base;
omap_dm_timer_init();
gpt = omap_dm_timer_request();
if (!gpt) {
pr_err("Could not get the gptimer\n");
return -1;
}
omap_dm_timer_set_source(gpt, OMAP_TIMER_SRC_SYS_CLK);
gpt_phys_base = gpt->phys_base;
gpt10_counter_reg =
OMAP2_L4_IO_ADDRESS(gpt_phys_base +
OMAP_TIMER_COUNTER_OFFSET);
gt_rate = clk_get_rate(omap_dm_timer_get_fclk(gpt));
omap_dm_timer_set_load_start(gpt, 0, 0);
.
.
.
}
I am not able to reference *gpt as the file does not know about struct
omap_dm_timer. I have included plat/dmtimer.h.
Why doesn't the dmtimer struct definition appear in plat/dmtimer.h ?
Is there any reason for this?
-
Thanks and Best Regards
Pramod Gurav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS
> -Original Message- > From: K, Ambresh > Sent: Wednesday, March 10, 2010 12:38 PM > To: Gurav , Pramod > Cc: K, Ambresh; Reddy, Teerth; linux-omap@vger.kernel.org; Sripathy, > Vishwanath; Paul Walmsley; Kevin Hilman; Kandasamy, Rajkumar > Subject: Re: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency > during DVFS Hello Ambresh, > > > We can get ride of the steps used to calculate CLKOUTX2, by simply > calling parent's (dpll3_ck) clk->recalc function pointer. > > recalc function will return CLKOUT, so CLKOUTX2 = CLKOUT * 2. > > pseudo code > > struct clk *parent = clk->parent; > clkout = parent->recalc(); > clkoutx2 = clkout * 2; > I will test this and update the patch if works fine. > To derive REFCLK. the only unknown parameter will be N, which can be > read from .clksel_reg. > > Why can't we use do_div() api to calculate REFCLK, instead of manual > calculation? > This should hold good for 3430 formula. I am also modifying the code to get 3630 formula included for DVFS latency calculation. But, I am not sure whether using do_div() takes care of truncation (fraction part) as the 3630 formula gives very small value (Need to converted to nano seconds). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS
Hi Ambresh,
> > + clk_sel_regval = cm_read_mod_reg(PLL_MOD, CM_CLKSEL);
>
> *clk already as reference to CM_CLKSEL:
>
> static struct clk dpll3_m2_ck = {
> [...]
> .clksel_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
> .clksel_mask= OMAP3430_CORE_DPLL_CLKOUT_DIV_MASK,
> [...]
>
> so please use .clksel_reg to read the register content.
>
This will be done.
> > + sys_clk_rate = clk_get_rate(clk_get(NULL, "osc_sys_ck"));
>
> Should it be "sys_ck" instead of "osc_sys_ck"?
>
> According to my understanding from trm, I guess CLKINP represents DPLL3
> reference clock (DPLL3_ALWON_FCLK) which is nothing but "sys_ck".
>
> Should not make a difference when the sys_clk divisor is 1, but if it is
> 2, then sys_ck=osc_sys_ck/2.
Yes, it has to be sys_ck and it will be taken care.
>
> > + /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
> > + nr1 = (4 * (core_dpll_div_n + 1) * 2 * core_dpll_clkoutdiv_m2 *
> > +core_dpll_mul_m);
> > + nr2 = 8 * (core_dpll_div_n + 1);
> > + nr = nr1 + nr2;
> > +
> > + dr = 2 * sys_clk_rate * core_dpll_mul_m * core_dpll_clkoutdiv_m2;
> > +
>
> I am not able to understand the calculations completely for
> (nr1 + nr2) / dr. and I guess you could simplify the calculation a bit
> by removing the redundant multiplications and divisions.
> And also may be you can use m, n & m2 instead of core_dpll_xxx_xx, to
> make code more readable.
>
>
I am restructuring the formula with appropriate variable names.
Thank you for your comments.
Regards,
Pramod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB charging over TPS65950 BCI
hi gregoire, i did not mention about charge current. the sysfs entry charge_current always returns 360. -- Best Regards Pramod On Fri, Sep 11, 2009 at 7:21 PM, pramod gurav wrote: > Hello gregoire, > > Really sorry I could not reply to your mail as I was busy with some other > work. > I applied your above patch tested. The sysfs entries return correct > values for status, charger device(online), voltage_now. But the > current across the battery is reported wrong. I compared the values > returned by current_now sysfs entry with multimeter values across the > battery. The values were varying whenever I remove AC and plug it > back. But what I could see was the current_now value was approximately > double the actual current across the battery. > Without your patch the twl4030_bci gives wrong values for current_now, > voltage_now, capacity etc. > But your patch fixes this issue. > > But the USB charging did not work. Is USB charging functional with > TWL4030 on any of the OMAP boards? > > > Don't mind for the late reply. Thanks for your help. > > -- > Thanks and Best Regards > Pramod > > On Wed, Aug 5, 2009 at 9:48 PM, Gregoire Gentil wrote: >> Hello, >> >> Any feed-back on the patch I sent? Have you tried it? Have you fixed >> your problem? >> >> Grégoire >> >> >> On Fri, 2009-07-31 at 23:41 -0700, Gregoire Gentil wrote: >>> On Fri, 2009-07-31 at 19:19 +0530, pramod gurav wrote: >>> > Hi All, >>> > I was trying to get the USB battery charging working over TPS65950 BCI >>> > on the OMAP3430 custom board. I am working with linux-omap-2.6 >>> > v2.6.28-omap1 tag. I enabled the TWL4030 MADC and TWL4030 BCI drivers. >>> > I passed interrupt details to these drivers from platform_device >>> > structure from my board file. I could get the AC charging working. The >>> > AC and USB detection worked. However the USB charging is not >>> > happening. >>> > I read through the TPS TRM and took the dumps of the registers from >>> > BCI and some from TWL USB module and BOOT_BCI whenever I plug in the >>> > USB charger between host and the board. The register settings seem to >>> > be fine. But the battery is not charging. I am using BQ27000 chip for >>> > battery monitoring and I can see the battery voltage is decreasing. >>> > >>> > Following are the register dumps of TWL with and without USB plugged in: >>> > >>> > These are the register contents when USB charger is plugged in: >>> > BCIMDEN = 0x11 >>> > REG_BOOT_BCI = 0x37 >>> > REG_POWER_CTRL = 0x20 >>> > REG_BCIMFSTS4 = 0xf4 >>> > REG_BCIMFSTS1 = 0x13 >>> > REG_BCIIREF1 = 0x68 >>> > REG_BCIIREF2 = 0x3 >>> > REG_BCIMFEN4 = 0x6f >>> > REG_BCIMFSTS2 = 0x0 >>> > REG_BCIMSTATEC = 0x12 >>> > REG_STS_HW_CONDITIONS= 0x90 >>> > >>> > >>> > These are the register contents when USB charger is plugged out: >>> > BCIMDEN = 0x0 >>> > REG_BOOT_BCI = 0x35 >>> > REG_POWER_CTRL = 0x20 >>> > REG_BCIMFSTS4 = 0xf0 >>> > REG_BCIMFSTS1 = 0xaa >>> > REG_BCIIREF1 = 0x68 >>> > REG_BCIIREF2 = 0x3 >>> > REG_BCIMFEN4 = 0x68 >>> > REG_BCIMFSTS2 = 0x0 >>> > REG_BCIMSTATEC =0x0 >>> > REG_STS_HW_CONDITIONS= 0x10 >>> > >>> > Is there anything more I need to support to get BCI USB charging >>> > working? Need I follow any USB Communication protocol between Host and >>> > the board. >>> > I have pasted the kernel boot logs for reference at the end. >>> > Can any one please guide me to some pointers? >>> > >>> > -- >>> > Best Regards >>> > Pramod >>> I'm experiencing some problems with TWL4030 DC charging and I'm >>> interested by this kind of problem. Basically, the values reported by >>> our patch is different from the current going to the battery. We wrote >>> the attached enhanced patch so as to edit at run-time the charging mode >>> and various values including charge_current. It's against 2.6.29 but I >>> think that it should work again 2.6.28. Unfortunately, starting 2.6.30, >>> Tony has removed all the BCI battery code and has asked for updated code >>> against mainline but I've not seen anything so far. >>> >>> Pramod, can you try the attached patch (perhaps, it will
USB charging over TPS65950 BCI
Hi All, I was trying to get the USB battery charging working over TPS65950 BCI on the OMAP3430 custom board. I am working with linux-omap-2.6 v2.6.28-omap1 tag. I enabled the TWL4030 MADC and TWL4030 BCI drivers. I passed interrupt details to these drivers from platform_device structure from my board file. I could get the AC charging working. The AC and USB detection worked. However the USB charging is not happening. I read through the TPS TRM and took the dumps of the registers from BCI and some from TWL USB module and BOOT_BCI whenever I plug in the USB charger between host and the board. The register settings seem to be fine. But the battery is not charging. I am using BQ27000 chip for battery monitoring and I can see the battery voltage is decreasing. Following are the register dumps of TWL with and without USB plugged in: These are the register contents when USB charger is plugged in: BCIMDEN = 0x11 REG_BOOT_BCI= 0x37 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf4 REG_BCIMFSTS1 = 0x13 REG_BCIIREF1= 0x68 REG_BCIIREF2= 0x3 REG_BCIMFEN4= 0x6f REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC = 0x12 REG_STS_HW_CONDITIONS= 0x90 These are the register contents when USB charger is plugged out: BCIMDEN = 0x0 REG_BOOT_BCI= 0x35 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf0 REG_BCIMFSTS1 = 0xaa REG_BCIIREF1= 0x68 REG_BCIIREF2= 0x3 REG_BCIMFEN4= 0x68 REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC =0x0 REG_STS_HW_CONDITIONS= 0x10 Is there anything more I need to support to get BCI USB charging working? Need I follow any USB Communication protocol between Host and the board. I have pasted the kernel boot logs for reference at the end. Can any one please guide me to some pointers? -- Best Regards Pramod Starting kernel ... Uncompressing Linux... done, boo. Linux version 2.6.28-omap1-(gpra...@gpramod.mistral.in) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #25 Fri Jul 31 15:48:37 I9 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3430 Main Board Memory policy: ECC disabled, Data cache writeback OMAP3430 Unknown revision SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Reserving 4194304 bytes SDRAM for VRAM Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext3 rootdelay=3 android.ril=pts/0 init=/init Unknown boot option `android.ril=pts/0': ignoring Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz Reprogramming SDRC GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 1024 (order: 10, 4096 bytes) OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 250880KB available (3580K code, 755K data, 300K init) Calibrating delay loop... 494.72 BogoMIPS (lpj=1933312) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 312 bytes NET: Registered protocol family 16 Found NAND on CS0 Registering NAND on CS0 OMAP DMA hardware revision 4.0 USB: No board-specific platform config found OMAP DSS rev 2.0 OMAP DISPC rev 3.0 OMAP VENC rev 2 i2c_omap i2c_omap.1: bus 1 rev3.12 at 400 kHz Skipping twl4030 internal clock init and using bootloader value (unknown osc rate) twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz SCSI subsystem initialized twl4030_usb twl4030_usb: Initialized TWL4030 USB module usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) ashmem: initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc. msgmni has been set to 490 alg: No test for stdrng (krng) io scheduler noop registered io sche
I2C1 controller timed out with twl4030-powerbutton
Hi all, I am working on omap3430 custom board with linux-omap-2.6 (2.6.28-omap1 tag) on it. I am using twl4030 power buttom. Whenever I press the power key I get i2c controller timed out. I am seeing following logs and the keypad stops responding and I have to remove the board supply completely. i2c_omap i2c_omap.1: controller timed out i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out When I enabled the logs I could see twl4030: i2c error -110 while reading TWL4030 PM_MASTER STS_HW_CONDITIONS register The behavior is seen mostly with power-button key. Is there any fix that has gone into the kernel for this(after 2.6.28-omap1)? -- Best Regards Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Hi Ramesh, This worked. Thanks a lot. -- Best Regards Pramod On Wed, Apr 22, 2009 at 2:44 PM, Gupta, Ramesh wrote: > Hi Pramod, > > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of pramod gurav >> Sent: Wednesday, April 22, 2009 1:17 PM >> To: Menon, Nishanth >> Cc: linux-omap@vger.kernel.org >> Subject: Re: dma_alloc_coherent fragmentation >> >> Hi Nishant, >> I am facing the same problem to allocate a chunk of 4MB on omap3evm >> using dma_alloc_coherent. I used the test driver mentioned here >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html >> >> I applied the patch for >> ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by >> Russell, but stiill seeing the error saying >> >> coherent allocation too big (requested 0x40 mask 0x) >> alloc[0] - virt=0x phy=0x size=0x0040 >> Allocation failed idx=0 >> insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot >> allocate memory >> >> I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | >> __GFP_RECLAIMABLE), but failed to insmod the module. >> I am working on linux-omap 2.6.28 kernel. Even I could not allocate >> memory size greater than 1MB. >> Has this been fixed? Are there any patches to fix this issue? >> > > What is the value for 'CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE' (default is 2 in > omap_3430sdp_defconfig), Can you please > try increasing to 8? > > Regards > Ramesh Gupta G > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Thanks for the quick reply. Can you please point me to some links on DMA pools. I am just blank on this. :( I will still search for this in net. -- Best Regards Pramod On Wed, Apr 22, 2009 at 1:20 PM, Shilimkar, Santosh wrote: > DMA pool is better solution for such usecases. >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of pramod gurav >> Sent: Wednesday, April 22, 2009 1:17 PM >> To: Menon, Nishanth >> Cc: linux-omap@vger.kernel.org >> Subject: Re: dma_alloc_coherent fragmentation >> >> Hi Nishant, >> I am facing the same problem to allocate a chunk of 4MB on omap3evm >> using dma_alloc_coherent. I used the test driver mentioned here >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html >> >> I applied the patch for >> ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by >> Russell, but stiill seeing the error saying >> >> coherent allocation too big (requested 0x40 mask 0x) >> alloc[0] - virt=0x phy=0x size=0x0040 >> Allocation failed idx=0 >> insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot >> allocate memory >> >> I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | >> __GFP_RECLAIMABLE), but failed to insmod the module. >> I am working on linux-omap 2.6.28 kernel. Even I could not allocate >> memory size greater than 1MB. >> Has this been fixed? Are there any patches to fix this issue? >> >> On Thu, Mar 19, 2009 at 2:36 PM, Menon, Nishanth wrote: > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Hi Nishant, I am facing the same problem to allocate a chunk of 4MB on omap3evm using dma_alloc_coherent. I used the test driver mentioned here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html I applied the patch for ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by Russell, but stiill seeing the error saying coherent allocation too big (requested 0x40 mask 0x) alloc[0] - virt=0x phy=0x size=0x0040 Allocation failed idx=0 insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot allocate memory I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | __GFP_RECLAIMABLE), but failed to insmod the module. I am working on linux-omap 2.6.28 kernel. Even I could not allocate memory size greater than 1MB. Has this been fixed? Are there any patches to fix this issue? On Thu, Mar 19, 2009 at 2:36 PM, Menon, Nishanth wrote: > Hi Hiroshi, >> -Original Message- >> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] >> Sent: Thursday, March 19, 2009 8:43 AM > >> >> >> What would happen with __GFP_RECLAIMABLE for dma_alloc_coherent()? > As per [1], GFP_TEMPORARY might be the right approach.. but yes, > Changing dummy to do: > dma_alloc_coherent(NULL, b[i].size, &b[i].phy, GFP_TEMPORARY); > > Seems to resolve the issue with the dummy driver. > > The question however still remains: For a driver to allocate a memory which > is not temporary in nature we'd recommend GFP_KERNEL. But as part of the exit > sequence the driver will deallocate that memory and as part of init sequence, > reallocate. Given that the memory is not reclaimed immediately, it looks like > the only way to ensure that would be to do GFP_KERNEL | __GFP_RECLAIMABLE > (which essentially is the definition of GFP_TEMPORARY). > > Regards, > Nishanth Menon > Ref: > [1] http://lkml.indiana.edu/hypermail/linux/kernel/0705.2/0638.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Regards Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
i2c-probe in 2.6.28 returns -EOPNOTSUPP
Hi All I am trying to port the i2c client drivers from linux-omap-2.6.26 to 2.6.28. The i2c client drivers are old styled. The i2c-probe function called by attach_adapter function returns -EOPNOTSUPP. This states adapter does not support SMBUS_QUICK command. Same driver on linux-omap-2.6.26 works well. The omap_i2c_func in i2c-omap.c driver doesn't seem to be returning this support. What changes have gone into i2c-omap driver that are causing i2c-probe function to return this error value? -- Best Regards Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C1 controller timed out issue
Hi, The kernel is from the tag "v2.6.26-omap2". And I applied the patch http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff; h=663715fc55ea5d292171c6934a2b91d8f4874171;hp=3c0134484bd5fe3c3d9611aab1983881efc894c0 But it did not work for me. Pramod On Mon, Dec 22, 2008 at 10:44 AM, pramod gurav wrote: > Hi, > I am using current linux-omap git sources. Can you please post the patch to > fix > this timeout issue. > > On Sat, Dec 20, 2008 at 7:39 PM, Felipe Balbi wrote: >> On Sat, Dec 20, 2008 at 03:34:00PM +0530, pramod gurav wrote: >>> Hi, >>> I am working on OMAP3430 board. The kernel is linux-omap-2.6. >>> The twl5030 module is sitting on i2c1. >>> I often come across a error saying >>> >>> i2c_omap i2c_omap.1: controller timed out >>> i2c_omap i2c_omap.1: controller timed out >>> >>> This is all what appears in logs when i2c1 times out and all the >>> other slave devices on i2c1 stop responding. Other i2c busses(2) >>> work properly. if try to reboot the I2C fails to respnd in u-boot also >>> saying >>> >>> timed out in wait_for_pin: I2C_STAT=0 >>> I2C read failed >>> timed out in wait_for_pin: I2C_STAT=0 >>> I2C read failed >>> timed out in wait_for_pin: I2C_STAT=0 >>> I2C read failed >>> >>> I have to to do hard reset to progress with the boot. >>> >>> I gone through the changes happened to i2-omap driver in between >>> and tried applying the patches manually. >>> The problem still persists. >>> May be I am missing some more changes. >>> >>> The i2-omap.c source is attached herewith this mail. >>> Somebody please suggest me on this issue if this has been seen as >>> a issue and if fixed. >> >> Are you using current linux-omap from git ? This problem is long gone. >> >> -- >> balbi >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C1 controller timed out issue
Hi, I am using current linux-omap git sources. Can you please post the patch to fix this timeout issue. On Sat, Dec 20, 2008 at 7:39 PM, Felipe Balbi wrote: > On Sat, Dec 20, 2008 at 03:34:00PM +0530, pramod gurav wrote: >> Hi, >> I am working on OMAP3430 board. The kernel is linux-omap-2.6. >> The twl5030 module is sitting on i2c1. >> I often come across a error saying >> >> i2c_omap i2c_omap.1: controller timed out >> i2c_omap i2c_omap.1: controller timed out >> >> This is all what appears in logs when i2c1 times out and all the >> other slave devices on i2c1 stop responding. Other i2c busses(2) >> work properly. if try to reboot the I2C fails to respnd in u-boot also >> saying >> >> timed out in wait_for_pin: I2C_STAT=0 >> I2C read failed >> timed out in wait_for_pin: I2C_STAT=0 >> I2C read failed >> timed out in wait_for_pin: I2C_STAT=0 >> I2C read failed >> >> I have to to do hard reset to progress with the boot. >> >> I gone through the changes happened to i2-omap driver in between >> and tried applying the patches manually. >> The problem still persists. >> May be I am missing some more changes. >> >> The i2-omap.c source is attached herewith this mail. >> Somebody please suggest me on this issue if this has been seen as >> a issue and if fixed. > > Are you using current linux-omap from git ? This problem is long gone. > > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
I2C1 controller timed out issue
Hi, I am working on OMAP3430 board. The kernel is linux-omap-2.6. The twl5030 module is sitting on i2c1. I often come across a error saying i2c_omap i2c_omap.1: controller timed out i2c_omap i2c_omap.1: controller timed out This is all what appears in logs when i2c1 times out and all the other slave devices on i2c1 stop responding. Other i2c busses(2) work properly. if try to reboot the I2C fails to respnd in u-boot also saying timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed I have to to do hard reset to progress with the boot. I gone through the changes happened to i2-omap driver in between and tried applying the patches manually. The problem still persists. May be I am missing some more changes. The i2-omap.c source is attached herewith this mail. Somebody please suggest me on this issue if this has been seen as a issue and if fixed. Thanks Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth SHUTDOWN GPIO on omap3430 labrador
Hi All I have a omap3430 logic zoom board. I want to configure bluetooth on it(BRF6300) which will interfaced to UART2. I gone through the schematics and could find that the BT_SHUTDOWN is controlled through GPIO.8 coming from TWL4030. Is that wright? I tried using that GPIO but the hci interface did not respond. I am using linux-2.6.24 with all bluetooth kernel support. What is correct GPIO to BT_SHUTDOWN. Reply is much awaited. Thanks for time and consideration. Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bluetooth GPIO on logic zoom omap3430 (labrador) board
Hi All I have a omap3430 logic zoom board. I want to configure bluetooth on it(BRF6300) which will interfaced to UART2. I gone through the schematics and could find that the BT_SHUTDOWN is controlled through GPIO.8 coming from TWL4030. Is that wright? I tried using that GPIO but the hci interface did not respond. I am using linux-2.6.24 with all bluetooth kernel support. What is correct GPIO to BT_SHUTDOWN. Reply is much awaited. Thanks for time and consideration. Pramod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
