[PATCH] OMAP: DISPC: Fix to disable also interface clocks
Leaving interface clocks enabled causes dss pwrdm to stay in active
state when mpu is in active state. This fix puts dss to sleep state
when it is not needed.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
drivers/video/omap/dispc.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 6aff476..ad436f5 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -914,18 +914,14 @@ static void put_dss_clocks(void)
static void enable_lcd_clocks(int enable)
{
- if (enable)
+ if (enable) {
+ clk_enable(dispc.dss_ick);
clk_enable(dispc.dss1_fck);
- else
+ }
+ else {
clk_disable(dispc.dss1_fck);
-}
-
-static void enable_interface_clocks(int enable)
-{
- if (enable)
- clk_enable(dispc.dss_ick);
- else
clk_disable(dispc.dss_ick);
+ }
}
static void enable_digit_clocks(int enable)
@@ -1361,7 +1357,6 @@ static int omap_dispc_init(struct omapfb_device *fbdev,
int ext_mode,
if ((r = get_dss_clocks()) 0)
return r;
- enable_interface_clocks(1);
enable_lcd_clocks(1);
#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
@@ -1465,7 +1460,6 @@ fail2:
free_irq(INT_24XX_DSS_IRQ, fbdev);
fail1:
enable_lcd_clocks(0);
- enable_interface_clocks(0);
put_dss_clocks();
return r;
@@ -1482,7 +1476,6 @@ static void omap_dispc_cleanup(void)
cleanup_fbmem();
free_palette_ram();
free_irq(INT_24XX_DSS_IRQ, dispc.fbdev);
- enable_interface_clocks(0);
put_dss_clocks();
}
--
1.5.5
--
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
[PATCH 0 /1] Backlight control for omap3evm
Hi all , The following patch adds backlight control for omap3evm User can vary the backlight from 0% to 100% through sysfs. To test execute. a) # echo 0 /sys/devices/platform/omapfb/panel/backlight_level This will turn off the backlight b) # echo 100 /sys/devices/platform/omapfb/panel/backlight_level This will give maximum brightness Regards, Arun C -- 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
Re: [PATCH] ARM: OMAP: Add support to Nokia N810 WiMAX
On Tue, 1 Jul 2008 07:09:10 -0500 ext Woodruff, Richard [EMAIL PROTECTED] wrote: Hi, I forgot to mention that it seems that HS OMAP or something is ceasing the operation just few seconds after bootup. Initfs gets more scripts executed but Debian from mtdblock4 hangs just in init. That is an odd statement. Are you commenting about an EMU/HS chip resetting during startup? Not resetting but the device seems to just stop during the process. Only idea what came to mind that probably HS OMAP in N810 WiMAX is causing this. There is a secure watch dog when needs to be taken care of and if you program it right. Generally your initial secure driver or stub ppa will take care of this. Secure driver at least was missing in this trial what is indeed found in our release :-) Jarkko -- 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
RE: [Question] MUSB: why not clear DMA interrupt in musbhsdma.c?
snip Actually, I don't have any detail information about the IP from mentor of Blackfin. I just found the instruction from the Blackfin manual. We need to clear DMA IRQ flag manually on Blackfin, although it is not true on Davinci. But when I tried to write large file to the U-DISK (such as 10Mbyte or 100Mbyte), speed is very slow and mush slower than PIO mode, IMO. I've certainly seen that little problem. I couldn't tell if the root cause was from Mentor's DMA support or from the kind of USB-antagonistic DMA engine on DaVinci, but when the DMA logic has to generate an IRQ for each packet (to get sane semantics), it's hopeless getting good throughput unless it's dirt cheap to set up and complete DMA transfers. (It isn't.) As has been seen elsewhere: when the cost of DMA integration exceeds the cost to stuff the FIFO by hand, DMA is not a win. That's an issue with the drivers/dma framework sometimes too, though in that case the issue is purely software. I did lots of test to compare the DMA and PIO such as a) dd large file to a USB flash disk, b) use bonnie++ to do performance test. The result is that no throughput improvement on DMA and CPU consumption is the same as PIO. We hope to see the CPU usage of DMA mode is less than PIO mode, but didn't got the expectation. Approximately how much is the performance you see with PIO mode (given that you also see the same with DMA mode)? Any chance you have dynamic tick suppression enabled (CONFIG_NO_HZ)? If so, could you try with nohz=off in your bootargs? - Anand -- 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
[PATCH 0/1] musb configs
The following patch gets rid os hdrc_cnf.h and make musb configuration details more dynamic by introducing proper fields in the platform_data. I tested the patch with n810 and omap3 beagle, but please everyone interested, give it a good review and try it out. Felipe Balbi (1): usb: musb: pass configuration specifics via pdata arch/arm/mach-omap2/board-n800-usb.c | 46 +- arch/arm/mach-omap2/usb-musb.c | 51 +- arch/arm/mach-omap2/usb-tusb6010.c |1 - drivers/usb/musb/musb_core.c | 37 +++ drivers/usb/musb/musb_core.h | 14 +--- drivers/usb/musb/tusb6010.h | 169 include/asm-arm/arch-omap/hdrc_cnf.h | 177 -- include/asm-arm/arch-omap/usb-musb.h |3 + include/linux/usb/musb.h | 38 +++- 9 files changed, 147 insertions(+), 389 deletions(-) delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h -- 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
Re: [PATCH 1/1] usb: musb: pass configuration specifics via pdata
On Tue, Jul 01, 2008 at 03:56:51PM +0300, Felipe Balbi wrote: diff --git a/include/asm-arm/arch-omap/usb-musb.h b/include/asm-arm/arch-omap/usb-musb.h index 4f0c830..bd507e7 100644 --- a/include/asm-arm/arch-omap/usb-musb.h +++ b/include/asm-arm/arch-omap/usb-musb.h @@ -29,6 +29,9 @@ #ifndef __ASM_ARCH_OMAP_USB_MUSB_H #define __ASM_ARCH_OMAP_USB_MUSB_H +#include linux/usb/musb.h +#include linux/ioport.h + extern void usb_musb_init(void); #endif /* __ASM_ARCH_OMAP_USB_MUSB_H */ this is garbage change... I'll remove and resend. -- - Balbi -- 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
[PATCH 1/1] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Cc: Tony Lindgre [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: Anand Gadiyar [EMAIL PROTECTED]
Cc: Kevin Hilman [EMAIL PROTECTED]
Cc: Bryan Wu [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-n800-usb.c | 46 +-
arch/arm/mach-omap2/usb-musb.c | 51 +-
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 +++
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h | 169
include/asm-arm/arch-omap/hdrc_cnf.h | 177 --
include/linux/usb/musb.h | 38 +++-
9 files changed, 147 insertions(+), 389 deletions(-)
delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..16ea8fc 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -35,14 +35,58 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 5,},
+ { ep1_rx, 5,},
+ { ep2_tx, 5,},
+ { ep2_rx, 5,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 2,},
+ { ep5_rx, 2,},
+ { ep6_tx, 2,},
+ { ep6_rx, 2,},
+ { ep7_tx, 2,},
+ { ep7_rx, 2,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
- .multipoint = 1,
.set_power = tusb_set_power,
.set_clock = tusb_set_clock,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
.clock = osc_ck,
+ .config = musb_config,
};
/*
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index bd3556b..933f7c1 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -37,7 +37,7 @@ static struct resource musb_resources[] = {
: OMAP243X_HS_BASE,
.end= cpu_is_omap34xx()
? OMAP34XX_HSUSB_OTG_BASE + SZ_8K - 1
- : OMAP243X_HS_BASE + SZ_8K -1,
+ : OMAP243X_HS_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* general IRQ */
@@ -71,6 +71,51 @@ static int musb_set_clock(struct clk *clk, int state)
return 0;
}
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 10, },
+ { ep1_rx, 10, },
+ { ep2_tx, 9,},
+ { ep2_rx, 9,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 3,},
+ { ep5_rx, 3,},
+ { ep6_tx, 3,},
+ { ep6_rx, 3,},
+ { ep7_tx, 3,},
+ { ep7_rx, 3,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps
RE: [PATCH] ARM: OMAP: Add support to Nokia N810 WiMAX
I forgot to mention that it seems that HS OMAP or something is ceasing the operation just few seconds after bootup. Initfs gets more scripts executed but Debian from mtdblock4 hangs just in init. That is an odd statement. Are you commenting about an EMU/HS chip resetting during startup? Not resetting but the device seems to just stop during the process. Only idea what came to mind that probably HS OMAP in N810 WiMAX is causing this. This is understandable actually. Especially if you don't have some kind of reset sequence in your power chip linked up. For instance on 3430 + T2 you need to add a reset sequence script into T2's internal memory. If you don't and you have CPUFREQ (dvfs) running, you can reboot at a time when the voltage is to low. The ROM code expects a nominal (1.2v) voltage at reset time. So when the DPLL spins up you can lock up and die. BTW, this also kills the a 'reboot' command which ultimately just does a warm reset sequence with a prcm write. ... actually in 2420 there are also errata around when its safe to issue a prcm based reset, this can also get you depending on your device. This deals with the need to be in bypass at the time of the write. There is a secure watch dog when needs to be taken care of and if you program it right. Generally your initial secure driver or stub ppa will take care of this. Secure driver at least was missing in this trial what is indeed found in our release :-) That would do it. You need to take care of a couple bits else it won't make it. This is doubly true on 3430 as your full or stub security driver needs to do a bit more. Regards, Richard W. -- 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
[PATCH 01/11] Basic cpuidle driver
OMAP3 Basic cpuidle
Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/cpuidle34xx.c | 245 ++
arch/arm/mach-omap2/cpuidle34xx.h | 56
arch/arm/mach-omap2/pm34xx.c |5
4 files changed, 306 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c2008-07-01
11:28:39.600854345 +0530
@@ -0,0 +1,245 @@
+/*
+ * linux/arch/arm/mach-omap2/cpuidle34xx.c
+ *
+ * OMAP3 CPU IDLE Routines
+ *
+ * Copyright (C) 2007-2008 Texas Instruments, Inc.
+ * Rajendra Nayak [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Karthik Dasu [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2006 Nokia Corporation
+ * Tony Lindgren [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Richard Woodruff [EMAIL PROTECTED]
+ *
+ * Based on pm.c for omap2
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/cpuidle.h
+#include asm/arch/pm.h
+#include asm/arch/prcm.h
+#include asm/arch/powerdomain.h
+#include cpuidle34xx.h
+
+#ifdef CONFIG_CPU_IDLE
+
+struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
+struct omap3_processor_cx current_cx_state;
+
+static int omap3_idle_bm_check(void)
+{
+ return 0;
+}
+
+/* omap3_enter_idle - Programs OMAP3 to enter the specified state.
+ * returns the total time during which the system was idle.
+ */
+static int omap3_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
+ struct timespec ts_preidle, ts_postidle, ts_idle;
+ struct powerdomain *mpu_pd;
+
+ current_cx_state = *cx;
+
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+
+
+ if (cx-type == OMAP3_STATE_C0) {
+ /* Do nothing for C0, not even a wfi */
+ return 0;
+ }
+
+ mpu_pd = pwrdm_lookup(mpu_pwrdm);
+ /* Program MPU to target state */
+ if (cx-mpu_state PWRDM_POWER_ON)
+ pwrdm_set_next_pwrst(mpu_pd, cx-mpu_state);
+
+ /* Execute ARM wfi */
+ omap_sram_idle();
+
+ /* Program MPU to ON */
+ if (cx-mpu_state PWRDM_POWER_ON)
+ pwrdm_set_next_pwrst(mpu_pd, PWRDM_POWER_ON);
+
+ getnstimeofday(ts_postidle);
+ ts_idle = timespec_sub(ts_postidle, ts_preidle);
+ return timespec_to_ns(ts_idle);
+}
+
+static int omap3_enter_idle_bm(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct cpuidle_state *new_state = NULL;
+ int i, j;
+
+ if ((state-flags CPUIDLE_FLAG_CHECK_BM) omap3_idle_bm_check()) {
+
+ /* Find current state in list */
+ for (i = 0; i OMAP3_MAX_STATES; i++)
+ if (state == dev-states[i])
+ break;
+ BUG_ON(i == OMAP3_MAX_STATES);
+
+ /* Back up to non 'CHECK_BM' state */
+ for (j = i - 1; j 0; j--) {
+ struct cpuidle_state *s = dev-states[j];
+
+ if (!(s-flags CPUIDLE_FLAG_CHECK_BM)) {
+ new_state = s;
+ break;
+ }
+ }
+
+ pr_debug(%s: Bus activity: Entering %s (instead of %s)\n,
+ __FUNCTION__, new_state-name, state-name);
+ }
+
+ return omap3_enter_idle(dev, new_state ? : state);
+}
+
+DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
+
+/* omap3_init_power_states - Initialises the OMAP3 specific C states.
+ * Below is the desciption of each C state.
+ *
+ C0 . System executing code
+ C1 . MPU WFI + Core active
+ C2 . MPU CSWR + Core active
+ C3 . MPU OFF + Core active
+ C4 . MPU CSWR + Core CSWR
+ C5 . MPU OFF + Core CSWR
+ C6 . MPU OFF + Core OFF
+ */
+void omap_init_power_states(void)
+{
+ /* C0 . System executing code */
+ omap3_power_states[0].valid = 1;
+ omap3_power_states[0].type = OMAP3_STATE_C0;
+ omap3_power_states[0].sleep_latency = 0;
+ omap3_power_states[0].wakeup_latency = 0;
+ omap3_power_states[0].threshold = 0;
+ omap3_power_states[0].mpu_state = PWRDM_POWER_ON;
+ omap3_power_states[0].core_state = PWRDM_POWER_ON;
+ omap3_power_states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+
+ /* C1 . MPU WFI + Core active */
+ omap3_power_states[1].valid = 1;
+ omap3_power_states[1].type = OMAP3_STATE_C1;
+
[PATCH 00/11] OMAP3 CPUidle patches
Hi, The following patches define and enable all of the below mentioned C states for OMAP3. These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and some even lack aggresive clock handling. These apply on top of the workaround patch set submitted by Jouni. ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) The following is neccessay even with a minimal config to achieve OFF. $ echo 1 /sys/power/sleep_while_idle $ echo 1 /sys/power/clocks_off_while_idle The following C states are defined C0 - System executing code C1 - MPU WFI + Core active C2 - MPU CSWR + Core active C3 - MPU OFF + Core active C4 - MPU CSWR + Core CSWR C5 - MPU OFF + Core CSWR C6 - MPU OFF + Core OFF regards, Rajendra -- 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
[PATCH 07/11] gpmc context save/restore
This patch adds the context save restore functions for GPMC
Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
arch/arm/mach-omap2/gpmc.c | 80 +++
include/asm-arm/arch-omap/gpmc.h | 14 ++
2 files changed, 94 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/gpmc.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/gpmc.c 2008-06-09
18:04:48.408424442 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/gpmc.c 2008-06-09 18:07:05.952023290
+0530
@@ -54,6 +54,21 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+/*
+ * Structure to save/restore gpmc context
+ * to support core off
+ */
+static struct gpmc_context {
+ u32 sysconfig;
+ u32 irqenable;
+ u32 timeout_ctrl;
+ u32 config;
+ u32 prefetch_config1;
+ u32 prefetch_config2;
+ u32 prefetch_control;
+ struct gpmc_cs_config cs_context[GPMC_CS_NUM];
+} gpmc_ctx;
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -429,3 +444,68 @@ void __init gpmc_init(void)
gpmc_mem_init();
}
+
+void omap_save_gpmc_ctx()
+{
+ int i;
+ gpmc_ctx.sysconfig = gpmc_read_reg(GPMC_SYSCONFIG);
+ gpmc_ctx.irqenable = gpmc_read_reg(GPMC_IRQENABLE);
+ gpmc_ctx.timeout_ctrl = gpmc_read_reg(GPMC_TIMEOUT_CONTROL);
+ gpmc_ctx.config = gpmc_read_reg(GPMC_CONFIG);
+ gpmc_ctx.prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ gpmc_ctx.prefetch_config2 = gpmc_read_reg(GPMC_PREFETCH_CONFIG2);
+ gpmc_ctx.prefetch_control = gpmc_read_reg(GPMC_PREFETCH_CONTROL);
+ for (i = 0; i GPMC_CS_NUM; i++) {
+ gpmc_ctx.cs_context[i].is_valid =
+ (gpmc_cs_read_reg(i, GPMC_CS_CONFIG7))
+(1 6);
+ if (gpmc_ctx.cs_context[i].is_valid) {
+ gpmc_ctx.cs_context[i].gpmc_config1 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG1);
+ gpmc_ctx.cs_context[i].gpmc_config2 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG2);
+ gpmc_ctx.cs_context[i].gpmc_config3 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG3);
+ gpmc_ctx.cs_context[i].gpmc_config4 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG4);
+ gpmc_ctx.cs_context[i].gpmc_config5 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG5);
+ gpmc_ctx.cs_context[i].gpmc_config6 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG6);
+ gpmc_ctx.cs_context[i].gpmc_config7 =
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG7);
+ }
+ }
+}
+
+void omap_restore_gpmc_ctx()
+{
+ int i;
+ gpmc_write_reg(GPMC_SYSCONFIG, gpmc_ctx.sysconfig);
+ gpmc_write_reg(GPMC_IRQENABLE, gpmc_ctx.irqenable);
+ gpmc_write_reg(GPMC_TIMEOUT_CONTROL, gpmc_ctx.timeout_ctrl);
+ gpmc_write_reg(GPMC_CONFIG, gpmc_ctx.config);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, gpmc_ctx.prefetch_config1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, gpmc_ctx.prefetch_config2);
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, gpmc_ctx.prefetch_control);
+ for (i = 0; i GPMC_CS_NUM; i++) {
+ if (gpmc_ctx.cs_context[i].is_valid) {
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG1,
+ gpmc_ctx.cs_context[i].gpmc_config1);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG2,
+ gpmc_ctx.cs_context[i].gpmc_config2);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG3,
+ gpmc_ctx.cs_context[i].gpmc_config3);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG4,
+ gpmc_ctx.cs_context[i].gpmc_config4);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG5,
+ gpmc_ctx.cs_context[i].gpmc_config5);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG6,
+ gpmc_ctx.cs_context[i].gpmc_config6);
+ gpmc_cs_write_reg(i, GPMC_CS_CONFIG7,
+ gpmc_ctx.cs_context[i].gpmc_config7);
+ }
+ }
+}
+
+
Index: linux-omap-2.6/include/asm-arm/arch-omap/gpmc.h
===
--- linux-omap-2.6.orig/include/asm-arm/arch-omap/gpmc.h2008-06-09
18:07:02.217142804 +0530
+++ linux-omap-2.6/include/asm-arm/arch-omap/gpmc.h 2008-06-09
18:10:31.189455603 +0530
@@ -86,6
[PATCH 08/11] serial context save/restore
This patch adds the context save restore functions for UART
Signed-off-by: Rajendra Nayak [EMAIL PROTECTED]
---
arch/arm/mach-omap2/serial.c | 62 +++
include/linux/serial_reg.h |1
2 files changed, 63 insertions(+)
Index: linux-omap-2.6/arch/arm/mach-omap2/serial.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/serial.c2008-07-01
11:08:08.844690432 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/serial.c 2008-07-01 12:14:14.542572349
+0530
@@ -83,6 +83,16 @@ static const u32 omap34xx_uart_padconf[O
CONTROL_PADCONF_UART3_RX
};
+struct omap_uart_regs {
+ u16 dll;
+ u16 dlh;
+ u16 ier;
+ u16 sysc;
+ u16 scr;
+ u16 wer;
+};
+static struct omap_uart_regs uart_ctx[OMAP_MAX_NR_PORTS];
+
static struct plat_serial8250_port serial_platform_data[] = {
{
.membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART1_BASE),
@@ -293,6 +303,58 @@ void __init omap_serial_init(void)
omap_serial_kick();
}
+void omap_save_uart_ctx(int unum)
+{
+ u16 lcr = 0;
+
+ struct plat_serial8250_port *p = serial_platform_data + unum;
+
+ if (uart_ick[unum] == NULL)
+ return;
+
+ lcr = serial_read_reg(p, UART_LCR);
+ serial_write_reg(p, UART_LCR, 0xBF);
+ uart_ctx[unum].dll = serial_read_reg(p, UART_DLL);
+ uart_ctx[unum].dlh = serial_read_reg(p, UART_DLM);
+ serial_write_reg(p, UART_LCR, lcr);
+ uart_ctx[unum].ier = serial_read_reg(p, UART_IER);
+ uart_ctx[unum].sysc = serial_read_reg(p, UART_OMAP_SYSC);
+ uart_ctx[unum].scr = serial_read_reg(p, UART_OMAP_SCR);
+ uart_ctx[unum].wer = serial_read_reg(p, UART_OMAP_WER);
+}
+EXPORT_SYMBOL(omap_save_uart_ctx);
+
+void omap_restore_uart_ctx(int unum)
+{
+ u16 efr = 0;
+
+ struct plat_serial8250_port *p = serial_platform_data + unum;
+
+ if (uart_ick[unum] == NULL)
+ return;
+
+ serial_write_reg(p, UART_OMAP_MDR1, 0x7);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ efr = serial_read_reg(p, UART_EFR);
+ serial_write_reg(p, UART_EFR, UART_EFR_ECB);
+ serial_write_reg(p, UART_LCR, 0x0); /* Operational mode */
+ serial_write_reg(p, UART_IER, 0x0);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(p, UART_DLL, uart_ctx[unum].dll);
+ serial_write_reg(p, UART_DLM, uart_ctx[unum].dlh);
+ serial_write_reg(p, UART_LCR, 0x0); /* Operational mode */
+ serial_write_reg(p, UART_IER, uart_ctx[unum].ier);
+ serial_write_reg(p, UART_FCR, 0xA1);
+ serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(p, UART_EFR, efr);
+ serial_write_reg(p, UART_LCR, UART_LCR_WLEN8);
+ serial_write_reg(p, UART_OMAP_SCR, uart_ctx[unum].scr);
+ serial_write_reg(p, UART_OMAP_WER, uart_ctx[unum].wer);
+ serial_write_reg(p, UART_OMAP_SYSC, uart_ctx[unum].sysc);
+ serial_write_reg(p, UART_OMAP_MDR1, 0x00); /* UART 16x mode */
+}
+EXPORT_SYMBOL(omap_restore_uart_ctx);
+
static struct platform_device serial_device = {
.name = serial8250,
.id = PLAT8250_DEV_PLATFORM,
Index: linux-omap-2.6/include/linux/serial_reg.h
===
--- linux-omap-2.6.orig/include/linux/serial_reg.h 2008-07-01
10:40:40.758251704 +0530
+++ linux-omap-2.6/include/linux/serial_reg.h 2008-07-01 12:08:11.157338527
+0530
@@ -323,6 +323,7 @@
#define UART_OMAP_MVER 0x14/* Module version register */
#define UART_OMAP_SYSC 0x15/* System configuration register */
#define UART_OMAP_SYSS 0x16/* System status register */
+#define UART_OMAP_WER 0x17/* Wake-up enable register */
#endif /* _LINUX_SERIAL_REG_H */
--
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
Re: [Question] MUSB: why not clear DMA interrupt in musbhsdma.c?
On Tue, Jul 1, 2008 at 8:55 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote: snip Actually, I don't have any detail information about the IP from mentor of Blackfin. I just found the instruction from the Blackfin manual. We need to clear DMA IRQ flag manually on Blackfin, although it is not true on Davinci. But when I tried to write large file to the U-DISK (such as 10Mbyte or 100Mbyte), speed is very slow and mush slower than PIO mode, IMO. I've certainly seen that little problem. I couldn't tell if the root cause was from Mentor's DMA support or from the kind of USB-antagonistic DMA engine on DaVinci, but when the DMA logic has to generate an IRQ for each packet (to get sane semantics), it's hopeless getting good throughput unless it's dirt cheap to set up and complete DMA transfers. (It isn't.) As has been seen elsewhere: when the cost of DMA integration exceeds the cost to stuff the FIFO by hand, DMA is not a win. That's an issue with the drivers/dma framework sometimes too, though in that case the issue is purely software. I did lots of test to compare the DMA and PIO such as a) dd large file to a USB flash disk, b) use bonnie++ to do performance test. The result is that no throughput improvement on DMA and CPU consumption is the same as PIO. We hope to see the CPU usage of DMA mode is less than PIO mode, but didn't got the expectation. Approximately how much is the performance you see with PIO mode (given that you also see the same with DMA mode)? I recorded the bonnie++ result in our tracker: https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=3786 Any chance you have dynamic tick suppression enabled (CONFIG_NO_HZ)? If so, could you try with nohz=off in your bootargs? Is this helpful? I am afraid that dynamic tick is not fully supported on Blackfin. But I will try it. Thanks -Bryan -- 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
TSC2004 touch driver
I'm trying to incorporate a TSC2004 touch driver for my omap3430 board, and before I go off and reinvent the wheel, fiugred I'd ask. Google doesn't come up with anything for a driver on tsc2004. Thanks in advance! -- Peter Barada [EMAIL PROTECTED] -- 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
Re: [PATCH 09/11] gpio context save/restore
On Tue, Jul 01, 2008 at 07:46:34PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_ARCH_OMAP34XX
+/* save the registers of bank 2-6 */
+void omap_gpio_save(void)
+{
+ int i;
+ /* saving banks from 2-6 only */
+ for (i = 1; i gpio_bank_count; i++) {
+ struct gpio_bank *bank = gpio_bank[i];
+ gpio_restore_banks[i].gpio_sysconfig =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SYSCONFIG);
+ gpio_restore_banks[i].gpio_wake_en =
+ __raw_readl(bank-base + OMAP24XX_GPIO_WAKE_EN);
+ gpio_restore_banks[i].gpio_ctrl =
+ __raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
+ gpio_restore_banks[i].gpio_oe =
+ __raw_readl(bank-base + OMAP24XX_GPIO_OE);
+ gpio_restore_banks[i].gpio_leveldetect0 =
+ __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0);
+ gpio_restore_banks[i].gpio_leveldetect1 =
+ __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
+ gpio_restore_banks[i].gpio_risingdetect =
+ __raw_readl(bank-base + OMAP24XX_GPIO_RISINGDETECT);
+ gpio_restore_banks[i].gpio_fallingdetect =
+ __raw_readl(bank-base + OMAP24XX_GPIO_FALLINGDETECT);
+ gpio_restore_banks[i].gpio_dataout =
+ __raw_readl(bank-base + OMAP24XX_GPIO_DATAOUT);
+ gpio_restore_banks[i].gpio_setwkuena =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SETWKUENA);
+ gpio_restore_banks[i].gpio_setdataout =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SETDATAOUT);
+ }
+}
+EXPORT_SYMBOL(omap_gpio_save);
+
+/* restore the required registers of bank 2-6 */
+void omap_gpio_restore(void)
+{
+ int i;
+ for (i = 1; i gpio_bank_count; i++) {
+ struct gpio_bank *bank = gpio_bank[i];
+ __raw_writel(gpio_restore_banks[i].gpio_sysconfig,
+ bank-base + OMAP24XX_GPIO_SYSCONFIG);
+ __raw_writel(gpio_restore_banks[i].gpio_wake_en,
+ bank-base + OMAP24XX_GPIO_WAKE_EN);
+ __raw_writel(gpio_restore_banks[i].gpio_ctrl,
+ bank-base + OMAP24XX_GPIO_CTRL);
+ __raw_writel(gpio_restore_banks[i].gpio_oe,
+ bank-base + OMAP24XX_GPIO_OE);
+ __raw_writel(gpio_restore_banks[i].gpio_leveldetect0,
+ bank-base + OMAP24XX_GPIO_LEVELDETECT0);
+ __raw_writel(gpio_restore_banks[i].gpio_leveldetect1,
+ bank-base + OMAP24XX_GPIO_LEVELDETECT1);
+ __raw_writel(gpio_restore_banks[i].gpio_risingdetect,
+ bank-base + OMAP24XX_GPIO_RISINGDETECT);
+ __raw_writel(gpio_restore_banks[i].gpio_fallingdetect,
+ bank-base + OMAP24XX_GPIO_FALLINGDETECT);
+ __raw_writel(gpio_restore_banks[i].gpio_dataout,
+ bank-base + OMAP24XX_GPIO_DATAOUT);
+ __raw_writel(gpio_restore_banks[i].gpio_setwkuena,
+ bank-base + OMAP24XX_GPIO_SETWKUENA);
+ __raw_writel(gpio_restore_banks[i].gpio_setdataout,
+ bank-base + OMAP24XX_GPIO_SETDATAOUT);
+ }
+}
+EXPORT_SYMBOL(omap_gpio_restore);
#else
inline void omap_gpio_save(void) {}
inline void omap_gpio_restore(void) {}
otherwise ifndef OMAP3 we're gonna get undef reference
or maybe do it in the header, but then use static inline, instead of
inline only.
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http://blog.felipebalbi.com
--
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
Re: [PATCH 01/11] Basic cpuidle driver
On Tue, Jul 01, 2008 at 07:46:07PM +0530, Rajendra Nayak wrote: OMAP3 Basic cpuidle small style comment: change __FUNCTION__ to __func__ to make checkpatch.pl happy ;-) -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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
Re: TSC2004 touch driver
On Tue, 2008-07-01 at 12:56 -0600, Todd Fischer wrote: Peter, We used the TSC2046, which is a next generation ADS7846 chip. We just used the ads7846 driver and it worked fine. The TSC2004 datasheet doesn't make the same compatibility claim however. The ads7846 driver is a place to start. The TSC2004 is I2C, wheras the ADS7846 is SPI. I've found a TSC2003 driver written by Bill Gatliff for 2.4, but was wondering if anyone had a better starting point. Also, any idea where I can find a snap (as in source) of the kernel work-in-progress, or is it all in the git trees? Todd The TSC2004 is a newer version the On Tue, 2008-07-01 at 13:59 -0400, Peter Barada wrote: I'm trying to incorporate a TSC2004 touch driver for my omap3430 board, and before I go off and reinvent the wheel, fiugred I'd ask. Google doesn't come up with anything for a driver on tsc2004. Thanks in advance! -- Peter Barada [EMAIL PROTECTED] -- 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
Re: TSC2004 touch driver
On Tue, Jul 01, 2008 at 05:42:07PM -0400, Peter Barada wrote: The TSC2004 is I2C, wheras the ADS7846 is SPI. I've found a TSC2003 driver written by Bill Gatliff for 2.4, but was wondering if anyone had a better starting point. Also, any idea where I can find a snap (as in source) of the kernel work-in-progress, or is it all in the git trees? there is tsc2005 in linux-omap. look at drivers/input/touchscreen/tsc2005.c if it helps you somehow, it's there :p -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
Hi, It's should be sent to MTD list. and we also fix the NOR similar ways. It's already posted but not committed. Thank you, Kyungmin Park On Tue, Jul 1, 2008 at 11:32 PM, Kamat, Nishant [EMAIL PROTECTED] wrote: From: Nishant Kamat [EMAIL PROTECTED] MTD: OMAP2-NAND: Fix partition reading from board info The parse_mtd_partitions() function no longer returns a negative error in case cmdline is not passed. See commit: b0d06afb607 Signed-off-by: Nishant Kamat [EMAIL PROTECTED] --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-omap-ti.ldp/drivers/mtd/nand/omap2.c === --- linux-omap-ti.ldp.orig/drivers/mtd/nand/omap2.c 2008-06-30 22:01:50.0 +0530 +++ linux-omap-ti.ldp/drivers/mtd/nand/omap2.c 2008-06-30 22:03:34.446471469 +0530 @@ -699,7 +699,7 @@ err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0); if (err 0) add_mtd_partitions(info-mtd, info-parts, err); - else if (err 0 pdata-parts) + else if (pdata-parts) add_mtd_partitions(info-mtd, pdata-parts, pdata-nr_parts); else #endif -- 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 -- 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
