Enabling clock for EMU clock domain
Good afternoon,
I am working on a beagleXM fitted with an OMAP3630 (I know it's old).
I am getting a reference on the emu_src_ck clock by calling
clk = clk_get(dev, emu_src_ck);
From there calling:
clk_enable(clk);
I have observed that upon returning from clk_enable() the clock is
still not active and as such, an access to the memory map of a device
in the EMU domain results in a kernel crash [1].
The enable function associated to emu_src_ck is
omap2_clkops_enable_clkdm(), which ends up calling
omap3xxx_clkdm_clk_enable(). In there there following condition is
taken:
240 if ((clkdm-flags CLKDM_MISSING_IDLE_REPORTING)
241 (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)) {
242 omap3xxx_clkdm_wakeup(clkdm);
243 return 0;
244 }
omap3xxx_clkdm_wakeup() results in a __raw_writel() and returns
right away, not waiting for the status bit associated to the clock.
That is where the problem is coming from.
Asking an OMAP clock expert I learned that if an .enable() function
is to wait for the status bit to be active before returning, it has to
go through omap2_dflt_clk_enable(). Since we have a hierarchy of
clocks, emu_src_ck may not be the right clock to call if I want it
to be active upon returning from clk_enable().
I perused through the TRM and browsed the code, more specifically the
clocks found in drivers/clk/ti/clk-3xxx.c. I made a list of the
clocks that do have omap2_dflt_clk_enable() as their enable function
but I simply couldn't find a match between the EMU clock domain and
the top clock I need to enable in the code.
At this point I know two things:
1) I probably missed something in that staggering heap of clocks.
2) Someone somewhere knows the answer of the top of their head.
I would be grateful if that magic someone would take 2 minutes to
answer my email. I need to know which clock listed in clk-3xxx.c
that will get me a working emu_src_ck clock upon return from
clk_enable(clk).
Best regards,
Mathieu
[1]. Unhandled fault: external abort on non-linefetch (0x1028) at 0xfe810010
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: OMAP depends on MMU
From: Arnd Bergmann a...@arndb.de There is no way to build OMAP kernels without an MMU at this point because of dependencies on MMU-only functions. As long as nobody is interested in fixing this, let's just disable this platforms for nommu kernels. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 84449dd..4b1fc0d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -934,6 +934,7 @@ config ARCH_DAVINCI config ARCH_OMAP bool TI OMAP + depends on MMU select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] omap randconfig fixes for v3.3
From: Arnd Bergmann a...@arndb.de The following is a set of patches that have been sent out during the 3.1 cycle that were not acked or merged. Sending again for completeness. Tony, please pull if there are no objections: The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Linux 3.3 (2012-03-18 16:15:34 -0700) are available in the git repository at: git://git.linaro.org/people/mpoirier/linux.git randconfig-omap Arnd Bergmann (8): arm/omap: enable building omap2 without omap2420/2430 omap: fix visibility of omap2_mbox_iva_priv ARM: omap2+: fix building without i2c tty/serial/omap: console can only be built-in omap2: select twl4030 support on boards that need it omap2plus: ensure that one of omap2/3/4 is selected arm: OMAP depends on MMU ARM: omap: select CPU_FREQ_TABLE where needed Russell King (1): ARM: omap2/n8x0: work around modular omap mmc arch/arm/Kconfig |1 + arch/arm/mach-omap2/Kconfig| 19 +++ arch/arm/mach-omap2/board-n8x0.c |6 -- arch/arm/mach-omap2/mailbox.c |2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Kconfig |5 + arch/arm/plat-omap/include/plat/multi.h|5 + drivers/tty/serial/Kconfig |2 +- 11 files changed, 40 insertions(+), 8 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] omap: fix visibility of omap2_mbox_iva_priv
From: Arnd Bergmann a...@arndb.de
map2_mbox_iva_priv is used on multiple omap2 socs but is hidden
in an outdated #ifdef that is specific to a single soc.
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 415a6f1..ef01f6c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -258,7 +258,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] omap2plus: ensure that one of omap2/3/4 is selected
From: Arnd Bergmann a...@arndb.de Random configurations can fail if none of the omap families in mach-omap2 is selected. This patch automatically selects omap2 if the user has not made any other choice. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 0279e9e..b244e80 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -55,6 +55,16 @@ config ARCH_OMAP4 select USB_ARCH_HAS_EHCI select ARM_CPU_SUSPEND if PM +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: omap: select CPU_FREQ_TABLE where needed
From: Arnd Bergmann a...@arndb.de The omap platform requires CPU_FREQ_TABLE support to be enabled for its CPU_FREQ implementations, so automatically select that when CPU_FREQ is enabled. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org --- arch/arm/plat-omap/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index aa59f42..1983d16 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -207,6 +207,11 @@ config OMAP_PM_NOOP endchoice +config OMAP_CPU_FREQ + def_bool y + depends on CPU_FREQ + select CPU_FREQ_TABLE + endmenu endif -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] arm: OMAP depends on MMU
From: Arnd Bergmann a...@arndb.de There is no way to build OMAP kernels without an MMU at this point because of dependencies on MMU-only functions. As long as nobody is interested in fixing this, let's just disable this platforms for nommu kernels. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dfb0312..8124ce0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -939,6 +939,7 @@ config ARCH_DAVINCI config ARCH_OMAP bool TI OMAP + depends on MMU select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] omap2: select twl4030 support on boards that need it
From: Arnd Bergmann a...@arndb.de These three boards unconditionally use the twl4030 driver from the board-zoom-display.c file. Make sure that the driver is always there. We also need to select the I2C core so we are able to build that driver. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e20c8ab..0279e9e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -265,6 +265,9 @@ config MACH_OMAP_ZOOM2 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE if REGULATOR + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_OMAP_ZOOM3 bool OMAP3630 Zoom3 board @@ -275,6 +278,9 @@ config MACH_OMAP_ZOOM3 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE if REGULATOR + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_CM_T35 bool CompuLab CM-T35/CM-T3730 modules @@ -316,6 +322,9 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select TWL4030_CORE + select MFD_SUPPORT + select I2C config MACH_TI8168EVM bool TI8168 Evaluation Module -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] tty/serial/omap: console can only be built-in
From: Arnd Bergmann a...@arndb.de When the omap serial driver is built as a module, we must not allow the console driver to be selected, because consoles can not be loadable modules. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Govindraj.R govindraj.r...@ti.com --- drivers/tty/serial/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 2de9924..bcf7e24 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1041,7 +1041,7 @@ config SERIAL_OMAP config SERIAL_OMAP_CONSOLE bool Console on OMAP serial port - depends on SERIAL_OMAP + depends on SERIAL_OMAP=y select SERIAL_CORE_CONSOLE help Select this option if you would like to use omap serial port as -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: omap2+: fix building without i2c
From: Arnd Bergmann a...@arndb.de
A trivial typo causes build breakage when I2C is disabled
and omap_i2c_reset is set to NULL on OMAP:
omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '' operand
Removing the '' character solves this.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Avinash.H.M avinas...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a5409ce..d74c76f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1038,7 +1038,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c4f56cb..69c91b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1088,7 +1088,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3c8dd92..d8eb79f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1367,7 +1367,7 @@ static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ef0524c..9adf749 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2258,7 +2258,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
.name = i2c,
.sysc = omap44xx_i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_2,
- .reset = omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: omap2/n8x0: work around modular omap mmc
From: Russell King li...@arm.linux.org.uk
When the omap driver is built as a module for n8x0,
n8x0_mmc_set_power_menelaus cannot call into the driver:
arch/arm/mach-omap2/board-n8x0.c:374: undefined reference
to `omap_mmc_notify_cover_event'
As a workaround, do not provide that device in this case. This needs
to be fixed properly, e.g. by converting n8x0 to be probed through the
device tree and moving that code into the driver.
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
Suggested-by: Russell King li...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-n8x0.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 6722627..8529ca0 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -193,8 +193,10 @@ static struct omap_onenand_platform_data
board_onenand_data[] = {
};
#endif
-#if defined(CONFIG_MENELAUS)
\
- (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
+#ifdef CONFIG_MMC_OMAP_MODULE
+#warning FIXME: cannot call omap_mmc_notify_cover_event for
CONFIG_MMC_OMAP_MODULE
+#endif
+#if defined(CONFIG_MENELAUS) (defined(CONFIG_MMC_OMAP)
/*
* On both N800 and N810, only the first of the two MMC controllers is in use.
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] arm/omap: enable building omap2 without omap2420/2430
From: Arnd Bergmann a...@arndb.de Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options being omap2420 and omap2430, but that leads to a build error when omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is undefined. This adds another clause to plat/multi.h, mainly to allow all possible randconfig combinations to build cleanly. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/multi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h index 999ffba..fb7f196 100644 --- a/arch/arm/plat-omap/include/plat/multi.h +++ b/arch/arm/plat-omap/include/plat/multi.h @@ -82,6 +82,11 @@ # define OMAP_NAME omap2430 # endif #endif +#ifdef CONFIG_ARCH_OMAP2 +# ifndef OMAP_NAME +# define OMAP_NAME omap2 +# endif +#endif #ifdef CONFIG_ARCH_OMAP3 # ifdef OMAP_NAME # undef MULTI_OMAP2 -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Adding i2c eeprom driver to read EDID
From f0b677144c1b674f21c1f423781c49d8173914c8 Mon Sep 17 00:00:00 2001
From: Mathieu J. Poirier mathieu.poir...@canonical.com
Date: Fri, 20 Aug 2010 14:25:53 -0600
Subject: [PATCH] Adding i2c eeprom driver to read EDID
Adding i2c eeprom driver to access monitor EDID binary information
from user space, something that is required by 'decode-edid' and
'parse-edid'.
BugLink: https://bugs.launchpad.net/bugs/608279
Signed-off-by: Mathieu Poirier mathieu.poir...@canonical.com
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7a1b351..fb6cbb9 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -355,13 +355,19 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
},
};
+static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
+};
+
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
- omap_register_i2c_bus(3, 100, NULL, 0);
+ omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Resetting host-power_mode to its original value
Good morning, The config file found at http://people.canonical.com/~mpoirier/config.mmc_failure; was generated by doing a make omap3_beagle_defconfig from 2.6.35-rc6, followed by a make menuconfig where the following flags were enabled: CONFIG_PREEMPT_VOLUNTARY CONFIG_CPU_IDLE CONFIG_SOUND CONFIG_SND CONFIG_SND_SOC When all 5 flags are set the following error message appears on the console, preventing one from booting a system from SDHC card: mmc0: error -110 whilst initialising SD card The problem was introduced by patch: 6da20c89af64b75302399369a90b9d50c1a87665 The first part of the patch is fine. The problem is caused by the initialization of the 'power_mode' variable in the second portion of the patch: host-power_mode = MMC_POWER_OFF; Reverting this statement to it's original form: host-power_mode = -1; is enough to cure the problem. I noticed that in file drivers/mmc/host/omap_hsmmc.c, 'host-power_mode' is used fairly often in the functions related to power management. Note that some cards don't exhibit the problem but with the ones that do, the failure is consistent and reproducible at will. I will dive in the code to understand exactly what is going on and hopefully find a solution to the problem. At this time, I suggest the following patch: http://people.canonical.com/~mpoirier/0001-Resetting-host-power_mode-to-its-orininal-value.patch; Since this area is completely foreign to me, help from anyone would be greatly appreciated. You can find me on freenode (mpoirier) under #ubuntu-arm, #ubuntu-kernel and #beagle. You can also find a reference to this bug in launchpad: https://bugs.launchpad.net/bugs/591941 I run a beagle board C4, fitted with an OMAP3 3530. Once again, my kernel is a vanilla upstream 2.6.35-rc6. The problem has also been observed on revision C2, C3 and XM. Best regards, Mathieu. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Initializing gpmc before accessing flash
From b12de3010763a8c047eefd2eb9296eb68157b07e Mon Sep 17 00:00:00 2001 From: Mathieu J. Poirier mathieu.poir...@canonical.com Date: Tue, 10 Aug 2010 17:14:25 -0400 Subject: [PATCH] Initializing gpmc before accessing flash Adding initialization of the General Purpose Memory Controller (gpmc) in 'omap3beagle_flash_init'. The gpmc init was decoupled from nand flash init and got its own init function. This change was not reflected in 'omap3beagle_flash_init' resulting in a lookup failure when probing for flash. BugLink: https://bugs/launchpad.net/bugs/608266 Signed-off-by: Mathieu Poirier mathieu.poir...@canonical.com --- arch/arm/mach-omap2/board-omap3beagle.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 7a1b351..e1203a4 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -466,6 +466,7 @@ static void __init omap3beagle_flash_init(void) omap3beagle_nand_data.gpmc_cs_baseaddr = (void *) (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE); omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add); + gpmc_nand_init(omap3beagle_nand_data); printk(KERN_INFO Registering NAND on CS%d\n, nandcs); if (platform_device_register(omap3beagle_nand_device) 0) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Combine dsi and sdi under the same vdds supply.
From b817304b25a0358f2897d39048adfada8d4126bc Mon Sep 17 00:00:00 2001
From: Mathieu J. Poirier mathieu.poir...@canonical.com
Date: Wed, 14 Jul 2010 15:31:46 -0600
Subject: [PATCH] Combine dsi and sdi under the same vdds supply.
The omapfb driver can't locate its display sink because of an
initialization error in the DSS subsystem. This error is caused by a
missing sdi entry in the board power regulator list. Adding the missing
sdi entry and combining dsi and sdi under the same vdds supply.
BugLink: https://bugs.launchpad.net/bugs/597904
Signed-off-by: mathieu.poir...@canonical.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 69b154c..32565dc 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -162,8 +162,10 @@ static struct platform_device beagle_dss_device = {
static struct regulator_consumer_supply beagle_vdac_supply =
REGULATOR_SUPPLY(vdda_dac, omapdss);
-static struct regulator_consumer_supply beagle_vdvi_supply =
- REGULATOR_SUPPLY(vdds_dsi, omapdss);
+static struct regulator_consumer_supply beagle_vdds_supplies[] = {
+ REGULATOR_SUPPLY(vdds_dsi, omapdss),
+ REGULATOR_SUPPLY(vdds_sdi, omapdss),
+};
static void __init beagle_display_init(void)
{
@@ -291,7 +293,6 @@ static struct regulator_init_data beagle_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_init_data beagle_vpll2 = {
.constraints = {
- .name = VDVI,
.min_uV = 180,
.max_uV = 180,
.valid_modes_mask = REGULATOR_MODE_NORMAL
@@ -299,8 +300,8 @@ static struct regulator_init_data beagle_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = beagle_vdvi_supply,
+ .num_consumer_supplies = ARRAY_SIZE(beagle_vdds_supplies),
+ .consumer_supplies = beagle_vdds_supplies,
};
static struct twl4030_usb_data beagle_usb_data = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDHC card affected by preemption model in 2.6.35
On Wed, 2010-06-16 at 14:13 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: HW: Beagleboard rev. C2 and C4 Processor: OMAP3 Kernel: 2.6.35-rc2 Driver: mmci-omap-hs I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY. When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. When booting, a failing card (PREEMPT_VOLUNTARY) will output the following: [ 2.283355] mmc0: error -110 whilst initialising SD card I have also seen transfer errors such as this one: [ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr 26, card status 0xc00 When working properly (PREEMPT_NONE), you get: [ 27.026519] mmc0: new high speed SDHC card at address 0007 [ 27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB We seem to have a little timing problem - has anyone seen the same issue ? Can driver mmci-omap-hs actually work under PREEMPT_VOLUNTARY ? Thanks, Mathieu. I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful. Thanks, Venkat. Venkat, Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console. As for the cards, had failures with 3 different manufacturer: - Patriot Memory, MicroSD card, 8GB, class 4, SDHC. - Kinston, 4GB, class 6, SDHC. - Sandisk, 4GB, Class 2, SDHC. I am more than willing to test kernels for you if need be. Thanks, Mathieu. For MMC/SD logs to be sent to the console, you need to a) echo 8 /proc/sys/kernel/printk in the shell and b) insert the card If you are booting from the card itself, then this won't work and DEBUG_LL has to be enabled (in addition to CONFIG_MMC_DEBUG) Apologies - I should have explained this initially. Regards, Venkat. Venkat, I am indeed booting from the card itself, making things more difficult. DEBUG_LL has been configured since the very beginning and still not much to look at on the console. To see something I had to pass loglevel=8 on the kernel command line. At that point there is tones of stuff coming out and the card is initialized properly, which points to a timing issue. Since I couldn't reproduce the failure when debug messages are enabled, I turned them back off and started to instrument the code on the hunt for the failure. I have cornered the source of the problem in drivers/mmc/core/sd_ops.c, function mmc_sd_switch. When the kernel is configured with PREEMPT_NONE, the value of data.error is set to 0 after mmc_wait_for_req returns. When PREEMPT_VOLUNTARY is configured, data.error gets set to -110 upon mmc_wait_for_req returning, which prevent the remaining of the configuration to take place. I am out of time for today but tomorrow I'll dive in mmc_wait_for_req. Send me a line if the above rings a bell or you find something. Ghorai, please find an answer to your question in the above trail. Thanks, Mathieu. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SDHC card affected by preemption model in 2.6.35
HW: Beagleboard rev. C2 and C4 Processor: OMAP3 Kernel: 2.6.35-rc2 Driver: mmci-omap-hs I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY. When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. When booting, a failing card (PREEMPT_VOLUNTARY) will output the following: [ 2.283355] mmc0: error -110 whilst initialising SD card I have also seen transfer errors such as this one: [ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr 26, card status 0xc00 When working properly (PREEMPT_NONE), you get: [ 27.026519] mmc0: new high speed SDHC card at address 0007 [ 27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB We seem to have a little timing problem - has anyone seen the same issue ? Can driver mmci-omap-hs actually work under PREEMPT_VOLUNTARY ? Thanks, Mathieu. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDHC card affected by preemption model in 2.6.35
On Tue, 2010-06-15 at 20:58 +0530, Venkatraman S wrote: Mathieu Poirier mathieu.poir...@canonical.com wrote: HW: Beagleboard rev. C2 and C4 Processor: OMAP3 Kernel: 2.6.35-rc2 Driver: mmci-omap-hs I am faced with an SDHC card problem on a beagleboard. Some cards cannot be initialized on startup while others work perfectly. I tracked the issue down to one single kernel config: PREEMPT_VOLUNTARY. When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. When booting, a failing card (PREEMPT_VOLUNTARY) will output the following: [ 2.283355] mmc0: error -110 whilst initialising SD card I have also seen transfer errors such as this one: [ 105.343780] mmcblk0: error -110 transferring data, sector 798431, nr 26, card status 0xc00 When working properly (PREEMPT_NONE), you get: [ 27.026519] mmc0: new high speed SDHC card at address 0007 [ 27.075775] mmcblk0: mmc0:0007 SD08G 7.49 GiB We seem to have a little timing problem - has anyone seen the same issue ? Can driver mmci-omap-hs actually work under PREEMPT_VOLUNTARY ? Thanks, Mathieu. I will check this out - not tested with PREEMPT_VOLUNTARY so far. If it's not too much trouble, can you provide a log with CONFIG_MMC_DEBUG ? Also, some details about the failing card would be helpful. Thanks, Venkat. Venkat, Unfortunately enabling CONFIG_MMC_DEBUG doesn't yield more information - the error message is the same and no additional output shows on the console. As for the cards, had failures with 3 different manufacturer: - Patriot Memory, MicroSD card, 8GB, class 4, SDHC. - Kinston, 4GB, class 6, SDHC. - Sandisk, 4GB, Class 2, SDHC. I am more than willing to test kernels for you if need be. Thanks, Mathieu. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDHC card affected by preemption model in 2.6.35
On Tue, 2010-06-15 at 14:55 -0700, David Brownell wrote: When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. Have you found whether this is a problem with the OMAP HSMMC driver versus the MMC/SD framework code Not yet - I'm in the code, investigating. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
