RE: [PATCH] ARM MMU: add strongly-ordered memory type
Hello Catalin, On Wed, 6 Aug 2008, Catalin Marinas wrote: On Tue, 2008-08-05 at 07:15 -0500, Woodruff, Richard wrote: Is the controller allowed to write dirty cache lines out at any time it likes? Surely a better fix is to drain the cache of the changes before changing the clock for the SDRAM? - Previously the SRAM was marked as cached. _Execution_ using that attribute will generate line fetches to SRAM. This will cause displacement write-outs of resident DDR lines. Similarly, _load/store_ sequences in that code have the same effect. This cast outs dead lock the CPU and it can't fetch to progress. [...] * Flushing the entire L1 L2 cache frequently is very expensive and better not done if you don't have. Also, it is not sufficient for the context-restore path which needs to NOT live in DDR. The code need to execute in a non-cached region. I don't think there is any guarantee that dirty cache line won't be evicted to SDRAM even if your code uses uncached memory only. The CPU is allowed to do speculative reads from the normal cached memory and these reads may force a dirty cache line to be written back to memory. You may need to do at least a cache clean operation (invalidate not necessary). If we turn off speculative reads via a CP15 control register Z-bit write for the duration of the SRAM code execution, and use either normal non-cached memory or strongly-ordered memory for the SRAM code, will that effectively prevent any cache line writeback during that time? (assuming interrupts are disabled, that is). Also, a somewhat-related question about strongly-ordered memory regions: these are described as bracketing accesses to those regions with data memory barriers. In this case, are those barriers specific to the strongly-ordered pages, or will they affect all memory transactions, even to normal cached memory? - Paul -- 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] Enable SYSOFFMODE use
On ke, 2008-08-06 at 12:12 -0500, ext Woodruff, Richard wrote: I would say no, we don't need the CONFIG_SYSOFFMODE option. One point is if you try an go to 0v on something under and ES2.1 you will end up with crashes after a while. Some kind of conditional is needed unless we get to drop the non-production chip versions. OK. We can replace the macros with run-time checks. But for ES2.1 suspending to 0V should be safe, right? Before ES2.1 there is a ROM code bug which will trip up the context restore. So ES2.0 is also affected, good to know. Really, it would be good to schedule some time to kill ES1 support. The chip is so different its really just baggage. With cheap and available OMAP3's out there they are really not viable. I've got ES2.0, so no objections from me. Anyone want to confess still using ES1.0? Tony, what do you think? As to C state, I'm not sure, just yet. If we end up with too many of them there is some overhead in determining thresholds, then trying to tweak a governor to choose them smartly? It's a little while before this code get to that point, but the process seem to be a bit time consuming on internal. OK, so I think we go with the user selectable sysoff_while_idle sysfs interface and not mess up the C-states. I see Rajendra posted a refreshed set of patches, so maybe we'll have the C-states in mainline soon. regards, Kalle 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 -- 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 MMU: add strongly-ordered memory type
On Wed, Aug 06, 2008 at 07:21:14AM -0500, Woodruff, Richard wrote: Most of the weak memory attributes in newer ARMs are not exploited today in tree. I'll guess this was more a correctness and capability judgment from Russell. Not entirely true. We do as much as is safe to do - which is basically using 'device' mappings for devices and ioremap, and 'memory' mappings for the main memory, module and vmalloc mappings. What we don't do is mark DMA memory ask being normal uncached memory, thereby allowing that to be reordered with device accesses - we make it strongly ordered. The reason being that the kernel doesn't have barriers necessary to ensure that writes to DMA memory hit physical memory before the device access to enable DMA hits the DMA controller. Those kinds of bugs can be absolute hell to track down - think about a DMA controller accessing an uninitialised DMA descriptor, resulting in it scribbing over random bits of memory. The only real way to do this is to audit lots of drivers to ensure that: 1. DMA is not started until accesses to memory allocated by dma_alloc_coherent() have hit memory 2. accesses to dma_alloc_coherent() memory always read current data, even if the DMA controller has just updated the descriptor you're reading. Linux presently - and quite rightly - assumes that accesses to DMA coherent memory _are_ coherent with DMA. If not, the API would be a joke. -- 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 0/4] Refreshed Workaround patches from Jouni
On ke, 2008-08-06 at 18:30 +0530, ext Rajendra Nayak wrote: Hi, I am posting a set of 4 workaround patches from Jouni, refreshed against the latest l-o tree. These are yet to be pushed to mailine and are needed for the refreshed CPUidle patches to work, which I would post following this set. I had some trouble applying these, so I'll send one more refreshment set that should apply cleanly over l-o master branch. regards, Kalle 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 -- 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/4] 34XX: PM: Workaround to check wether any fck is active before entering sleep
From: ext Rajendra Nayak [EMAIL PROTECTED]
This workaround shouldn't be needed when all drivers are configuring
their sysconfig registers properly and using their clocks properly.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc72c11..bca1994 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -174,10 +174,41 @@ static void omap_sram_idle(void)
omap2_gpio_resume_after_retention();
}
+static int omap3_fclks_active(void)
+{
+ u32 fck_core1 = 0, fck_core3 = 0, fck_sgx = 0, fck_dss = 0,
+ fck_cam = 0, fck_per = 0, fck_usbhost = 0;
+
+ fck_core1 = cm_read_mod_reg(CORE_MOD,
+ CM_FCLKEN1);
+ if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
+ fck_core3 = cm_read_mod_reg(CORE_MOD,
+ OMAP3430ES2_CM_FCLKEN3);
+ fck_sgx = cm_read_mod_reg(OMAP3430ES2_SGX_MOD,
+ CM_FCLKEN);
+ fck_usbhost = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,
+ CM_FCLKEN);
+ } else
+ fck_sgx = cm_read_mod_reg(GFX_MOD,
+ OMAP3430ES2_CM_FCLKEN3);
+ fck_dss = cm_read_mod_reg(OMAP3430_DSS_MOD,
+ CM_FCLKEN);
+ fck_cam = cm_read_mod_reg(OMAP3430_CAM_MOD,
+ CM_FCLKEN);
+ fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
+ CM_FCLKEN);
+ if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
+ fck_cam | fck_per | fck_usbhost)
+ return 1;
+ return 0;
+}
+
static int omap3_can_sleep(void)
{
if (!enable_dyn_sleep)
return 0;
+ if (omap3_fclks_active())
+ return 0;
if (atomic_read(sleep_block) 0)
return 0;
return 1;
--
1.5.4.3
--
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 2/4] 34XX: PM: Workaround for taking care of gpio clocks
From: ext Rajendra Nayak [EMAIL PROTECTED]
In omap3 gpios 2-6 are in per domain. Functional clocks for these
should be disabled. This patch is needed until gpio driver disables
gpio clocks.
GPIO modules in PER domain are not able to act as a wake up source if
PER domain is in retention. PER domain sleep transition before MPU is
prevented by leaving icks active. PER domain still enters retention
together with MPU. When this happens IOPAD wake up mechanism is used
for gpios.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 58 +++--
1 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bca1994..4b6d645 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -47,12 +47,42 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+void (*_omap_sram_idle)(u32 *addr, int save_state, int disable_clocks);
static void (*saved_idle)(void);
static struct powerdomain *mpu_pwrdm;
+/* XXX This is for gpio fclk hack. Will be removed as gpio driver
+ * handles fcks correctly */
+#define NUM_OF_PERGPIOS 5
+static struct clk *gpio_fcks[NUM_OF_PERGPIOS];
+
+/* XXX This is for gpio fclk hack. Will be removed as gpio driver
+ * handles fcks correctly */
+static void per_gpio_clk_enable(void)
+{
+ int i;
+ for (i = 1; i NUM_OF_PERGPIOS + 1; i++)
+ clk_enable(gpio_fcks[i-1]);
+}
+
+/* XXX This is for gpio fclk hack. Will be removed as gpio driver
+ * handles fcks correctly */
+static void per_gpio_clk_disable(void)
+{
+ int i;
+ for (i = 1; i NUM_OF_PERGPIOS + 1; i++)
+ clk_disable(gpio_fcks[i-1]);
+}
+
+/* XXX This is for gpio fclk hack. Will be removed as gpio driver
+ * handles fcks correctly */
+static void gpio_fclk_mask(u32 *fclk)
+{
+ *fclk = ~(0x1f 13);
+}
+
/* PRCM Interrupt Handler for wakeups */
static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
{
@@ -169,7 +199,17 @@ static void omap_sram_idle(void)
omap2_gpio_prepare_for_retention();
- _omap_sram_idle(NULL, save_state);
+ /* XXX This is for gpio fclk hack. Will be removed as gpio driver
+* handles fcks correctly */
+ if (clocks_off_while_idle)
+ per_gpio_clk_disable();
+
+ _omap_sram_idle(NULL, save_state, clocks_off_while_idle);
+
+ /* XXX This is for gpio fclk hack. Will be removed as gpio driver
+* handles fcks correctly */
+ if (clocks_off_while_idle)
+ per_gpio_clk_enable();
omap2_gpio_resume_after_retention();
}
@@ -197,6 +237,10 @@ static int omap3_fclks_active(void)
CM_FCLKEN);
fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
CM_FCLKEN);
+
+ if (clocks_off_while_idle)
+ gpio_fclk_mask(fck_per);
+
if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
fck_cam | fck_per | fck_usbhost)
return 1;
@@ -412,7 +456,8 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm)
int __init omap3_pm_init(void)
{
struct power_state *pwrst;
- int ret;
+ char clk_name[11];
+ int ret, i;
printk(KERN_ERR Power Management for TI OMAP3.\n);
@@ -448,6 +493,13 @@ int __init omap3_pm_init(void)
pm_idle = omap3_pm_idle;
+ /* XXX This is for gpio fclk hack. Will be removed as gpio driver
+* handles fcks correctly */
+ for (i = 1; i NUM_OF_PERGPIOS + 1; i++) {
+ sprintf(clk_name, gpio%d_fck, i + 1);
+ gpio_fcks[i-1] = clk_get(NULL, clk_name);
+ }
+
err1:
return ret;
err2:
--
1.5.4.3
--
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 3/4] Added sleep support to UART
From: Tero Kristo [EMAIL PROTECTED]
UART usage (e.g. serial console) now denies sleep for 5 seconds. This
makes it possible to use serial console when dynamic idle is
enabled. Write 1 to /sys/power/clocks_off_while_sleep to enable uart
clock disable on idle. Without this omap won't enter retention.
Also moved code from pm-debug.c to serial.c, and made pm24xx.c use
this new implementation.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm-debug.c | 132
arch/arm/mach-omap2/pm.h |8 --
arch/arm/mach-omap2/pm24xx.c | 57 --
arch/arm/mach-omap2/pm34xx.c | 26 +--
arch/arm/mach-omap2/serial.c | 148
include/asm-arm/arch-omap/common.h |3 +
6 files changed, 204 insertions(+), 170 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index a32f11f..61d4501 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -37,138 +37,6 @@
#ifdef CONFIG_PM_DEBUG
int omap2_pm_debug = 0;
-static int serial_console_clock_disabled;
-static int serial_console_uart;
-static unsigned int serial_console_next_disable;
-
-static struct clk *console_iclk, *console_fclk;
-
-static void serial_console_kick(void)
-{
- serial_console_next_disable = omap2_read_32k_sync_counter();
- /* Keep the clocks on for 4 secs */
- serial_console_next_disable += 4 * 32768;
-}
-
-static void serial_wait_tx(void)
-{
- static const unsigned long uart_bases[3] = {
- 0x4806a000, 0x4806c000, 0x4806e000
- };
- unsigned long lsr_reg;
- int looped = 0;
-
- /* Wait for TX FIFO and THR to get empty */
- lsr_reg = IO_ADDRESS(uart_bases[serial_console_uart - 1] + (5 2));
- while ((__raw_readb(lsr_reg) 0x60) != 0x60)
- looped = 1;
- if (looped)
- serial_console_kick();
-}
-
-u32 omap2_read_32k_sync_counter(void)
-{
-return omap_readl(OMAP2_32KSYNCT_BASE + 0x0010);
-}
-
-void serial_console_fclk_mask(u32 *f1, u32 *f2)
-{
- switch (serial_console_uart) {
- case 1:
- *f1 = ~(1 21);
- break;
- case 2:
- *f1 = ~(1 22);
- break;
- case 3:
- *f2 = ~(1 2);
- break;
- }
-}
-
-void serial_console_sleep(int enable)
-{
- if (console_iclk == NULL || console_fclk == NULL)
- return;
-
- if (enable) {
- BUG_ON(serial_console_clock_disabled);
- if (clk_get_usecount(console_fclk) == 0)
- return;
- if ((int) serial_console_next_disable - (int)
omap2_read_32k_sync_counter() = 0)
- return;
- serial_wait_tx();
- clk_disable(console_iclk);
- clk_disable(console_fclk);
- serial_console_clock_disabled = 1;
- } else {
- int serial_wakeup = 0;
- u32 l;
-
- switch (serial_console_uart) {
- case 1:
- l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (l OMAP24XX_ST_UART1)
- serial_wakeup = 1;
- break;
- case 2:
- l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (l OMAP24XX_ST_UART2)
- serial_wakeup = 1;
- break;
- case 3:
- l = prm_read_mod_reg(CORE_MOD, OMAP24XX_PM_WKST2);
- if (l OMAP24XX_ST_UART3)
- serial_wakeup = 1;
- break;
- }
- if (serial_wakeup)
- serial_console_kick();
- if (!serial_console_clock_disabled)
- return;
- clk_enable(console_iclk);
- clk_enable(console_fclk);
- serial_console_clock_disabled = 0;
- }
-}
-
-void pm_init_serial_console(void)
-{
- const struct omap_serial_console_config *conf;
- char name[16];
-
- conf = omap_get_config(OMAP_TAG_SERIAL_CONSOLE,
- struct omap_serial_console_config);
- if (conf == NULL)
- return;
- if (conf-console_uart 3 || conf-console_uart 1)
- return;
- serial_console_uart = conf-console_uart;
- sprintf(name, uart%d_fck, conf-console_uart);
- console_fclk = clk_get(NULL, name);
- if (IS_ERR(console_fclk))
- console_fclk = NULL;
- name[6] = 'i';
- console_iclk = clk_get(NULL, name);
- if (IS_ERR(console_fclk))
- console_iclk = NULL;
- if (console_fclk == NULL || console_iclk == NULL) {
- serial_console_uart = 0;
- return;
-
[PATCH 4/4] 34XX: PM: Workaround to enable autoidle for clocks
From: ext Rajendra Nayak [EMAIL PROTECTED] This workaround enables autoidle for interface clocks and plls. Also automatic control of external oscillator through sys_clkreq is enabled. Proper fix to this is to generalize omap3_dpll_allow_idle, omap3_dpll_deny_idle, omap3_dpll_autoidle_read and call it for each clock on init. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] --- arch/arm/mach-omap2/pm34xx.c | 118 ++ 1 files changed, 118 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 63c50b4..a7b2af0 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -433,6 +433,124 @@ static void __init prcm_setup_regs(void) } else prm_write_mod_reg(0, GFX_MOD, PM_WKDEP); + /* XXX Enable interface clock autoidle for all modules. This +* should be done by clockfw */ + cm_write_mod_reg( + OMAP3430ES2_AUTO_MMC3 | + OMAP3430ES2_AUTO_ICR | + OMAP3430_AUTO_AES2 | + OMAP3430_AUTO_SHA12 | + OMAP3430_AUTO_DES2 | + OMAP3430_AUTO_MMC2 | + OMAP3430_AUTO_MMC1 | + OMAP3430_AUTO_MSPRO | + OMAP3430_AUTO_HDQ | + OMAP3430_AUTO_MCSPI4 | + OMAP3430_AUTO_MCSPI3 | + OMAP3430_AUTO_MCSPI2 | + OMAP3430_AUTO_MCSPI1 | + OMAP3430_AUTO_I2C3 | + OMAP3430_AUTO_I2C2 | + OMAP3430_AUTO_I2C1 | + OMAP3430_AUTO_UART2 | + OMAP3430_AUTO_UART1 | + OMAP3430_AUTO_GPT11 | + OMAP3430_AUTO_GPT10 | + OMAP3430_AUTO_MCBSP5 | + OMAP3430_AUTO_MCBSP1 | + OMAP3430ES1_AUTO_FAC | /* This is es1 only */ + OMAP3430_AUTO_MAILBOXES | + OMAP3430_AUTO_OMAPCTRL | + OMAP3430ES1_AUTO_FSHOSTUSB | + OMAP3430_AUTO_HSOTGUSB | + OMAP3430ES1_AUTO_D2D | /* This is es1 only */ + OMAP3430_AUTO_SSI, + CORE_MOD, CM_AUTOIDLE1); + + cm_write_mod_reg( + OMAP3430_AUTO_PKA | + OMAP3430_AUTO_AES1 | + OMAP3430_AUTO_RNG | + OMAP3430_AUTO_SHA11 | + OMAP3430_AUTO_DES1, + CORE_MOD, CM_AUTOIDLE2); + + if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) + cm_write_mod_reg( + OMAP3430ES2_AUTO_USBTLL, + CORE_MOD, CM_AUTOIDLE3); + + cm_write_mod_reg( + OMAP3430_AUTO_WDT2 | + OMAP3430_AUTO_WDT1 | + OMAP3430_AUTO_GPIO1 | + OMAP3430_AUTO_32KSYNC | + OMAP3430_AUTO_GPT12 | + OMAP3430_AUTO_GPT1 , + WKUP_MOD, CM_AUTOIDLE); + + cm_write_mod_reg( + OMAP3430_AUTO_DSS, + OMAP3430_DSS_MOD, + CM_AUTOIDLE); + + cm_write_mod_reg( + OMAP3430_AUTO_CAM, + OMAP3430_CAM_MOD, + CM_AUTOIDLE); + + cm_write_mod_reg( + OMAP3430_AUTO_GPIO6 | + OMAP3430_AUTO_GPIO5 | + OMAP3430_AUTO_GPIO4 | + OMAP3430_AUTO_GPIO3 | + OMAP3430_AUTO_GPIO2 | + OMAP3430_AUTO_WDT3 | + OMAP3430_AUTO_UART3 | + OMAP3430_AUTO_GPT9 | + OMAP3430_AUTO_GPT8 | + OMAP3430_AUTO_GPT7 | + OMAP3430_AUTO_GPT6 | + OMAP3430_AUTO_GPT5 | + OMAP3430_AUTO_GPT4 | + OMAP3430_AUTO_GPT3 | + OMAP3430_AUTO_GPT2 | + OMAP3430_AUTO_MCBSP4 | + OMAP3430_AUTO_MCBSP3 | + OMAP3430_AUTO_MCBSP2, + OMAP3430_PER_MOD, + CM_AUTOIDLE); + + if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) + cm_write_mod_reg( + OMAP3430ES2_AUTO_USBHOST, + OMAP3430ES2_USBHOST_MOD, + CM_AUTOIDLE); + + /* XXX Set all plls to autoidle. This is needed until autoidle is +* enabled by clockfw */ + cm_write_mod_reg(1 OMAP3430_CLKTRCTRL_IVA2_SHIFT, +OMAP3430_IVA2_MOD, +CM_AUTOIDLE2); + cm_write_mod_reg(1 OMAP3430_AUTO_MPU_DPLL_SHIFT, +MPU_MOD, +CM_AUTOIDLE2); + cm_write_mod_reg((1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT) | +(1 OMAP3430_AUTO_CORE_DPLL_SHIFT), +PLL_MOD, +CM_AUTOIDLE); + cm_write_mod_reg(1 OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT, +PLL_MOD, +CM_AUTOIDLE2); + + /* XXX Enable control of expternal oscillator through +* sys_clkreq. I think clockfw should provide
RE: how to use omap 2430 character led
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vishal bhoj Sent: Wednesday, August 06, 2008 6:59 PM To: linux-omap@vger.kernel.org Subject: Fwd: how to use omap 2430 character led CAn anyone tell me howto use the character lcd display on omap 2430 board. i want to test it and use it at assembly level I think you are definitely NOT referring to Secondary LCD. i am writing it in the memory locations but im not getting any output. do we have to do any initializations to run this code on the board ? like mux config ? im creating a bin image and trying to run it in the ram directly. do i have to initialisze the pad ? i dono much, im a newbie to omaps For Character LCD, I think you can refer to the code snippet in u-boot that displays the boot mode NAND/NOR etc on character LCD. Following the exact code base should help you in getting characters displayed on the LCD. Download u-boot for 2430 SDP from here In file u-boot/board/omap2430sdp/sys_info.c Refer to function: display_board_info(u32 btype) Regards, Khasim http://khasim.blogspot.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] Load triton2 scripts.
Hi Tony, This patch should be safe to apply now as the sys off mode pin polarity was fixed in the patch Add early init for voltage controller configuration and off mode polarity (index a6cfc46..fc72c11 100644). I compile boot tested it on SDP board, on both plain master branch and with Jouni's workarounds. Works for me. regards, Kalle On ma, 2008-07-21 at 19:17 +0300, ext Peter 'p2' De Schrijver wrote: Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- drivers/i2c/chips/Makefile|2 +- drivers/i2c/chips/twl4030-power.c | 337 + 2 files changed, 338 insertions(+), 1 deletions(-) create mode 100644 drivers/i2c/chips/twl4030-power.c diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index 1f81ebd..a44e617 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -23,7 +23,7 @@ obj-$(CONFIG_GPIOEXPANDER_OMAP) += gpio_expander_omap.o obj-$(CONFIG_MENELAUS) += menelaus.o obj-$(CONFIG_SENSORS_TSL2550)+= tsl2550.o obj-$(CONFIG_SENSORS_TSL2563)+= tsl2563.o -obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-pwrirq.o +obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-pwrirq.o twl4030-power.o obj-$(CONFIG_TWL4030_GPIO) += twl4030-gpio.o obj-$(CONFIG_TWL4030_USB)+= twl4030-usb.o obj-$(CONFIG_TWL4030_POWEROFF) += twl4030-poweroff.o diff --git a/drivers/i2c/chips/twl4030-power.c b/drivers/i2c/chips/twl4030-power.c new file mode 100644 index 000..195c3c4 --- /dev/null +++ b/drivers/i2c/chips/twl4030-power.c @@ -0,0 +1,337 @@ +/* + * linux/drivers/i2c/chips/twl4030-power.c + * + * Handle TWL4030 Power initialization + * + * Copyright (C) 2008 Nokia Corporation + * Copyright (C) 2006 Texas Instruments, Inc + * + * Written byKalle Jokiniemi + * Peter De Schrijver [EMAIL PROTECTED] + * + * This file is subject to the terms and conditions of the GNU General + * Public License. See the file COPYING in the main directory of this + * archive for more details. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include linux/module.h +#include linux/pm.h +#include linux/i2c/twl4030.h + +#define PWR_P1_SW_EVENTS 0x10 +#define PWR_DEVOFF (10) + +#define PHY_TO_OFF_PM_MASTER(p) (p - 0x36) +#define PHY_TO_OFF_PM_RECIEVER(p)(p - 0x5b) + +/* resource - hfclk */ +#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECIEVER(0xe6) + +/* PM events */ +#define R_P1_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x46) +#define R_P2_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x47) +#define R_P3_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x48) +#define R_CFG_P1_TRANSITION PHY_TO_OFF_PM_MASTER(0x36) +#define R_CFG_P2_TRANSITION PHY_TO_OFF_PM_MASTER(0x37) +#define R_CFG_P3_TRANSITION PHY_TO_OFF_PM_MASTER(0x38) + +#define LVL_WAKEUP 0x08 + +#define ENABLE_WARMRESET (14) + +/* sequence script */ + +#define END_OF_SCRIPT0x3f + +#define R_SEQ_ADD_A2SPHY_TO_OFF_PM_MASTER(0x55) +#define R_SEQ_ADD_SA12 PHY_TO_OFF_PM_MASTER(0x56) +#define R_SEQ_ADD_S2A3 PHY_TO_OFF_PM_MASTER(0x57) +#define R_SEQ_ADD_WARM PHY_TO_OFF_PM_MASTER(0x58) +#define R_MEMORY_ADDRESS PHY_TO_OFF_PM_MASTER(0x59) +#define R_MEMORY_DATAPHY_TO_OFF_PM_MASTER(0x5a) + +/* Power bus message definitions */ + +#define DEV_GRP_NULL 0x0 +#define DEV_GRP_P1 0x1 +#define DEV_GRP_P2 0x2 +#define DEV_GRP_P3 0x4 + +#define RES_GRP_RES 0x0 +#define RES_GRP_PP 0x1 +#define RES_GRP_RC 0x2 +#define RES_GRP_PP_RC0x3 +#define RES_GRP_PR 0x4 +#define RES_GRP_PP_PR0x5 +#define RES_GRP_RC_PR0x6 +#define RES_GRP_ALL 0x7 + +#define RES_TYPE2_R0 0x0 + +#define RES_TYPE_ALL 0x7 + +#define RES_STATE_WRST 0xF +#define RES_STATE_ACTIVE 0xE +#define RES_STATE_SLEEP 0x8 +#define RES_STATE_OFF0x0 + +/* +*Power Bus Message Format +* +*Broadcast Message (16 Bits) +*DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4] +*RES_STATE[3:0] +* +*Singular Message (16 Bits) +*DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0] +* +*/ + +#define MSG_BROADCAST(devgrp, grp, type, type2, state) \ + (devgrp 13 | 1 12 | grp 9 | type2 7 | type 4 |
Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
On ke, 2008-08-06 at 18:42 +0530, ext Rajendra Nayak wrote: Hi, Re-posting a refreshed version of these patches. I'm getting this error when trying to apply these patches with 'git-am' command: $ git-am ~/.evolution/mail/local/stage Applying Basic cpuidle driver fatal: patch fragment without header at line 13: @@ -0,0 +1,245 @@ Patch failed at 0001. with manual patch -p 1 .dotest/0001 they apply nicely, but it is very time-consuming to do it manually for each patch. Do you use normal git-format-patch and git-send-email to format and post the patches? Br, Kalle regards Rajendra Hi, I am sending an updated patch set for CPUidle which includes all fixes/comments posted on the previous set by Jouni/Richard W/Peter and others. The Following are the fixes 1) Uart clock enable/disable moved out of the context save/restore patch 2) GPIO IRQENABLE save/restore fix from Richard 3) Fixes from Jouni which do the following 1. Add wkdep between neon and mpu 2. Add wkdep between per and core 3. Deny hwsup mode before writing next pwrst state 4. Make sure that order in idle loop is such that clocks are _really_ enabled before accessing registers (serial gpio). 4) Safe state idle fix from Richard 5) Uart smart-force fix from Richard 6) Toggle IO-PAD enable/disable in idle As earlier these patches apply on top of Jouni's workaround patch set ([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 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 -- 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: About to tag v2.6.26-omap1, patch queue deleted, please check and repost
* David Brownell [EMAIL PROTECTED] [080807 02:30]: On Tuesday 05 August 2008, Tony Lindgren wrote: Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Two problems on the OSK5912: - cpufreq oopses on boot - continuous i2c overflow errors ISTR both of these bugs are in mainline too. I'd say the I2C regression is higher priority. Hmm, I wonder what has broken I2C? Anyways, let's fix these regressions before tagging. Tony - Dave CPUFREQ oopsing 5Linux version 2.6.26-omap1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #186 PREEMPT Wed Aug 6 16:12:29 PDT 2008 CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 Machine: TI-OSK Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 8192 7 DMA zone: 64 pages used for memmap 7 DMA zone: 0 pages reserved 7 DMA zone: 8128 pages, LIFO batch:0 7 Normal zone: 0 pages used for memmap 7 Movable zone: 0 pages used for memmap OMAP1611b revision 2 handled as 16xx id: 26058c80eb051c15 6SRAM: Mapped pa 0x2000 to va 0xd700 size: 0x10 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 5Kernel command line: console=ttyS0,115200 mem=32M ip=dhcp root=/dev/nfs i2c_omap.clock=400 3Unknown boot option `i2c_omap.clock=400': ignoring Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000 6Clocking rate (xtal/DPLL1/MPU): 12.0/192.0/192.0 MHz Total of 128 interrupts in 4 interrupt banks 6OMAP GPIO hardware version 1.0 4MUX: initialized M7_1610_GPIO62 PID hash table entries: 128 (order: 7, 512 bytes) Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1920 bytes 6Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) 6Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) 6Memory: 32MB = 32MB total 5Memory: 26936KB available (2476K code, 2919K data, 104K init) 6SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 7Calibrating delay loop... 94.82 BogoMIPS (lpj=474112) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 6net_namespace: 256 bytes 6NET: Registered protocol family 16 4MUX: initialized M19_1610_CAM_RSTZ 4MUX: initialized Y15_1610_CAM_OUTCLK 4MUX: initialized H19_1610_CAM_EXCLK 4MUX: initialized W13_1610_CCP_CLKM 4MUX: initialized Y12_1610_CCP_CLKP 4MUX: initialized W14_1610_CCP_DATAP 4MUX: initialized N20_1610_GPIO11 4MUX: initialized P20_1610_GPIO4 4MUX: initialized PWL 6OMAP DMA hardware version 1 6DMA capabilities: 000c::01ff:003f:007f 6omap_dsp_init() done 1Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 1[] *pgd= Internal error: Oops: 5 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (2.6.26-omap1 #186) PC is at wq_per_cpu+0xc/0x14 LR is at queue_delayed_work_on+0x90/0x124 pc : [c005068c]lr : [c00510f0]psr: 6013 sp : c1c21dbc ip : c1c21dcc fp : c1c21dc8 r10: 0292 r9 : 0001 r8 : r7 : r6 : c0561c20 r5 : r4 : c0561c04 r3 : 0001 r2 : r1 : r0 : Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 10004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc1c20260) Stack: (0xc1c21dbc to 0xc1c22000) 1da0:c1c21df0 1dc0: c1c21dcc c00510f0 c0050690 c0561be0 0292 c02aa654 c0561be0 c1c38840 1de0: c1c21e1c c1c21df4 c0175358 c0051070 c1c38840 1e00: 0001 c001c818 c1c21e38 c1c21e20 c0172e00 c017514c 1e20: c1c21e5c c1c38840 c1c21e58 c1c21e3c c0173454 c0172d30 c02980f0 1e40: c1c38840 c0561ad0 c1c21f28 c1c21e5c c0174428 c0173348 0001 1e60: 0002ee00 5dc0 00989680 0002ee00 0002ee00 1e80: 0002ee00 c02aa654 c1c38874 c1c38874 c0173dd4 c0561bb0 1ea0: c02704f9 5dc0 0002ee00 1ec0: 1ee0: 0001 dead4ead c02d1f40 c02592d4 c1c388e0 1f00: c1c388e0 c02aa3d0 c02a7680 c02af8c0 c02af8c8 c1c21f54 1f20: c1c21f2c c0137920 c0174204 c1c04098 c02af8c0
Re: About to tag v2.6.26-omap1, patch queue deleted, please checkand repost
Hi, first - print is misleading, it should be i2c tarnsmit underflow. I2C transmit underflow is because of interrupt handler error. There was a patch to correct nack error ( ack for devices which are not present) which also removed some continue statement. now a race condition arises where even xdr and xudf is simultaneously generated. even if xdr is handled print goes to xudf and we get the print and hence error in return. so it might happen that ur data is transferred but u get error in return. i will send a patch by tomorrow to fix this Regards Chandra Shekhar - Original Message - From: Tony Lindgren [EMAIL PROTECTED] To: David Brownell [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Sent: Thursday, August 07, 2008 4:27 PM Subject: Re: About to tag v2.6.26-omap1, patch queue deleted, please checkand repost * David Brownell [EMAIL PROTECTED] [080807 02:30]: On Tuesday 05 August 2008, Tony Lindgren wrote: Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Two problems on the OSK5912: - cpufreq oopses on boot - continuous i2c overflow errors ISTR both of these bugs are in mainline too. I'd say the I2C regression is higher priority. Hmm, I wonder what has broken I2C? Anyways, let's fix these regressions before tagging. Tony - Dave CPUFREQ oopsing 5Linux version 2.6.26-omap1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #186 PREEMPT Wed Aug 6 16:12:29 PDT 2008 CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 Machine: TI-OSK Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 8192 7 DMA zone: 64 pages used for memmap 7 DMA zone: 0 pages reserved 7 DMA zone: 8128 pages, LIFO batch:0 7 Normal zone: 0 pages used for memmap 7 Movable zone: 0 pages used for memmap OMAP1611b revision 2 handled as 16xx id: 26058c80eb051c15 6SRAM: Mapped pa 0x2000 to va 0xd700 size: 0x10 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 5Kernel command line: console=ttyS0,115200 mem=32M ip=dhcp root=/dev/nfs i2c_omap.clock=400 3Unknown boot option `i2c_omap.clock=400': ignoring Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000 6Clocking rate (xtal/DPLL1/MPU): 12.0/192.0/192.0 MHz Total of 128 interrupts in 4 interrupt banks 6OMAP GPIO hardware version 1.0 4MUX: initialized M7_1610_GPIO62 PID hash table entries: 128 (order: 7, 512 bytes) Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1920 bytes 6Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) 6Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) 6Memory: 32MB = 32MB total 5Memory: 26936KB available (2476K code, 2919K data, 104K init) 6SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 7Calibrating delay loop... 94.82 BogoMIPS (lpj=474112) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 6net_namespace: 256 bytes 6NET: Registered protocol family 16 4MUX: initialized M19_1610_CAM_RSTZ 4MUX: initialized Y15_1610_CAM_OUTCLK 4MUX: initialized H19_1610_CAM_EXCLK 4MUX: initialized W13_1610_CCP_CLKM 4MUX: initialized Y12_1610_CCP_CLKP 4MUX: initialized W14_1610_CCP_DATAP 4MUX: initialized N20_1610_GPIO11 4MUX: initialized P20_1610_GPIO4 4MUX: initialized PWL 6OMAP DMA hardware version 1 6DMA capabilities: 000c::01ff:003f:007f 6omap_dsp_init() done 1Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 1[] *pgd= Internal error: Oops: 5 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (2.6.26-omap1 #186) PC is at wq_per_cpu+0xc/0x14 LR is at queue_delayed_work_on+0x90/0x124 pc : [c005068c]lr : [c00510f0]psr: 6013 sp : c1c21dbc ip : c1c21dcc fp : c1c21dc8 r10: 0292 r9 : 0001 r8 : r7 : r6 : c0561c20 r5 : r4 : c0561c04 r3 : 0001 r2 : r1 : r0 : Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 10004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc1c20260) Stack: (0xc1c21dbc to 0xc1c22000) 1da0: c1c21df0 1dc0: c1c21dcc c00510f0 c0050690 c0561be0 0292 c02aa654 c0561be0 c1c38840 1de0: c1c21e1c c1c21df4 c0175358 c0051070 c1c38840 1e00: 0001 c001c818 c1c21e38 c1c21e20 c0172e00 c017514c 1e20:
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Thu, 2008-08-07 at 08:30 +0100, Russell King - ARM Linux wrote: What we don't do is mark DMA memory ask being normal uncached memory, thereby allowing that to be reordered with device accesses - we make it strongly ordered. The reason being that the kernel doesn't have barriers necessary to ensure that writes to DMA memory hit physical memory before the device access to enable DMA hits the DMA controller. We have mb() and related which provides the ordering (there is also mmiowb() but my understanding is that we don't need this on ARM). http://lwn.net/Articles/283776/ Those kinds of bugs can be absolute hell to track down - think about a DMA controller accessing an uninitialised DMA descriptor, resulting in it scribbing over random bits of memory. Yes, indeed, but ARM is not the only architecture with a weak memory ordering model so drivers should be fixed, in theory. Linux presently - and quite rightly - assumes that accesses to DMA coherent memory _are_ coherent with DMA. If not, the API would be a joke. As I understand it, the DMA mapping doesn't guarantee any ordering, drivers must use barriers. According to Documentation/DMA-mapping.txt: - Consistent DMA mappings which are usually mapped at driver initialization, unmapped at the end and for which the hardware should guarantee that the device and the CPU can access the data in parallel and will see updates made by each other without any explicit software flushing. [...] IMPORTANT: Consistent DMA memory does not preclude the usage of proper memory barriers. The CPU may reorder stores to consistent memory just as it may normal memory. -- Catalin -- 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
[RFC] Patch for proper Cortex-A8 cache configuration output
Recent ARM kernel doesn't detect and output Cortex-A8 cache configuration correctly. Result is something like this in kernel's boot messages: -- cut -- ... CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f ... CPU0: D VIPT write-through cache CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets ... -- cut -- Catalin sent a patch for this to linux-arm-kernel list: http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html Result: -- cut -- ... CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3 CPU0: Level 1 cache is separate instruction and data CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, supports RA CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, supports RA WB WT CPU0: Level 2 cache is unified CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 sets, supports WA RA WB WT ... -- cut -- Some people really like this and this patch is used in some private trees, e.g. for BeagleBoard. Unfortunately, RMK doesn't like the patch. He prefers to completely remove 'broken' configuration output completely. What's about applying this patch locally to OMAP git until upstream ARM kernel has a fix/remove solution for this? Many thanks Dirk -- 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
HS USB errors on OMAP3530
Greetings, I've got a OMAP3530 based board on which I'm having some trouble with HS USB transfers. I plug in a HS USB Flash drive and it is properly detected. I can mount the drive and write any amount of data to it without any problems. However, when I start reading from the drive, the action halts at some random point with the USB driver indicating that it got less data than it requested in it's transaction. Once this failure occurs, the port gets reset and the inserted Flash drive is detected again but none of the descriptors can be retrieved to actually configure/enumerate the device. After a few more reset cycles the process just halts. The console messages are the following.. --- Console Messages --- 7usb-storage: waiting for device to settle before scanning scsi 0:0:0:0: Direct-Access USB DISK 2.0 PMAP PQ: 0 ANSI: 0 CCS sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] 964608 512-byte hardware sectors (494 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: USB disconnect, address 2 sd 0:0:0:0: Device offlined - not ready after error recovery Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 775288 end_request: I/O error, dev sda, sector 775288 Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 775528 end_request: I/O error, dev sda, sector 775528 usb 1-2: new high speed USB device using ehci-omap and address 3 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new high speed USB device using ehci-omap and address 4 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new high speed USB device using ehci-omap and address 5 usb 1-2: device not accepting address 5, error -110 usb 1-2: new high speed USB device using ehci-omap and address 6 usb 1-2: device not accepting address 6, error -110 hub 1-0:1.0: unable to enumerate USB device on port 2 --- End Messages -- Why the writes succeed without any issues while the reads fail has me completely stumped. I'm currently using The Linux Kernel version 2.6.24.7 from omapzoom.org with the /drivers/usb code from the latest 2.6.26 back-ported. Attempting to jump to the newest Kernel would require some work to get my board-specific code all happy and I'm in the process of doing that.. I would love to hear from ideas on what might be going on and what I should be looking at to get this resolved. Regards ~ Ashwin -- 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 MMU: add strongly-ordered memory type
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Most of the weak memory attributes in newer ARMs are not exploited today in tree. I'll guess this was more a correctness and capability judgment from Russell. Not entirely true. We do as much as is safe to do - which is basically using 'device' mappings for devices and ioremap, and 'memory' mappings for the main memory, module and vmalloc mappings. Is DEVICE really safe for things other than FIFOs with out the use of barriers? Accesses are in order but they can be buffered. The bus is free to post/buffer these writes as long as it preserves the order (and it does). I want to know the write happened before moving on in some code. Yes some barrier can be added to the code to fix it but its not there in most drivers today. I recall you gave an explanation on list a while back where MPCORE had to use DEVICE or it wouldn't work. That restriction is not there for others. We do in some drivers today get spurious interrupts when DEVICE is used but don't see them when using SO. Originally the IC-Architect wanted two memory windows per device, one SO for register control and one DEVICE for FIFO access. Given that we do DMA (which doesn't care about how ARM sees the world) on the performance hungry devices not doing this was ok. What we don't do is mark DMA memory ask being normal uncached memory, thereby allowing that to be reordered with device accesses - we make it strongly ordered. The reason being that the kernel doesn't have barriers necessary to ensure that writes to DMA memory hit physical memory before the device access to enable DMA hits the DMA controller. For an experiment a couple years back we did convert the dma alloc pool addresses as NC. All worked -except- for OHCI-USB which started failing some tests. 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
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Thu, Aug 07, 2008 at 01:56:40PM -0500, Woodruff, Richard wrote: From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Most of the weak memory attributes in newer ARMs are not exploited today in tree. I'll guess this was more a correctness and capability judgment from Russell. Not entirely true. We do as much as is safe to do - which is basically using 'device' mappings for devices and ioremap, and 'memory' mappings for the main memory, module and vmalloc mappings. Is DEVICE really safe for things other than FIFOs with out the use of barriers? As far as I'm aware, yes - and that comment is based solely upon the fact that no one has reported any problems with the kernel which have been tracked down to using the device memory type on ARMv6 and above... We do in some drivers today get spurious interrupts when DEVICE is used but don't see them when using SO. ... until now, or even that very sentence. That's not unexpected if you don't have the right barriers in place at the end of things such as IRQ controllers ack/mask functions. Can you give me more information - which OMAP platform, which IRQ controller, which device is easiest to provoke this behaviour, and I'll look at it. Originally the IC-Architect wanted two memory windows per device, one SO for register control and one DEVICE for FIFO access. Given that we do DMA (which doesn't care about how ARM sees the world) on the performance hungry devices not doing this was ok. I'm not sure what point you're making there. For an experiment a couple years back we did convert the dma alloc pool addresses as NC. All worked -except- for OHCI-USB which started failing some tests. If we go down the route of marking DMA as 'normal memory non-cacheable' we're going to have a never ending stream of drivers which don't work correctly. We're forever going to be bug hunting drivers, having to add barriers as required. Arguably those barriers should be there already, but if drivers are developed on platforms without weak ordering, authors just don't think about it, and _certainly_ can't test them. -- 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 MMU: add strongly-ordered memory type
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Is DEVICE really safe for things other than FIFOs with out the use of barriers? As far as I'm aware, yes - and that comment is based solely upon the fact that no one has reported any problems with the kernel which have been tracked down to using the device memory type on ARMv6 and above... We do in some drivers today get spurious interrupts when DEVICE is used but don't see them when using SO. ... until now, or even that very sentence. That is our fault then I suppose for not discussing this on arm-linux. In OMAP2 and OMAP3 this has been observed. In vendor kernels where time stands still and lots of validation has happened we did stick with SO for OMAP2. On some internal kernels already we have gone to SO for OMAP3 as customers ramp and need the errors gone. The faster the system clocks the more it seems to show. The thing with these effects, especially spurious IRQs is there usually are several reasons they show up and several ways to make them go away. In the beginning there have been lots then they drop off as the system software matures. Then if the program survives long enough to be optimized they start to show up again but in lesser numbers. This has been the OMAP2/3 experience so far. Going SO to control regions has stamped them out at this point. That's not unexpected if you don't have the right barriers in place at the end of things such as IRQ controllers ack/mask functions. Yes. I've submitted patches (to linux-omap) and Catalin did submit patches (to arm-linux) for PIC barriers. In the past they have been rejected by Tony or you for different reasons. Tony last rejected it because he thought it should be generic at the ARM level. I don't recall what your last stance was. It is consistently observed, that with these irq-controller barriers in place, spurious irqs go down (but not necessarily away). Our internal kernels still have this in them for OMAP2 and OMAP3. Can you give me more information - which OMAP platform, which IRQ controller, which device is easiest to provoke this behaviour, and I'll look at it. Lately, a full OMAP3 system running with the 3d-GFX driver is causing these. Camera driver operation has been one which raised them on and off. If it persists exporting an environment to you should be possible. I expect it will take time and coordination to do this. The pure linux-omap kernel has periodically seen spurious irqs with UART. However, if you use the irq-controller barriers they tend to go away. Originally the IC-Architect wanted two memory windows per device, one SO for register control and one DEVICE for FIFO access. Given that we do DMA (which doesn't care about how ARM sees the world) on the performance hungry devices not doing this was ok. I'm not sure what point you're making there. Use a dual mapping to manage a device (2 ioremaps). You use a SO mapping to write to registers of that device. Then when you go to write to its FIFO use a DEVICE mapping. Say TX IRQ happens at UART, I might check status bits through a SO mapping, but when it comes time to fill the FIFO I write to the DEVICE mapping. Maybe I can even arrange it such that I burst in order using the natural FIFO width. Even if you don't burst you can take advantage of the bus posting effects. Fill the FIFO and get out of there with out a big stall time. Like I said previously, a system likely will use DMA to the FIFO if performance matters, so not optimizing here has been the choice. For an experiment a couple years back we did convert the dma alloc pool addresses as NC. All worked -except- for OHCI-USB which started failing some tests. If we go down the route of marking DMA as 'normal memory non-cacheable' we're going to have a never ending stream of drivers which don't work correctly. We're forever going to be bug hunting drivers, having to add barriers as required. Arguably those barriers should be there already, but if drivers are developed on platforms without weak ordering, authors just don't think about it, and _certainly_ can't test them. Is this just the case for an attribute to be made available from an API change/addition to allow a driver to make use of it? The default can always be conservative. The trend is ARMs are depending more on pipeline and prefetch tricks to perform. For these tricks to work weak memory features need to be used at times. 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
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Thu, Aug 07, 2008 at 03:38:55PM -0500, Woodruff, Richard wrote: From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] Is DEVICE really safe for things other than FIFOs with out the use of barriers? As far as I'm aware, yes - and that comment is based solely upon the fact that no one has reported any problems with the kernel which have been tracked down to using the device memory type on ARMv6 and above... We do in some drivers today get spurious interrupts when DEVICE is used but don't see them when using SO. ... until now, or even that very sentence. That is our fault then I suppose for not discussing this on arm-linux. In OMAP2 and OMAP3 this has been observed. In vendor kernels where time stands still and lots of validation has happened we did stick with SO for OMAP2. On some internal kernels already we have gone to SO for OMAP3 as customers ramp and need the errors gone. The faster the system clocks the more it seems to show. To do that, and then ask about when Linux is going to start exploiting the weak memory types is a little unfair don't you think? The thing with these effects, especially spurious IRQs is there usually are several reasons they show up and several ways to make them go away. In the beginning there have been lots then they drop off as the system software matures. Then if the program survives long enough to be optimized they start to show up again but in lesser numbers. This has been the OMAP2/3 experience so far. Going SO to control regions has stamped them out at this point. What you're therefore asking for is a weak memory ordering model which doesn't require any effort on the software programmers part - that's a CPU architecture thing which you'll need to talk to ARM about. x86 can do this for the most part because x86's development has been such that the hardware has had to work around the software to make improvements. On ARM, normally when there's updates, software has to work around the hardware. That's not unexpected if you don't have the right barriers in place at the end of things such as IRQ controllers ack/mask functions. Yes. I've submitted patches (to linux-omap) and Catalin did submit patches (to arm-linux) for PIC barriers. In the past they have been rejected by Tony or you for different reasons. Tony last rejected it because he thought it should be generic at the ARM level. I don't recall what your last stance was. Looking back, I never commented on that patch. I did on the previous patch which was adding DSBs in a way which would break stuff. The patch to add them to the interrupt controllers has never been reposted. However, adding barriers may not be the correct answer for this. See Documentation/io_ordering.txt - reading back from a safe register on the target device ensures that the previous writes should hit the device before the read completes, without the overhead of a full barrier. This point is even more important if you have some form of write posting between the CPU and the device (eg, a PCI bus) - a DSB won't reach down to the target PCI device which may be behind some write-posting bridges. So, in the case of arch/arm/common/gic.c, we should be reading one of the gic control registers after the writes. In the case of arch/arm/mach-omap2/irq.c, reading the INTC_REVISION reg after masking should be a sufficient solution. But, not a barrier. However, if you use the irq-controller barriers they tend to go away. Great, so solving that should prevent them. Originally the IC-Architect wanted two memory windows per device, one SO for register control and one DEVICE for FIFO access. Given that we do DMA (which doesn't care about how ARM sees the world) on the performance hungry devices not doing this was ok. I'm not sure what point you're making there. Use a dual mapping to manage a device (2 ioremaps). You use a SO mapping to write to registers of that device. Then when you go to write to its FIFO use a DEVICE mapping. I believe ARMv7 has some restrictions on dual mapping of the same space with different types, so don't expect this technique to always work. Say TX IRQ happens at UART, I might check status bits through a SO mapping, but when it comes time to fill the FIFO I write to the DEVICE mapping. Why? Firstly, the read _has_ to complete before the program can continue. (If it hasn't completed, you don't have the data to decide what to do next.) Secondly, any previous device writes will have to complete before the read completes. So what does reading the status bits through a SO mapping gain you? The answer is, all other reads and writes previously issued by the program completing. Does that affect the status that the UART is giving you? For an experiment a couple years back we did convert the dma alloc pool addresses as NC. All worked -except- for OHCI-USB which started failing some tests. If we go down the route of
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Thu, Aug 07, 2008 at 10:20:33PM +0100, Russell King - ARM Linux wrote:
In the case of arch/arm/mach-omap2/irq.c, reading the INTC_REVISION
reg after masking should be a sufficient solution.
And here's a patch to do exactly that.
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 9ef15b3..27610b1 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -48,6 +48,7 @@ static struct omap_irq_bank {
static void omap_ack_irq(unsigned int irq)
{
__raw_writel(0x1, irq_banks[0].base_reg + INTC_CONTROL);
+ __raw_readl(irq_banks[0].base_reg + INTC_REVISION);
}
static void omap_mask_irq(unsigned int irq)
@@ -61,6 +62,7 @@ static void omap_mask_irq(unsigned int irq)
}
__raw_writel(1 irq, irq_banks[0].base_reg + INTC_MIR_SET0 + offset);
+ __raw_readl(irq_banks[0].base_reg + INTC_REVISION);
}
static void omap_unmask_irq(unsigned int irq)
--
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] Patch for I2C transmit overflow error
On Thursday 07 August 2008, chandra shekhar wrote: This patch is to fix I2C transmit overflow error. I guess it should fix the OSK5912 error. I dont have the board to test it. Yes, it makes those error reports go away. I'd say to merge this patch. -- 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: About to tag v2.6.26-omap1, patch queue deleted, please check and repost
On Thursday 07 August 2008, Tony Lindgren wrote: Two problems on the OSK5912: - cpufreq oopses on boot - continuous i2c overflow errors ISTR both of these bugs are in mainline too. I'd say the I2C regression is higher priority. Hmm, I wonder what has broken I2C? Seems fixed now; goof in earlier error handling patch. Anyways, let's fix these regressions before tagging. I've not yet looked at the cpufreq thing, but after applying the patch from Chandra Shekhar the I2C problem went away. However that still doesn't make OSK happy. It wedges sometime after freeing init memory ... timer interrupts are no longer happening, the LED stops flashing. The userspace has sometimes started the watchdog daemon, in which case a watchdog timeout fires and it reboots. FWIW mainline fails *really* early, before showing any kernel messages at all. - Dave -- 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: testers wanted: isp1301_omap conversion to new-style i2c driver
On Thursday 07 August 2008, Jean Delvare wrote: Still no testers for these patches? Right now I don't seem to be able to boot OMAP1 in mainline, so pulling that H2 out of its box would be futile. :( -- 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] Enable SYSOFFMODE use
On ke, 2008-08-06 at 12:12 -0500, ext Woodruff, Richard wrote: I would say no, we don't need the CONFIG_SYSOFFMODE option. One point is if you try an go to 0v on something under and ES2.1 you will end up with crashes after a while. Some kind of conditional is needed unless we get to drop the non-production chip versions. OK. We can replace the macros with run-time checks. But for ES2.1 suspending to 0V should be safe, right? It has been ok in our tests so far. 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
Re: HS USB errors on OMAP3530
On Thu, Aug 7, 2008 at 3:38 PM, David Brownell [EMAIL PROTECTED] wrote: On Thursday 07 August 2008, Ashwin Bihari wrote: sd 0:0:0:0: [sda] Attached SCSI removable disk usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: reset high speed USB device using ehci-omap and address 2 usb 1-2: device not accepting address 2, error -110 usb 1-2: USB disconnect, address 2 sd 0:0:0:0: Device offlined - not ready after error recovery Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sda, sector 775288 end_request: I/O error, dev sda, sector 775288 ... I wouldn't assume this is specifically an OMAP issue -- though it might be in this case. If you could throw a USB sniffer at the problem and report what that shows, it may be enlightening... Folk have been reporting these symptoms for some time, but nobody can quite track it down. I think one person who was able to observe the problem (I've never seen it) reported that switching disk, USB cable, *OR* PC host made the problem go away ... but MS-Windows didn't see it on the same hardware. As I recall, one person had some recent success shrinking the let SET_ADDRESS settle mdelay in drivers/usb/hub.c (near line 2535). Strictly speaking, that shouldn't be needed. - Dave Dave, I did use a Total Phase Beagle 480USB protocol analyzer when this issue first manifested, but there is nothing that jumped out at me as a possible error or glitch. It just looks like the transactions just stopped mid-way without any rhyme or reason. I've noticed this issue with a couple of HS flash drives, as well as, a FS CD-ROM drive. Would the let SET_ADDRESS settle change only affect the initial detection? My initial insertion of device works great, the errors I showed are after I do a read of a large amount of data from the Flash drive and essentially wedge something in the USB stream. Regards ~ Ashwin -- 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: HS USB errors on OMAP3530
On Thursday 07 August 2008, Ashwin Bihari wrote: I did use a Total Phase Beagle 480USB protocol analyzer when this issue first manifested, but there is nothing that jumped out at me as a possible error or glitch. It just looks like the transactions just stopped mid-way without any rhyme or reason. Why don't you post such a log, ideally with matching Linux kernel log data. Maybe something would jump out to other folk. :) I've noticed this issue with a couple of HS flash drives, as well as, a FS CD-ROM drive. Would the let SET_ADDRESS settle change only affect the initial detection? My initial insertion of device works great, Good. the errors I showed are after I do a read of a large amount of data from the Flash drive and essentially wedge something in the USB stream. What I'd like to establish is whether this is a case of the flash drive flaking out (that does happen on low end hardware!) or else there's something wrong on the Linux side. - Dave -- 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 3/3] Fixes required for HSMMC driver to work as module
* Madhusudhan Chikkature [EMAIL PROTECTED] [080725 13:34]:
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Fixes required to make HSMMC driver as module.
This patch provides the necessary fixes to make the HSMMC driver work as
loadble module.
This one does not apply, can you take a look?
Thanks,
Tony
Hi Tony,
I see that you have pushed this patch which did not apply correctly. So the
patch seems to have applied in part. Also the title for the commit seems to
have been wronly put as removing some usb defines.
I will post a patch which will complete the patch that I had send for HSMMC
driver to work as a module.
Regards,
Madhu
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 43
+++---
1 files changed, 32 insertions(+), 11 deletions(-)
Index: linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-ti.git-07142008.orig/drivers/mmc/host/omap_hsmmc.c
2008-07-23
16:31:56.0 +0530
+++ linux-omap-ti.git-07142008/drivers/mmc/host/omap_hsmmc.c 2008-07-24
12:07:40.0 +0530
@@ -764,23 +764,27 @@ static int __init omap_mmc_probe(struct
if (IS_ERR(host-iclk)) {
ret = PTR_ERR(host-iclk);
host-iclk = NULL;
-goto err;
+goto err1;
}
host-fclk = clk_get(pdev-dev, mmchs_fck);
if (IS_ERR(host-fclk)) {
ret = PTR_ERR(host-fclk);
host-fclk = NULL;
clk_put(host-iclk);
-goto err;
+goto err1;
}
-if (clk_enable(host-fclk) != 0)
-goto err;
+if (clk_enable(host-fclk) != 0) {
+clk_put(host-iclk);
+clk_put(host-fclk);
+goto err1;
+}
if (clk_enable(host-iclk) != 0) {
clk_disable(host-fclk);
+clk_put(host-iclk);
clk_put(host-fclk);
-goto err;
+goto err1;
}
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
@@ -873,12 +877,6 @@ static int __init omap_mmc_probe(struct
return 0;
-err:
-dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
-if (host)
-mmc_free_host(mmc);
-return ret;
-
irq_err:
dev_dbg(mmc_dev(host-mmc), Unable to configure MMC IRQs\n);
clk_disable(host-fclk);
@@ -890,6 +888,11 @@ irq_err:
clk_put(host-dbclk);
}
+err1:
+iounmap(host-base);
+err:
+dev_dbg(mmc_dev(host-mmc), Probe Failed\n);
+release_mem_region(res-start, res-end - res-start + 1);
if (host)
mmc_free_host(mmc);
return ret;
@@ -898,9 +901,26 @@ irq_err:
static int omap_mmc_remove(struct platform_device *pdev)
{
struct mmc_omap_host *host = platform_get_drvdata(pdev);
+struct resource *res;
+u16 vdd = 0;
+
+if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
+/*
+ * Set the vdd back to 3V,
+ * applicable for dual volt support.
+ */
+vdd = fls(host-mmc-ocr_avail) - 1;
+if (omap_mmc_switch_opcond(host, vdd) != 0)
+host-mmc-ios.vdd = vdd;
+}
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (res)
+release_mem_region(res-start, res-end - res-start + 1);
platform_set_drvdata(pdev, NULL);
if (host) {
+mmc_remove_host(host-mmc);
host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
if (mmc_slot(host).card_detect_irq)
@@ -917,6 +937,7 @@ static int omap_mmc_remove(struct platfo
}
mmc_free_host(host-mmc);
+iounmap(host-base);
}
return 0;
--
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
[Resending PATCH 3/3] Fixes required for HSMMC driver to work as module
From: Madhusudhan Chikkature[EMAIL PROTECTED]
ARM: OMAP3: Fixes required to make HSMMC driver work as module.Complete the
previously applied patch.
This patch provides the necessary fixes to make the HSMMC driver work as
loadble module.
Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]
Signed-off-by: Romit Dasgupta [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c | 17 +
1 files changed, 17 insertions(+)
Index: linux-omap-2.6/drivers/mmc/host/omap_hsmmc.c
===
--- linux-omap-2.6.orig/drivers/mmc/host/omap_hsmmc.c 2008-08-07
15:56:52.0 +0530
+++ linux-omap-2.6/drivers/mmc/host/omap_hsmmc.c2008-08-07
16:09:22.0
+0530
@@ -901,9 +901,26 @@ err:
static int omap_mmc_remove(struct platform_device *pdev)
{
struct mmc_omap_host *host = platform_get_drvdata(pdev);
+ struct resource *res;
+ u16 vdd = 0;
+
+ if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
+ /*
+* Set the vdd back to 3V,
+* applicable for dual volt support.
+*/
+ vdd = fls(host-mmc-ocr_avail) - 1;
+ if (omap_mmc_switch_opcond(host, vdd) != 0)
+ host-mmc-ios.vdd = vdd;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
platform_set_drvdata(pdev, NULL);
if (host) {
+ mmc_remove_host(host-mmc);
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
--
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
OMAP35xx MUSB kernel crash with Linux 2.6.26
Hi, I observed kernel crash in Linux 2.6.26 on OMAP35xx EVM with MUSB. The issue is described here. Case-1: 1) Connect USB stick to root hub of OMAP35xx board. 2) It gets detected successfully. 3) Disconnect the stick and connect it again 4) repeat step-3 and we get kernel crash (log-1 attached below). Case-2: 1) Connect USB stick to root hub of OMAP35xx board. 2) It gets detected successfully. 3) Mount it and try to read. 4) During read it gets stuck and kernel crash observed (log-2 attached below). Regards, Ajay ==[log-1] 7musb_start_urb 214: qh c7eb71e0 urb c7eea140 dev2 ep0out, hw_ep 0, ffc00020/8 7musb_ep_program 644: -- hw0 urb c7eea140 spd3 dev2 ep0out h_addr00 h_port00 bytes 8 7musb_write_fifo 171: TX ep0 fifo c8800020 count 8 buf ffc00020 7musb_start_urb 256: Start TX0 pio 7musb_hub_control 344: port status 00030101 7musb_hub_control 278: clear feature 16 7musb_hub_control 278: clear feature 17 6usb 1-1: USB disconnect, address 2 usb 1-1: USB disconnect, address 2 7musb_urb_dequeue 1979: urb=c7eea140, dev2 ep2out 7__musb_giveback 292: complete c7eea140 (-115), dev2 ep2out, 0/31 4[ cut here ] [ cut here ] 4WARNING: at lib/kref.c:43 kref_get+0x28/0x44() WARNING: at lib/kref.c:43 kref_get+0x28/0x44() Modules linked in:Modules linked in: [c002be04] [c002be04] (dump_stack+0x0/0x14) (dump_stack+0x0/0x14) from [c004aafc] from [c004aafc] (warn_on_slowpath+0x4c/0x68) (warn_on_slowpath+0x4c/0x68) [c004aab0] [c004aab0] (warn_on_slowpath+0x0/0x68) (warn_on_slowpath+0x0/0x68) from [c015e69c] from [c015e69c] (kref_get+0x28/0x44) (kref_get+0x28/0x44) r6:c7d1d034 r6:c7d1d034 r5:c7c75800 r5:c7c75800 r4:c7eea1e0 r4:c7eea1e0 [c015e674] [c015e674] (kref_get+0x0/0x44) (kref_get+0x0/0x44) from [c01d5050] from [c01d5050] (usb_get_urb+0x18/0x20) (usb_get_urb+0x18/0x20) r5:c7c75800 r5:c7c75800 r4:c7eea1e0 r4:c7eea1e0 [c01d5038] [c01d5038] (usb_get_urb+0x0/0x20) (usb_get_urb+0x0/0x20) from [c01d43ec] from [c01d43ec] (usb_hcd_flush_endpoint+0x3c/0xcc) (usb_hcd_flush_endpoint+0x3c/0xcc) r5:c7c75800 r5:c7c75800 r4:c7eea1e0 r4:c7eea1e0 [c01d43b0] [c01d43b0] (usb_hcd_flush_endpoint+0x0/0xcc) (usb_hcd_flush_endpoint+0x0/0xcc) from [c01d55e0] from [c01d55e0] (usb_disable_endpoint+0x5c/0x6 c) (usb_disable_endpoint+0x5c/0x6c) r7:c7d1d060 r7:c7d1d060 r6:001f r6:001f r5:c7d1d000 r5:c7d1d000 r4:c7d1d034 r4:c7d1d034 [c01d5584] [c01d5584] (usb_disable_endpoint+0x0/0x6c) (usb_disable_endpoint+0x0/0x6c) from [c01d560c] from [c01d560c] (usb_disable_device+0x1c/0xf8) (usb_disable_device+0x1c/0xf8) r5:c7d1d000 r5:c7d1d000 r4: r4: [c01d55f0] [c01d55f0] (usb_disable_device+0x0/0xf8) (usb_disable_device+0x0/0xf8) from [c01d176c] from [c01d176c] (usb_disconnect+0x90/0xd0) (usb_disconnect+0x90/0xd0) r7:c7d1d060 r7:c7d1d060 r6:001f r6:001f r5:c7d1d07c r5:c7d1d07c r4:c7d1d000 r4:c7d1d000 [c01d16dc] [c01d16dc] (usb_disconnect+0x0/0xd0) (usb_disconnect+0x0/0xd0) from [c01d1c14] from [c01d1c14] (hub_thread+0x358/0xb5c) (hub_thread+0x358/0xb5c) [c01d18bc] [c01d18bc] (hub_thread+0x0/0xb5c) (hub_thread+0x0/0xb5c) from [c005d69c] from [c005d69c] (kthread+0x54/0x80) (kthread+0x54/0x80) [c005d648] [c005d648] (kthread80) (kthread+0x0/0x80) from [c004db40] from [c004db40] (do_exit+0x0/0x5fc) (do_exit+0x0/0x5fc) r5: r5: r4: r4: 4---[ end trace 1c3c0ed6dfe75056 ]--- ---[ end trace 1c3c0ed6dfe75056 ]--- 1Unable to handle kernel NULL pointer dereference at virtual address 002c Unable to handle kernel NULL pointer dereference at virtual address 002c 1pgd = c0004000 pgd = c0004000 1[002c] *pgd=[002c] *pgd= Internal error: Oops: 17 [#1] Internal error: Oops: 17 [#1] Modules linked in:Modules linked in: CPU: 0Tainted: GW (2.6.26-omap1 #23) CPU: 0Tainted: GW (2.6.26-omap1 #23) PC is at unlink1+0x1c/0xac PC is at unlink1+0x1c/0xac LR is at usb_hcd_flush_endpoint+0x4c/0xcc LR is at usb_hcd_flush_endpoint+0x4c/0xcc pc : [c01d3a3c]lr : [c01d43fc]psr: 6093 sp : c7c65ec0 ip : c7c65ee8 fp : c7c65ee4 pc : [c01d3a3c]lr : [c01d43fc]psr: 6093 sp : c7c65ec0 ip : c7c65ee8 fp : c7c65ee4 r10: c7c11230 r9 : 0001 r8 : ff94 r10: c7c11230 r9 : 0001 r8 : ff94 r7 : c7d1d060 r6 : c7eea1e0 r5 : c7c75800 r4 : c7c75800 r7 : c7d1d060 r6 : c7eea1e0 r5 : c7c75800 r4 : c7c75800 r3 : r2 : ff94 r1 : c7eea1e0 r0 : c7c75800 r3 : r2 : ff94 r1 : c7eea1e0 r0 : c7c75800 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 87c98018 DAC: 0017 Control: 00c5387f Table: 87c98018 DAC: 0017 Process khubd (pid: 91, stack limit = 0xc7c642e0) Process khubd (pid: 91, stack limit = 0xc7c642e0) Stack: (0xc7c65ec0 to
