RE: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
-Original Message-
From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
Sent: Tuesday, January 05, 2010 1:06 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Woodruff, Richard; Menon,
Nishanth
Subject: Re: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
Hello,
Few little comments bellow.
On Tue, Jan 05, 2010 at 07:36:08AM +0100, ext Vishwanath BS wrote:
DPLL4 for 3630 introduces a changed block requiring special divisor
bits and additional reg fields. To allow for silicons to use this, this
is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630
^
I don't see anywhere in this patch a reference to this function/macro
Yes, omap3_has_jtype_dpll4 is no longer used. This description is borrowed from
previous version of the patch. I will correct it.
silicon. Also FREQSEL field is no longer valid for OMAP3630. So reference
to this is removed for 3630.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c|2 +
arch/arm/mach-omap2/clock44xx_data.c|1 +
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/dpll.c | 53
--
arch/arm/plat-omap/include/plat/clock.h |1 +
6 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..14f73e7 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,9 @@
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+/*DPLL Type and DCO Selection Flags*/
+#define DPLL_J_TYPE0x1
+#define DPLL_NO_DCO_SEL0x2
Add blank line here, just to make it cleaner.
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-
omap2/clock34xx_data.c
index 043caed..9aac354 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3241,6 +3241,8 @@ int __init omap2_clk_init(void)
cpu_clkflg |= CK_3430ES2;
}
}
+ if (cpu_is_omap3630())
+ dpll4_ck.dpll_data-flags |= DPLL_J_TYPE;
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index 2210e22..7347246 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2736,6 +2736,7 @@ int __init omap2_clk_init(void)
if (cpu_is_omap44xx()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
+ dpll_usb_ck.dpll_data-flags |= DPLL_NO_DCO_SEL | DPLL_J_TYPE;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-
regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index f6055b4..d52ab37 100644
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -238,6 +238,42 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
}
/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+
RE: [PATCH] rtc: make rtc-omap wakeup capable
Hello, On Tue, Nov 24, 2009 at 18:48:40, Nori, Sekhar wrote: The rtc-omap driver currently hardcodes the RTC to be not capable of wakeup events. On the DA850/OMAP-L138 SoC, the RTC is a wake up source from its deep sleep mode. Let platform data set the wakeup capability flag instead. Signed-off-by: Sekhar Nori nsek...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Any comments on this patch? Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] Get rid of ifdef in board file
Here is the Version 3 of the 2 patch series based on top of your for-tony branch at [1]. [1] git://gitorious.org/usb/usb.git for-tony Maulik Mankad (2): [PATCH 1/2] USB : Add empty functions in otg.h [PATCH 2/2] ARM : OMAP : Remove #ifdef from board-omap3evm.c The Version 3 of the patch set fixes the comments received for Version 2. Felipe, Greg, Tony Note that Patch 1 needs to go through Greg (USB) and Patch 2 through Tony (OMAP). Patch 2/2 depends on Patch 1/2. The patches are compile tested and do not report any checkpatch warnings. Thanks, Maulik -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] USB: Add empty functions in otg.h
USB : Add empty functions in otg.h
Add empty functions for usb_nop_xceiv_register()
and usb_nop_xceiv_unregister() in otg.h so that
these functions can be called even when
CONFIG_NOP_USB_XCEIV is not enabled.
It allows to remove ifdef's from board file.
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Olof Johansson o...@lixom.net
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
Cc: Gupta, Ajay Kumar ajay.gu...@ti.com
---
Index: felipe_musb/include/linux/usb/otg.h
===
--- felipe_musb.orig/include/linux/usb/otg.h
+++ felipe_musb/include/linux/usb/otg.h
@@ -110,9 +110,19 @@ struct otg_transceiver {
/* for board-specific init logic */
extern int otg_set_transceiver(struct otg_transceiver *);
+#if defined(CONFIG_NOP_USB_XCEIV)
/* sometimes transceivers are accessed only through e.g. ULPI */
extern void usb_nop_xceiv_register(void);
extern void usb_nop_xceiv_unregister(void);
+#else
+static inline void usb_nop_xceiv_register(void)
+{
+}
+
+static inline void usb_nop_xceiv_unregister(void)
+{
+}
+#endif
/* helpers for direct access thru low-level io interface */
static inline int otg_io_read(struct otg_transceiver *otg, u32 reg)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] ARM : OMAP : Remove #ifdef from board-omap3evm.c
ARM : OMAP : Remove #ifdef from board-omap3evm.c
Remove #ifdef around usb_nop_xceiv_register() from
board-omap3evm.c
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Olof Johansson o...@lixom.net
---
Index: felipe_musb/arch/arm/mach-omap2/board-omap3evm.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-omap3evm.c
+++ felipe_musb/arch/arm/mach-omap2/board-omap3evm.c
@@ -444,10 +444,10 @@ static void __init omap3_evm_init(void)
ARRAY_SIZE(omap3evm_spi_board_info));
omap_serial_init();
-#ifdef CONFIG_NOP_USB_XCEIV
+
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
usb_nop_xceiv_register();
-#endif
+
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
omap_mux_init_gpio(22, OMAP_PIN_INPUT_PULLUP);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
On Wed, Dec 30, 2009 at 7:07 AM, Tony Lindgren t...@atomide.com wrote: * Magnus Damm magnus.d...@gmail.com [091227 21:54]: arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work Are you seeing the occasional crc errors when uncompressing the new kernel on your v7? Nope, it's very stable. I boot over USB with kexec for all my ARM kernel development and I have not seen any issues so far. I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if I do an extra (and wrong) flush_cache_all after local_flush_tlb_all at the end of setup_mm_for_reboot. My second kernel does not need any workaround, however... If you're not seeing the crc errors, do you have L2 cache on? I'm not sure at this point, but I think L2 is disabled. Will try to turn it on. Also, what's the Cortex version on your v7? It's rev r2p3 on omap3430. The data sheet of sh7377 says r2p3 as well. Cheers, / magnus -- 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: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
Hello Vishwanath,
On Tue, Jan 05, 2010 at 09:16:22AM +0100, ext Sripathy, Vishwanath wrote:
-Original Message-
From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
Sent: Tuesday, January 05, 2010 1:06 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Woodruff, Richard; Menon,
Nishanth
Subject: Re: [PATCHV4 1/3] OMAP3: introduce DPLL4 Jtype
Hello,
Few little comments bellow.
On Tue, Jan 05, 2010 at 07:36:08AM +0100, ext Vishwanath BS wrote:
DPLL4 for 3630 introduces a changed block requiring special divisor
bits and additional reg fields. To allow for silicons to use this, this
is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630
^
I don't see anywhere in this patch a reference to this function/macro
Yes, omap3_has_jtype_dpll4 is no longer used. This description is borrowed
from previous version of the patch. I will correct it.
OK. Nice.
silicon. Also FREQSEL field is no longer valid for OMAP3630. So reference
to this is removed for 3630.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h |3 ++
arch/arm/mach-omap2/clock34xx_data.c|2 +
arch/arm/mach-omap2/clock44xx_data.c|1 +
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/dpll.c | 53
--
arch/arm/plat-omap/include/plat/clock.h |1 +
6 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..14f73e7 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,9 @@
#define DPLL_LOW_POWER_BYPASS0x5
#define DPLL_LOCKED 0x7
+/*DPLL Type and DCO Selection Flags*/
+#define DPLL_J_TYPE 0x1
+#define DPLL_NO_DCO_SEL 0x2
Add blank line here, just to make it cleaner.
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-
omap2/clock34xx_data.c
index 043caed..9aac354 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3241,6 +3241,8 @@ int __init omap2_clk_init(void)
cpu_clkflg |= CK_3430ES2;
}
}
+ if (cpu_is_omap3630())
+ dpll4_ck.dpll_data-flags |= DPLL_J_TYPE;
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index 2210e22..7347246 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2736,6 +2736,7 @@ int __init omap2_clk_init(void)
if (cpu_is_omap44xx()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
+ dpll_usb_ck.dpll_data-flags |= DPLL_NO_DCO_SEL | DPLL_J_TYPE;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-
regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT 8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK(0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK(0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index f6055b4..d52ab37 100644
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -238,6 +238,42 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
}
/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd;
Re: [PATCH 08/10] video/omap: add __init/__exit macros to drivers/video/omap/lcd_htcherald.c
On Tue, 22 Dec 2009, peterhu...@gmx.de wrote:
From: Peter Huewe peterhu...@gmx.de
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of
drivers/video/omap/lcd_htcherald.c
Please have a look at the small patch and either pull it through
your tree, or please ack' it so Jiri can pull it through the trivial
tree.
Patch against linux-next-tree, 22. Dez 08:38:18 CET 2009
but also present in linus tree.
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/video/omap/lcd_htcherald.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap/lcd_htcherald.c
b/drivers/video/omap/lcd_htcherald.c
index a9007c5..4802419 100644
--- a/drivers/video/omap/lcd_htcherald.c
+++ b/drivers/video/omap/lcd_htcherald.c
@@ -115,12 +115,12 @@ struct platform_driver htcherald_panel_driver = {
},
};
-static int htcherald_panel_drv_init(void)
+static int __init htcherald_panel_drv_init(void)
{
return platform_driver_register(htcherald_panel_driver);
}
-static void htcherald_panel_drv_cleanup(void)
+static void __exit htcherald_panel_drv_cleanup(void)
{
platform_driver_unregister(htcherald_panel_driver);
}
Doesn't seem to be in linux-next as of today. Applied myself, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAP2 clock: dynamically allocate CPUFreq frequency table
Hi,
On Tue, Jan 05, 2010 at 03:42:07AM +0100, ext Paul Walmsley wrote:
@@ -470,21 +472,51 @@ void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
if (prcm-dpll_speed == prcm-xtal_speed)
continue;
+ tbl_sz++;
+ }
+
+ /*
+* XXX Ensure that we're doing what CPUFreq expects for this error
+* case and the following one
+*/
+ if (tbl_sz == 0) {
+ pr_warning(%s: no matching entries in rate_table\n,
+ __func__);
+ goto ocict_exit;
you only use this ocict_exit here, so how about only return instead of a
goto to a return ?
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table
On Tue, Jan 05, 2010 at 03:42:08AM +0100, ext Paul Walmsley wrote: OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array, so this patch ensures that it is freed if CPUFreq terminates. wasn't this introduced by the previous patch ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP2: clock: clk2xxx.c doesn't compile if CPUFREQ is enabled
Hi,
On Tue, Jan 05, 2010 at 03:42:05AM +0100, ext Paul Walmsley wrote:
From: Felipe Balbi felipe.ba...@nokia.com
if we enable CPUFREQ we can't build omap2 for two reasons,
one of them is fixed by the patch below.
It's failing because the __must_be_array() check in
ARRAY_SIZE() is failing and printing the following message:
arch/arm/mach-omap2/clock2xxx.c:453: error: negative width in bit-field
'anonymous'
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
[p...@pwsan.com: commit message updated; changed rate variable name]
and you forgot to change the variable definition...
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock2xxx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index d0e3fb7..2f3c3ba 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -455,12 +455,15 @@ static struct cpufreq_frequency_table
freq_table[ARRAY_SIZE(rate_table)];
void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
struct prcm_config *prcm;
+ long rate;
int i = 0;
+ sys_ck_rate = clk_get_rate(sclk);
The variable defined is called rate but you use sys_ck_rate.
I used rate, because that's what other functions are using and
I wanted to keep the code consistent. Anyways, as is now this patch
won't compile again :-p
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] USB: Add empty functions in otg.h
On Tue, Jan 05, 2010 at 09:46:58AM +0100, ext Maulik Mankad wrote: USB : Add empty functions in otg.h Add empty functions for usb_nop_xceiv_register() and usb_nop_xceiv_unregister() in otg.h so that these functions can be called even when CONFIG_NOP_USB_XCEIV is not enabled. It allows to remove ifdef's from board file. Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Felipe Balbi felipe.ba...@nokia.com Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Now this patch looks ok. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM : OMAP : Remove #ifdef from board-omap3evm.c
On Tue, Jan 05, 2010 at 09:49:32AM +0100, ext Maulik Mankad wrote: ARM : OMAP : Remove #ifdef from board-omap3evm.c Remove #ifdef around usb_nop_xceiv_register() from board-omap3evm.c Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Acked-by: Felipe Balbi felipe.ba...@nokia.com Tony, let's wait for Greg's Ack to the previous patch, but if everything is Fine, you can take this one on for-next. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + drivers-video-omap2-dss-rfbic-port-to-new-kfifo-api.patch added to -mm tree
On Tue, 2010-01-05 at 00:07 +0100, ext a...@linux-foundation.org wrote: The patch titled drivers/video/omap2/dss/rfbi.c: port to new kfifo API has been added to the -mm tree. Its filename is drivers-video-omap2-dss-rfbic-port-to-new-kfifo-api.patch Before you just go and hit reply, please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: drivers/video/omap2/dss/rfbi.c: port to new kfifo API From: Stefani Seibold stef...@seibold.net Port drivers/video/omap2/dss/rfbi.c to the new kfifo API. This should be the last one. Signed-off-by: Stefani Seibold stef...@seibold.net Cc: Tomi Valkeinen tomi.valkei...@nokia.com Cc: Greg KH g...@kroah.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/video/omap2/dss/rfbi.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) This patch is not correct, rfbi.c doesn't compile. I made a patch for this yesterday, and if it's ok for everyone, I'll put that patch into my dss tree, and this patch can be discarded. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
On Tue, Dec 29, 2009 at 02:07:05PM -0800, Tony Lindgren wrote: Hi, * Magnus Damm magnus.d...@gmail.com [091227 21:54]: Hi Tony, On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren t...@atomide.com wrote: Here are some v7 fixes, mostly to make kexec work. Using 2.6.33-rc1, these fixes, and kexec from kexec-tools git repo, I can reboot my n900 in a loop reliably. Thanks for your work on this. I previously tested kexec on ARM V6 and V7 and noticed that V7 didn't work. I revisited my V7 test after becoming aware of your patches. The single patch below unbreaks V7 on my target system. arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work Cool. Thank you for fixing the kexec source :) Are you seeing the occasional crc errors when uncompressing the new kernel on your v7? I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if I do an extra (and wrong) flush_cache_all after local_flush_tlb_all at the end of setup_mm_for_reboot. Hi, I've also been playing with this patch. One thing I noticed is that If I disable L2 cache in cpu_v7_proc_fin() then kexec works fine and no crc errors from decompressor (I did ~30 kexec boots). With L2 cache enabled, it fails almost immediately. Tested with OMAP3430 ES3.1. Thanks, MW -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: defconfig: rx51: enable phonet and g_nokia
trivial patch enabling g_nokia on rx51_defconfig. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/configs/rx51_defconfig | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig index b6eeebb..72e27d8 100644 --- a/arch/arm/configs/rx51_defconfig +++ b/arch/arm/configs/rx51_defconfig @@ -445,6 +445,8 @@ CONFIG_IP_NF_FILTER=m # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set +CONFIG_PHONET=y +# CONFIG_IEEE802154 is not set # CONFIG_NET_SCHED is not set # CONFIG_DCB is not set @@ -1325,27 +1327,34 @@ CONFIG_USB_GADGET_SELECTED=y # CONFIG_USB_GADGET_LH7A40X is not set # CONFIG_USB_GADGET_OMAP is not set # CONFIG_USB_GADGET_PXA25X is not set +# CONFIG_USB_GADGET_R8A66597 is not set # CONFIG_USB_GADGET_PXA27X is not set -# CONFIG_USB_GADGET_S3C2410 is not set +# CONFIG_USB_GADGET_S3C_HSOTG is not set # CONFIG_USB_GADGET_IMX is not set +# CONFIG_USB_GADGET_S3C2410 is not set # CONFIG_USB_GADGET_M66592 is not set # CONFIG_USB_GADGET_AMD5536UDC is not set # CONFIG_USB_GADGET_FSL_QE is not set # CONFIG_USB_GADGET_CI13XXX is not set # CONFIG_USB_GADGET_NET2280 is not set # CONFIG_USB_GADGET_GOKU is not set +# CONFIG_USB_GADGET_LANGWELL is not set # CONFIG_USB_GADGET_DUMMY_HCD is not set CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_ZERO=m # CONFIG_USB_ZERO_HNPTEST is not set +# CONFIG_USB_AUDIO is not set # CONFIG_USB_ETH is not set # CONFIG_USB_GADGETFS is not set CONFIG_USB_FILE_STORAGE=m # CONFIG_USB_FILE_STORAGE_TEST is not set +# CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set +CONFIG_USB_G_NOKIA=m +# CONFIG_USB_G_MULTI is not set # # OTG and related infrastructure -- 1.6.6.rc0 -- 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/2] usb: gadget: introduce g_nokia gadget driver
g_nokia is the gadget driver implementing
WMCDC Wireless Handset Control Model for the N900
device.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/usb/gadget/Kconfig | 10 ++
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/nokia.c | 259 +++
3 files changed, 271 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/nokia.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index ee41120..7460cd7 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -812,6 +812,16 @@ config USB_CDC_COMPOSITE
Say y to link the driver statically, or m to build a
dynamically linked module.
+config USB_G_NOKIA
+ tristate Nokia composite gadget
+ depends on PHONET
+ help
+ The Nokia composite gadget provides support for acm, obex
+ and phonet in only one composite gadget driver.
+
+ It's only really useful for N900 hardware. If you're building
+ a kernel for N900, say Y or M here. If unsure, say N.
+
config USB_G_MULTI
tristate Multifunction Composite Gadget (EXPERIMENTAL)
depends on BLOCK NET
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 2e2c047..43b51da 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -43,6 +43,7 @@ g_mass_storage-objs := mass_storage.o
g_printer-objs := printer.o
g_cdc-objs := cdc2.o
g_multi-objs := multi.o
+g_nokia-objs := nokia.o
obj-$(CONFIG_USB_ZERO) += g_zero.o
obj-$(CONFIG_USB_AUDIO)+= g_audio.o
@@ -55,4 +56,5 @@ obj-$(CONFIG_USB_G_PRINTER) += g_printer.o
obj-$(CONFIG_USB_MIDI_GADGET) += g_midi.o
obj-$(CONFIG_USB_CDC_COMPOSITE) += g_cdc.o
obj-$(CONFIG_USB_G_MULTI) += g_multi.o
+obj-$(CONFIG_USB_G_NOKIA) += g_nokia.o
diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c
new file mode 100644
index 000..7d6b66a
--- /dev/null
+++ b/drivers/usb/gadget/nokia.c
@@ -0,0 +1,259 @@
+/*
+ * nokia.c -- Nokia Composite Gadget Driver
+ *
+ * Copyright (C) 2008-2010 Nokia Corporation
+ * Contact: Felipe Balbi felipe.ba...@nokia.com
+ *
+ * This gadget driver borrows from serial.c which is:
+ *
+ * Copyright (C) 2003 Al Borchers (alborch...@steinerpoint.com)
+ * Copyright (C) 2008 by David Brownell
+ * Copyright (C) 2008 by Nokia Corporation
+ *
+ * This software is distributed under the terms of the GNU General
+ * Public License (GPL) as published by the Free Software Foundation,
+ * version 2 of that License.
+ */
+
+#include linux/kernel.h
+#include linux/utsname.h
+#include linux/device.h
+
+#include u_serial.h
+#include u_ether.h
+#include u_phonet.h
+#include gadget_chips.h
+
+/* Defines */
+
+#define NOKIA_VERSION_NUM 0x0211
+#define NOKIA_LONG_NAMEN900 (PC-Suite Mode)
+
+/*-*/
+
+/*
+ * Kbuild is not very cooperative with respect to linking separately
+ * compiled library objects into one module. So for now we won't use
+ * separate compilation ... ensuring init/exit sections work to shrink
+ * the runtime footprint, and giving us at least some parts of what
+ * a gcc --combine ... part1.c part2.c part3.c ... build would.
+ */
+#include composite.c
+#include usbstring.c
+#include config.c
+#include epautoconf.c
+
+#include u_serial.c
+#include f_acm.c
+#include f_ecm.c
+#include f_obex.c
+#include f_serial.c
+#include f_phonet.c
+#include u_ether.c
+
+/*-*/
+
+#define NOKIA_VENDOR_ID0x0421 /* Nokia */
+#define NOKIA_PRODUCT_ID 0x01c8 /* Nokia Gadget */
+
+/* string IDs are assigned dynamically */
+
+#define STRING_MANUFACTURER_IDX0
+#define STRING_PRODUCT_IDX 1
+#define STRING_DESCRIPTION_IDX 2
+
+static char manufacturer_nokia[] = Nokia;
+static const char product_nokia[] = NOKIA_LONG_NAME;
+static const char description_nokia[] = PC-Suite Configuration;
+
+static struct usb_string strings_dev[] = {
+ [STRING_MANUFACTURER_IDX].s = manufacturer_nokia,
+ [STRING_PRODUCT_IDX].s = NOKIA_LONG_NAME,
+ [STRING_DESCRIPTION_IDX].s = description_nokia,
+ { } /* end of list */
+};
+
+static struct usb_gadget_strings stringtab_dev = {
+ .language = 0x0409, /* en-us */
+ .strings= strings_dev,
+};
+
+static struct usb_gadget_strings *dev_strings[] = {
+ stringtab_dev,
+ NULL,
+};
+
+static struct usb_device_descriptor device_desc = {
+ .bLength= USB_DT_DEVICE_SIZE,
+ .bDescriptorType= USB_DT_DEVICE,
+ .bcdUSB = __constant_cpu_to_le16(0x0200),
+ .bDeviceClass = USB_CLASS_COMM,
+ .idVendor
Re: [PATCH 4/4] OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table
On Tue, 5 Jan 2010, Felipe Balbi wrote: On Tue, Jan 05, 2010 at 03:42:08AM +0100, ext Paul Walmsley wrote: OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array, so this patch ensures that it is freed if CPUFreq terminates. wasn't this introduced by the previous patch ? The dynamically-allocated array? Yes. Your point being? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP2: clock: clk2xxx.c doesn't compile if CPUFREQ is enabled
On Tue, 5 Jan 2010, Felipe Balbi wrote: and you forgot to change the variable definition... Thanks, looks like I sent an older version of the series. I will resend. The variable defined is called rate but you use sys_ck_rate. I used rate, because that's what other functions are using and I wanted to keep the code consistent. Did you examine the other functions omap2_round_to_table_rate() and omap2_select_table_rate()? What advantage is there to keeping this variable named rate, which is less specific given that this function also deals with DPLL rates, MPU rates, and crystal rates? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAP2 clock: dynamically allocate CPUFreq frequency table
On Tue, 5 Jan 2010, Felipe Balbi wrote:
On Tue, Jan 05, 2010 at 03:42:07AM +0100, ext Paul Walmsley wrote:
@@ -470,21 +472,51 @@ void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
if (prcm-dpll_speed == prcm-xtal_speed)
continue;
+ tbl_sz++;
+ }
+
+ /*
+* XXX Ensure that we're doing what CPUFreq expects for this error
+* case and the following one
+*/
+ if (tbl_sz == 0) {
+ pr_warning(%s: no matching entries in rate_table\n,
+ __func__);
+ goto ocict_exit;
you only use this ocict_exit here, so how about only return instead of a goto
to a return ?
It's used twice. But your latter point is a good one. I will change
that.
- Paul
--
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
Question about omap_hsmmc driver
Hi all, I'm having problems trying to run the SDIO WLAN module on my IGEP v2 board using the latest omap kernel (2.6.33-rc2). The SDIO WLAN module is connected to the MMC2 using 4 wires. With an older kernel ( 2.6.28 ) works fine but the same configuration with 2.6.33-rc2 do not detect the SDIO card. Any idea to solve the problem ? There is a substantial modification in this driver. Any help will be appreciated. I attached the log. Thanks in advance, Enric [ 24.521484] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522003] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.522033] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED [ 24.522308] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522338] mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 65535 width 0 timing 0 [ 24.545104] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.568298] mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 65535 width 0 timing 0 [ 24.569335] mmc1: starting CMD0 arg flags 00c0 [ 24.569366] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x [ 24.569519] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1 [ 24.569549] mmc1: req done (CMD0): 0: [ 24.572540] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.573547] mmc1: starting CMD8 arg 00aa flags 02f5 [ 24.573577] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x00aa [ 24.573913] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.573913] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.573944] mmc1: req done (CMD8): -110: [ 24.575744] mmc1: starting CMD5 arg flags 02e1 [ 24.575775] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576110] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576141] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576171] mmc1: req failed (CMD5): -110, retrying... [ 24.576171] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576507] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576538] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576568] mmc1: req failed (CMD5): -110, retrying... [ 24.576568] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576904] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576934] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576934] mmc1: req failed (CMD5): -110, retrying... [ 24.576965] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.577301] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.577331] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.577331] mmc1: req done (CMD5): -110: [ 24.578247] mmc1: starting CMD55 arg flags 00f5 [ 24.578247] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.578582] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.578613] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.578643] mmc1: req done (CMD55): -110: [ 24.580444] mmc1: starting CMD55 arg flags 00f5 [ 24.580474] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.580810] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.580810] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.580841] mmc1: req done (CMD55): -110: [ 24.582641] mmc1: starting CMD55 arg flags 00f5 [ 24.582672] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.583007] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.583007] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.583038] mmc1: req done (CMD55): -110: [ 24.584899] mmc1: starting CMD55 arg flags 00f5 [ 24.584899] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.585235] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.585266] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.585296] mmc1: req done (CMD55): -110: [ 24.587097] mmc1: starting CMD1 arg flags 00e1 [ 24.587097] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x [ 24.587432] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.587463] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.587493] mmc1: req done (CMD1): -110: [ 24.589294] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.623962] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED -- 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
[PATCH] omap: make serial_in_override() address the right uart port
Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e makes it possible to
have some other than first uart port as ttyS0, which breaks the workaround
serial_in_override() function which will try to address the first uart
port (for ttyS0) and not the one that was initialized.
Signed-off-by: Alexander Shishkin virtu...@slind.org
CC: Mika Westerberg ext-mika.1.westerb...@nokia.com
CC: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 19805a7..8c964be 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -125,6 +125,13 @@ static struct plat_serial8250_port serial_platform_data3[]
= {
}
};
#endif
+static inline unsigned int __serial_read_reg(struct uart_port *up,
+ int offset)
+{
+ offset = up-regshift;
+ return (unsigned int)__raw_readb(up-membase + offset);
+}
+
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -583,11 +590,12 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
{
if (UART_RX == offset) {
unsigned int lsr;
- lsr = serial_read_reg(omap_uart[up-line].p, UART_LSR);
+ lsr = __serial_read_reg(up, UART_LSR);
if (!(lsr UART_LSR_DR))
return -EPERM;
}
- return serial_read_reg(omap_uart[up-line].p, offset);
+
+ return __serial_read_reg(up, offset);
}
void __init omap_serial_early_init(void)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] omap i2c: make errata 1.153 workaround a separate function
On Mon, Dec 21, 2009 at 01:29:58 +0200, Alexander Shishkin wrote: This is to avoid insanely long lines and levels of indentation. Ben, do you want me to resend these with Tony's acks or can you consider applying them? Regards, -- Alex -- 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: Question about omap_hsmmc driver
Hi Enric, You see from the log there is a timeout on CMD5. This could happen because of multiple reasons. One of them is muxing of CMD/CLK lines. Or it could be due to negotiation of voltage. I would look at these things first. Regards, Madhu From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Tuesday, January 05, 2010 10:44 AM To: linux-omap@vger.kernel.org; madhu...@ti.com Subject: Question about omap_hsmmc driver Hi all, I'm having problems trying to run the SDIO WLAN module on my IGEP v2 board using the latest omap kernel (2.6.33-rc2). The SDIO WLAN module is connected to the MMC2 using 4 wires. With an older kernel ( 2.6.28 ) works fine but the same configuration with 2.6.33-rc2 do not detect the SDIO card. Any idea to solve the problem ? There is a substantial modification in this driver. Any help will be appreciated. I attached the log. Thanks in advance, Enric [ 24.521484] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522003] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.522033] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED [ 24.522308] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522338] mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 65535 width 0 timing 0 [ 24.545104] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.568298] mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 65535 width 0 timing 0 [ 24.569335] mmc1: starting CMD0 arg flags 00c0 [ 24.569366] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x [ 24.569519] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1 [ 24.569549] mmc1: req done (CMD0): 0: [ 24.572540] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.573547] mmc1: starting CMD8 arg 00aa flags 02f5 [ 24.573577] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x00aa [ 24.573913] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.573913] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.573944] mmc1: req done (CMD8): -110: [ 24.575744] mmc1: starting CMD5 arg flags 02e1 [ 24.575775] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576110] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576141] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576171] mmc1: req failed (CMD5): -110, retrying... [ 24.576171] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576507] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576538] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576568] mmc1: req failed (CMD5): -110, retrying... [ 24.576568] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576904] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576934] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576934] mmc1: req failed (CMD5): -110, retrying... [ 24.576965] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.577301] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.577331] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.577331] mmc1: req done (CMD5): -110: [ 24.578247] mmc1: starting CMD55 arg flags 00f5 [ 24.578247] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.578582] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.578613] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.578643] mmc1: req done (CMD55): -110: [ 24.580444] mmc1: starting CMD55 arg flags 00f5 [ 24.580474] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.580810] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.580810] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.580841] mmc1: req done (CMD55): -110: [ 24.582641] mmc1: starting CMD55 arg flags 00f5 [ 24.582672] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.583007] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.583007] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.583038] mmc1: req done (CMD55): -110: [ 24.584899] mmc1: starting CMD55 arg flags 00f5 [ 24.584899] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.585235] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.585266] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.585296] mmc1: req done (CMD55): -110: [ 24.587097] mmc1: starting CMD1 arg flags 00e1 [ 24.587097] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x [ 24.587432] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [
Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
* Mika Westerberg mika.westerb...@iki.fi [100105 03:34]: On Tue, Dec 29, 2009 at 02:07:05PM -0800, Tony Lindgren wrote: Hi, * Magnus Damm magnus.d...@gmail.com [091227 21:54]: Hi Tony, On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren t...@atomide.com wrote: Here are some v7 fixes, mostly to make kexec work. Using 2.6.33-rc1, these fixes, and kexec from kexec-tools git repo, I can reboot my n900 in a loop reliably. Thanks for your work on this. I previously tested kexec on ARM V6 and V7 and noticed that V7 didn't work. I revisited my V7 test after becoming aware of your patches. The single patch below unbreaks V7 on my target system. arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work Cool. Thank you for fixing the kexec source :) Are you seeing the occasional crc errors when uncompressing the new kernel on your v7? I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if I do an extra (and wrong) flush_cache_all after local_flush_tlb_all at the end of setup_mm_for_reboot. Hi, I've also been playing with this patch. One thing I noticed is that If I disable L2 cache in cpu_v7_proc_fin() then kexec works fine and no crc errors from decompressor (I did ~30 kexec boots). With L2 cache enabled, it fails almost immediately. Tested with OMAP3430 ES3.1. OK cool. I thought disabling the caches should also disable L2, but looks like not then. Regards, Tony -- 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: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 breaks omapfb (old non-dss2)
Hi Tomi, On Tue, 15 Dec 2009, Tomi Valkeinen wrote: On Tue, 2009-12-15 at 10:58 +0100, ext Sergey Lapin wrote: dadd2bb931a08a4b6b17f9e82d9bbe7bedebbc98 OMAP: OMAPFB: add omapdss device The upcoming new display subsystem driver is divided to two devices, omapdss and omapfb, of which omapdss handles the actual hardware. This patch adds a dummy omapdss platform device for the current omapfb driver, which is then used to get the clocks. This will make it possible for the current and the new display drivers to co-exist. Signed-off-by: Tomi Valkeinen tomi.valkei...@nokia.com Acked-by: Tony Lindgren t...@atomide.com breaks old omapfb. I didn't look at this further, but I quickly tested with OMAP3 SDP board, reverting the patch that makes SDP use DSS2, and it seems to work fine with the old omapfb. Perhaps you have more kernel debug options enabled, and then it complains about missing release function. I'll look at it tomorrow. This also affects omap_2430sdp_defconfig on 2430SDP: omapfb omapfb: timeout waiting for FRAME DONE [ cut here ] WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c() Device 'omapdss' does not have a release() function, it is broken and must be fixed. Modules linked in: [c002c748] (unwind_backtrace+0x0/0xdc) from [c0049874] (warn_slowpath_common+0x48/0x60) [c0049874] (warn_slowpath_common+0x48/0x60) from [c00498c4] (warn_slowpath_fmt+0x24/0x30) [c00498c4] (warn_slowpath_fmt+0x24/0x30) from [c01b0544] (device_release+0x68/0x7c) [c01b0544] (device_release+0x68/0x7c) from [c01706a8] (kobject_release+0x60/0x74) [c01706a8] (kobject_release+0x60/0x74) from [c01713c4] (kref_put+0x5c/0x6c) [c01713c4] (kref_put+0x5c/0x6c) from [c018df44] (omapfb_free_resources+0xec/0x130) [c018df44] (omapfb_free_resources+0xec/0x130) from [c018f030] (omapfb_do_probe+0x6dc/0x810) [c018f030] (omapfb_do_probe+0x6dc/0x810) from [c0191088] (sdp2430_panel_probe+0xc/0x18) [c0191088] (sdp2430_panel_probe+0xc/0x18) from [c01b3f24] (platform_drv_probe+0x18/0x1c) [c01b3f24] (platform_drv_probe+0x18/0x1c) from [c01b3114] (driver_probe_device+0xa0/0x14c) [c01b3114] (driver_probe_device+0xa0/0x14c) from [c01b3220] (__driver_attach+0x60/0x84) [c01b3220] (__driver_attach+0x60/0x84) from [c01b2990] (bus_for_each_dev+0x44/0x74) [c01b2990] (bus_for_each_dev+0x44/0x74) from [c01b22e8] (bus_add_driver+0x9c/0x224) [c01b22e8] (bus_add_driver+0x9c/0x224) from [c01b34f4] (driver_register+0xa8/0x130) [c01b34f4] (driver_register+0xa8/0x130) from [c0026364] (do_one_initcall+0x5c/0x1b4) [c0026364] (do_one_initcall+0x5c/0x1b4) from [c0008408] (kernel_init+0xa0/0x124) [c0008408] (kernel_init+0xa0/0x124) from [c0027ed4] (kernel_thread_exit+0x0/0x8) ---[ end trace da227214a82491b7 ]--- - Paul -- 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 v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up
Hello, This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi felipe.ba...@nokia.com. Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at: http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/ Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP. This second version also incorporates some comments from Felipe. - Paul --- Felipe Balbi (1): OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled Paul Walmsley (3): OMAP2xxx OPP: clean up comments in OPP data OMAP2 clock: dynamically allocate CPUFreq frequency table OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table arch/arm/mach-omap2/clock2xxx.c | 57 ++- arch/arm/mach-omap2/opp2420_data.c | 38 +++-- arch/arm/mach-omap2/opp2430_data.c | 30 arch/arm/plat-omap/clock.c | 10 + arch/arm/plat-omap/cpu-omap.c |1 + arch/arm/plat-omap/include/plat/clock.h |2 + 6 files changed, 96 insertions(+), 42 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled
From: Felipe Balbi felipe.ba...@nokia.com
if we enable CPUFREQ we can't build omap2 for two reasons,
one of them is fixed by the patch below.
It's failing because the __must_be_array() check in
ARRAY_SIZE() is failing and printing the following message:
arch/arm/mach-omap2/clock2xxx.c:453: error: negative width in bit-field
'anonymous'
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
[p...@pwsan.com: commit message updated; changed rate variable name]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock2xxx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index d0e3fb7..ce6742f 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -455,12 +455,15 @@ static struct cpufreq_frequency_table
freq_table[ARRAY_SIZE(rate_table)];
void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
struct prcm_config *prcm;
+ long sys_ck_rate;
int i = 0;
+ sys_ck_rate = clk_get_rate(sclk);
+
for (prcm = rate_table; prcm-mpu_speed; prcm++) {
if (!(prcm-flags cpu_mask))
continue;
- if (prcm-xtal_speed != sys_ck.rate)
+ if (prcm-xtal_speed != sys_ck_rate)
continue;
/* don't put bypass rates in table */
--
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 v2 3/4] OMAP2 clock: dynamically allocate CPUFreq frequency table
Dynamically allocate the CPUFreq frequency table on OMAP2xxx chips.
This fixes some compilation problems, since the kernel may not know
what chip it is running on until boot-time. This also reduces the size
of the CPUFreq frequency table.
Problem reported by Felipe Balbi felipe.ba...@nokia.com. Thanks also
for comments on the patch from Felipe.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/clock2xxx.c | 45 ---
1 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index ce6742f..3bfd045 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -449,14 +449,16 @@ int omap2_select_table_rate(struct clk *clk, unsigned
long rate)
#ifdef CONFIG_CPU_FREQ
/*
* Walk PRCM rate table and fillout cpufreq freq_table
+ * XXX This should be replaced by an OPP layer in the near future
*/
-static struct cpufreq_frequency_table freq_table[ARRAY_SIZE(rate_table)];
+static struct cpufreq_frequency_table *freq_table;
void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
- struct prcm_config *prcm;
+ const struct prcm_config *prcm;
long sys_ck_rate;
int i = 0;
+ int tbl_sz = 0;
sys_ck_rate = clk_get_rate(sclk);
@@ -470,17 +472,44 @@ void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
if (prcm-dpll_speed == prcm-xtal_speed)
continue;
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-mpu_speed / 1000;
- i++;
+ tbl_sz++;
}
- if (i == 0) {
- printk(KERN_WARNING %s: failed to initialize frequency
- table\n, __func__);
+ /*
+* XXX Ensure that we're doing what CPUFreq expects for this error
+* case and the following one
+*/
+ if (tbl_sz == 0) {
+ pr_warning(%s: no matching entries in rate_table\n,
+ __func__);
return;
}
+ /* Include the CPUFREQ_TABLE_END terminator entry */
+ tbl_sz++;
+
+ freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) * tbl_sz,
+GFP_KERNEL);
+ if (!freq_table) {
+ pr_err(%s: could not kzalloc frequency table\n, __func__);
+ return;
+ }
+
+ for (prcm = rate_table; prcm-mpu_speed; prcm++) {
+ if (!(prcm-flags cpu_mask))
+ continue;
+ if (prcm-xtal_speed != sys_ck_rate)
+ continue;
+
+ /* don't put bypass rates in table */
+ if (prcm-dpll_speed == prcm-xtal_speed)
+ continue;
+
+ freq_table[i].index = i;
+ freq_table[i].frequency = prcm-mpu_speed / 1000;
+ i++;
+ }
+
freq_table[i].index = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
--
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 v2 4/4] OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table
OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array,
so this patch ensures that it is freed if CPUFreq terminates.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock2xxx.c |7 +++
arch/arm/plat-omap/clock.c | 10 ++
arch/arm/plat-omap/cpu-omap.c |1 +
arch/arm/plat-omap/include/plat/clock.h |2 ++
4 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index 3bfd045..74f5586 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -515,6 +515,12 @@ void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
*table = freq_table[0];
}
+
+void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+ kfree(freq_table);
+}
+
#endif
struct clk_functions omap2_clk_functions = {
@@ -526,6 +532,7 @@ struct clk_functions omap2_clk_functions = {
.clk_disable_unused = omap2_clk_disable_unused,
#ifdef CONFIG_CPU_FREQ
.clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
+ .clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
#endif
};
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index a64d84c..d9f8c84 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -329,6 +329,16 @@ void clk_init_cpufreq_table(struct cpufreq_frequency_table
**table)
arch_clock-clk_init_cpufreq_table(table);
spin_unlock_irqrestore(clockfw_lock, flags);
}
+
+void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ if (arch_clock-clk_exit_cpufreq_table)
+ arch_clock-clk_exit_cpufreq_table(table);
+ spin_unlock_irqrestore(clockfw_lock, flags);
+}
#endif
/*-*/
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index f8ddbdd..6d3d333 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -134,6 +134,7 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
+ clk_exit_cpufreq_table(freq_table);
clk_put(mpu_clk);
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 309b6d1..94fe2a0 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -119,6 +119,7 @@ struct clk_functions {
void(*clk_disable_unused)(struct clk *clk);
#ifdef CONFIG_CPU_FREQ
void(*clk_init_cpufreq_table)(struct
cpufreq_frequency_table **);
+ void(*clk_exit_cpufreq_table)(struct
cpufreq_frequency_table **);
#endif
};
@@ -135,6 +136,7 @@ extern unsigned long followparent_recalc(struct clk *clk);
extern void clk_enable_init_clocks(void);
#ifdef CONFIG_CPU_FREQ
extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
+extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
#endif
extern const struct clkops clkops_null;
--
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 v2 2/4] OMAP2xxx OPP: clean up comments in OPP data
Revise some of the comments in the OMAP2xxx OPP data for clarity.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
---
arch/arm/mach-omap2/opp2420_data.c | 38 +++-
arch/arm/mach-omap2/opp2430_data.c | 30 ++--
2 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/opp2420_data.c
b/arch/arm/mach-omap2/opp2420_data.c
index 126a939..e6dda69 100644
--- a/arch/arm/mach-omap2/opp2420_data.c
+++ b/arch/arm/mach-omap2/opp2420_data.c
@@ -9,45 +9,47 @@
* The OMAP2 processor can be run at several discrete 'PRCM configurations'.
* These configurations are characterized by voltage and speed for clocks.
* The device is only validated for certain combinations. One way to express
- * these combinations is via the 'ratio's' which the clocks operate with
+ * these combinations is via the 'ratios' which the clocks operate with
* respect to each other. These ratio sets are for a given voltage/DPLL
- * setting. All configurations can be described by a DPLL setting and a ratio
- * There are 3 ratio sets for the 2430 and X ratio sets for 2420.
- *
- * 2430 differs from 2420 in that there are no more phase synchronizers used.
- * They both have a slightly different clock domain setup. 2420(iva1,dsp) vs
- * 2430 (iva2.1, NOdsp, mdm)
+ * setting. All configurations can be described by a DPLL setting and a ratio.
*
* XXX Missing voltage data.
+ * XXX Missing 19.2MHz sys_clk rate sets (needed for N800/N810)
*
* THe format described in this file is deprecated. Once a reasonable
* OPP API exists, the data in this file should be converted to use it.
*
* This is technically part of the OMAP2xxx clock code.
+ *
+ * Considerable work is still needed to fully support dynamic frequency
+ * changes on OMAP2xxx-series chips. Readers interested in such a
+ * project are encouraged to review the Maemo Diablo RX-34 and RX-44
+ * kernel source at:
+ * http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/
*/
#include opp2xxx.h
#include sdrc.h
#include clock.h
-/*-
- * Key dividers which make up a PRCM set. Ratio's for a PRCM are mandated.
+/*
+ * Key dividers which make up a PRCM set. Ratios for a PRCM are mandated.
* xtal_speed, dpll_speed, mpu_speed, CM_CLKSEL_MPU,
* CM_CLKSEL_DSP, CM_CLKSEL_GFX, CM_CLKSEL1_CORE, CM_CLKSEL1_PLL,
* CM_CLKSEL2_PLL, CM_CLKSEL_MDM
*
- * Filling in table based on H4 boards and 2430-SDPs variants available.
- * There are quite a few more rates combinations which could be defined.
+ * Filling in table based on H4 boards available. There are quite a
+ * few more rate combinations which could be defined.
*
- * When multiple values are defined the start up will try and choose the
- * fastest one. If a 'fast' value is defined, then automatically, the /2
- * one should be included as it can be used. Generally having more that
- * one fast set does not make sense, as static timings need to be changed
- * to change the set. The exception is the bypass setting which is
- * availble for low power bypass.
+ * When multiple values are defined the start up will try and choose
+ * the fastest one. If a 'fast' value is defined, then automatically,
+ * the /2 one should be included as it can be used. Generally having
+ * more than one fast set does not make sense, as static timings need
+ * to be changed to change the set. The exception is the bypass
+ * setting which is available for low power bypass.
*
* Note: This table needs to be sorted, fastest to slowest.
- *-*/
+ **/
const struct prcm_config omap2420_rate_table[] = {
/* PRCM I - FAST */
{S12M, S660M, S330M, RI_CM_CLKSEL_MPU_VAL, /* 330MHz ARM */
diff --git a/arch/arm/mach-omap2/opp2430_data.c
b/arch/arm/mach-omap2/opp2430_data.c
index edb8167..1b9596a 100644
--- a/arch/arm/mach-omap2/opp2430_data.c
+++ b/arch/arm/mach-omap2/opp2430_data.c
@@ -1,5 +1,5 @@
/*
- * opp2420_data.c - old-style OPP table for OMAP2420
+ * opp2430_data.c - old-style OPP table for OMAP2430
*
* Copyright (C) 2005-2009 Texas Instruments, Inc.
* Copyright (C) 2004-2009 Nokia Corporation
@@ -9,16 +9,16 @@
* The OMAP2 processor can be run at several discrete 'PRCM configurations'.
* These configurations are characterized by voltage and speed for clocks.
* The device is only validated for certain combinations. One way to express
- * these combinations is via the 'ratio's' which the clocks operate with
+ * these combinations is via the 'ratios' which the clocks operate with
* respect to each other. These ratio sets are for a given voltage/DPLL
- * setting. All configurations can be described by a DPLL setting and a ratio
- * There are 3 ratio sets for the 2430 and X ratio sets for 2420.
+ * setting. All configurations can be
Re: [PATCH v3 1/2] USB: Add empty functions in otg.h
On Tue, Jan 05, 2010 at 12:54:50PM +0200, Felipe Balbi wrote: On Tue, Jan 05, 2010 at 09:46:58AM +0100, ext Maulik Mankad wrote: USB : Add empty functions in otg.h Add empty functions for usb_nop_xceiv_register() and usb_nop_xceiv_unregister() in otg.h so that these functions can be called even when CONFIG_NOP_USB_XCEIV is not enabled. It allows to remove ifdef's from board file. Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Felipe Balbi felipe.ba...@nokia.com Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Now this patch looks ok. Don't you mean Acked-by? Anyway, also: Acked-by: Olof Johansson o...@lixom.net -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM : OMAP : Remove #ifdef from board-omap3evm.c
On Tue, Jan 05, 2010 at 02:19:32PM +0530, Maulik Mankad wrote: ARM : OMAP : Remove #ifdef from board-omap3evm.c Remove #ifdef around usb_nop_xceiv_register() from board-omap3evm.c Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Greg Kroah-Hartman gre...@suse.de Cc: Olof Johansson o...@lixom.net Acked-by: Olof Johansson o...@lixom.net -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
Hi, On Tue, 29 Dec 2009, Tony Lindgren wrote: Also, what's the Cortex version on your v7? It's rev r2p3 on omap3430. Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and below, and r1p7 on ES3.1.2. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: make serial_in_override() address the right uart port
* Alexander Shishkin virtu...@slind.org [100105 08:56]:
Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e makes it possible to
have some other than first uart port as ttyS0, which breaks the workaround
serial_in_override() function which will try to address the first uart
port (for ttyS0) and not the one that was initialized.
Nothing wrong with this patch.. But so we're back to having the ports move
around again? That sucks. I wonder if we can initialize dummy 8250 ports
somehow to keep the order correct to avoid confusion.
Regards,
Tony
Signed-off-by: Alexander Shishkin virtu...@slind.org
CC: Mika Westerberg ext-mika.1.westerb...@nokia.com
CC: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 19805a7..8c964be 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -125,6 +125,13 @@ static struct plat_serial8250_port
serial_platform_data3[] = {
}
};
#endif
+static inline unsigned int __serial_read_reg(struct uart_port *up,
+int offset)
+{
+ offset = up-regshift;
+ return (unsigned int)__raw_readb(up-membase + offset);
+}
+
static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
int offset)
{
@@ -583,11 +590,12 @@ static unsigned int serial_in_override(struct uart_port
*up, int offset)
{
if (UART_RX == offset) {
unsigned int lsr;
- lsr = serial_read_reg(omap_uart[up-line].p, UART_LSR);
+ lsr = __serial_read_reg(up, UART_LSR);
if (!(lsr UART_LSR_DR))
return -EPERM;
}
- return serial_read_reg(omap_uart[up-line].p, offset);
+
+ return __serial_read_reg(up, offset);
}
void __init omap_serial_early_init(void)
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up
* Paul Walmsley p...@pwsan.com [100105 09:35]: Hello, This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi felipe.ba...@nokia.com. Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at: http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/ Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP. This second version also incorporates some comments from Felipe. These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there? Regards, Tony - Paul --- Felipe Balbi (1): OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled Paul Walmsley (3): OMAP2xxx OPP: clean up comments in OPP data OMAP2 clock: dynamically allocate CPUFreq frequency table OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table arch/arm/mach-omap2/clock2xxx.c | 57 ++- arch/arm/mach-omap2/opp2420_data.c | 38 +++-- arch/arm/mach-omap2/opp2430_data.c | 30 arch/arm/plat-omap/clock.c | 10 + arch/arm/plat-omap/cpu-omap.c |1 + arch/arm/plat-omap/include/plat/clock.h |2 + 6 files changed, 96 insertions(+), 42 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: make serial_in_override() address the right uart port
On Tue, Jan 05, 2010 at 10:03:01 -0800, Tony Lindgren wrote: * Alexander Shishkin virtu...@slind.org [100105 08:56]: Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e makes it possible to have some other than first uart port as ttyS0, which breaks the workaround serial_in_override() function which will try to address the first uart port (for ttyS0) and not the one that was initialized. Nothing wrong with this patch.. But so we're back to having the ports move around again? That sucks. I wonder if we can initialize dummy 8250 ports somehow to keep the order correct to avoid confusion. It doesn't seem like any solution to this problem will suck less than the current one, but let's think about it. My patch only addresses the issue I'm having with the current solution. Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: make serial_in_override() address the right uart port
* Alexander Shishkin virtu...@slind.org [100105 10:08]: On Tue, Jan 05, 2010 at 10:03:01 -0800, Tony Lindgren wrote: * Alexander Shishkin virtu...@slind.org [100105 08:56]: Commit f62349ee9788b1d94c55eb6c291d74a1f69bdd9e makes it possible to have some other than first uart port as ttyS0, which breaks the workaround serial_in_override() function which will try to address the first uart port (for ttyS0) and not the one that was initialized. Nothing wrong with this patch.. But so we're back to having the ports move around again? That sucks. I wonder if we can initialize dummy 8250 ports somehow to keep the order correct to avoid confusion. It doesn't seem like any solution to this problem will suck less than the current one, but let's think about it. My patch only addresses the issue I'm having with the current solution. Agreed, we need to fix the problem first. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up
On Tue, 5 Jan 2010, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [100105 09:35]: Hello, This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi felipe.ba...@nokia.com. Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at: http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/ Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP. This second version also incorporates some comments from Felipe. These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there? Yes, I plan to send them there along with some other queued fixes for another .33-rc fixes series. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up
* Paul Walmsley p...@pwsan.com [100105 10:20]: On Tue, 5 Jan 2010, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [100105 09:35]: Hello, This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi felipe.ba...@nokia.com. Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at: http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/ Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP. This second version also incorporates some comments from Felipe. These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there? Yes, I plan to send them there along with some other queued fixes for another .33-rc fixes series. OK, thanks. Tony -- 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: [RFC][PATCH] mfd: twl4030: Check for i2c error code in protect_pm_master function
Hi Balaji,
On Fri, Dec 11, 2009 at 09:59:18PM +0530, balaj...@ti.com wrote:
From: Balaji T K balaj...@ti.com
Warn about error messages immediately after i2c write to R_PROTECT_KEY
in functions protect_pm_master/unprotect_pm_master
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mfd/twl-core.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 42af794..74f93ed 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -804,6 +804,9 @@ static inline int __init protect_pm_master(void)
e = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_LOCK,
R_PROTECT_KEY);
+ if (e 0)
+ pr_err(twl_core: Could not write value : %x to TWL
+ register %x err %d\n, KEY_LOCK, R_PROTECT_KEY, e);
return e;
}
@@ -811,10 +814,17 @@ static inline int __init unprotect_pm_master(void)
{
int e = 0;
- e |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK1,
+ e = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK1,
R_PROTECT_KEY);
- e |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK2,
+ if (e 0)
+ pr_err(twl_core: Could not write value : %x to TWL
+ register %x err %d\n, KEY_UNLOCK1, R_PROTECT_KEY, e);
+
Does it make sense to continue here ? If the key unlocking failed, shouldnt we
just return the error and leave ?
+ e = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK2,
R_PROTECT_KEY);
+ if (e 0)
+ pr_err(twl_core: Could not write value : %x to TWL
+ register %x err %d\n, KEY_UNLOCK1, R_PROTECT_KEY, e);
return e;
}
@@ -865,10 +875,13 @@ static void clocks_init(struct device *dev)
}
ctrl |= HIGH_PERF_SQ;
- e |= unprotect_pm_master();
+ e = unprotect_pm_master();
Same here: If the unprotection failed, the rest probably will fail as well,
right ?
Cheers,
Samuel.
/* effect-MADC+USB ck en */
- e |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER, ctrl, R_CFG_BOOT);
- e |= protect_pm_master();
+ e = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, ctrl, R_CFG_BOOT);
+ if (e 0)
+ pr_err(twl_core: Could not write value : %x to TWL
+ register %x err %d\n, ctrl, R_CFG_BOOT, e);
+ e = protect_pm_master();
if (e 0)
pr_err(%s: clock init err [%d]\n, DRIVER_NAME, e);
--
1.5.4.7
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
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: mfd: twl4030-irq: irq_desc-lock converted to raw_spinlock_t
Hi Tony, On Mon, Dec 28, 2009 at 12:01:45PM -0800, Tony Lindgren wrote: * Felipe Balbi felipe.ba...@nokia.com [091228 03:04]: commit 239007b8440abff689632f50cdf0f2b9e895b534 converted the spinlock_t to raw_spinlock_t. Unfortunately twl4030-irq was left aside on the conversion. Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Acked-by: Thomas Gleixner t...@linutronix.de Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- resending because it wasn't applied before This should go via Samuel as it's MFD related. Linus applied it to his tree directly. Cheers, Samuel. Acked-by: Tony Lindgren t...@atomide.com drivers/mfd/twl4030-irq.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index 20d29ba..9df9a5a 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -568,12 +568,12 @@ static void twl4030_sih_do_edge(struct work_struct *work) bytes[byte] = ~(0x03 off); - spin_lock_irq(d-lock); + raw_spin_lock_irq(d-lock); if (d-status IRQ_TYPE_EDGE_RISING) bytes[byte] |= BIT(off + 1); if (d-status IRQ_TYPE_EDGE_FALLING) bytes[byte] |= BIT(off + 0); - spin_unlock_irq(d-lock); + raw_spin_unlock_irq(d-lock); edge_change = ~BIT(i); } -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch-v2.6.33-rc2+ 10/12] arm: omap: gpio: kill compile warning in gpio.c
* Felipe Balbi felipe.ba...@nokia.com [091229 14:59]:
when building linux-omap for omap1510, there will
be a compile warning about the unused flags variable
which is only used on 16xx and onwards.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/gpio.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 0484681..8c34b81 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1072,7 +1072,10 @@ static inline void _set_gpio_irqenable(struct
gpio_bank *bank, int gpio, int ena
*/
static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
{
+#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP24XX) || \
+ defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP4)
unsigned long flags;
+#endif
Let's not add more ifdeffery to gpio.c.. How about
let's use uninitialized_var() instead? See the patch
below.
Regards,
Tony
From 62fc4a4ec588956979ef611da8753d8d1c02de8e Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 5 Jan 2010 12:17:06 -0800
Subject: [PATCH] omap: Remove uninitialized warning for gpio.c
Flags is not used on 15xx.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 0484681..792be9f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1072,7 +1072,7 @@ static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int ena
*/
static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
{
- unsigned long flags;
+ unsigned long uninitialized_var(flags);
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP16XX
Re: [patch-v2.6.33-rc2+ 06/12] arm: omap: kill compile warning in irq.c
* Felipe Balbi felipe.ba...@nokia.com [091229 14:54]:
intc_context is only used when omap3 is to be built,
so also put it under ifdef CONFIG_ARM_OMAP3 to avoid
the compile warning.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/irq.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index e9bc782..d370052 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -62,7 +62,9 @@ struct omap3_intc_regs {
u32 mir[INTCPS_NR_MIR_REGS];
};
+#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
+#endif
/* INTC bank register get/set */
Can you please move the struct omap3_intc_regs intc_context into
to right above save_context function where we have the a block
already for ifdef CONFIG_ARCH_OMAP3?
That avoids adding a new ifdef block.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags
* Paul Walmsley p...@pwsan.com [100105 09:52]: Hi, On Tue, 29 Dec 2009, Tony Lindgren wrote: Also, what's the Cortex version on your v7? It's rev r2p3 on omap3430. Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and below, and r1p7 on ES3.1.2. Oops, sorry for posting wrong info. Yeah it's r1 not r2. Regards, Tony -- 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: [rfc/rft/patch 4/9] arm: omap: io: kill compile warning
Hi Felipe,
cc's trimmed,
On Tue, 1 Dec 2009, Felipe Balbi wrote:
when building omap4 defconfigs, io.c will warn about unused
_omap2_init_reprogram_sdrc, that's because that functio is
only used ifndef CONFIG_ARCH_OMAP4, so add the missing
ifndef CONFIG_ARCH_OMAP4 to _omap2_init_reprogram_sdrc
definition.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/io.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 6a4d8e4..a2be3ce 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -278,6 +278,7 @@ void __init omap2_map_common_io(void)
* -EINVAL if the dpll3_m2_ck cannot be found, 0 if called on OMAP2,
* or passes along the return value of clk_set_rate().
*/
+#ifndef CONFIG_ARCH_OMAP4
static int __init _omap2_init_reprogram_sdrc(void)
{
struct clk *dpll3_m2_ck;
@@ -301,6 +302,7 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+#endif
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
--
1.6.6.rc0
Let's do this a little differently - can you move this function into a
mach-omap2/sdrc3xxx.c file, rename it to omap3_init_reprogram_sdrc(), set
the file up in the Makefile to only build for OMAP3, and then in io.c,
only call omap3_init_reprogram_sdrc() if cpu_is_omap34xx()? This way, we
avoid the ifdefs.
thanks
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AM35xx: Add clock support for new modules on AM35xx
Hi Ranjith,
(please keep attribution lines in message replies, otherwise it becomes
very difficult to keep track of who said what)
On Fri, 18 Dec 2009, Ranjith Lohithakshan wrote:
On Fri, 18-Dec-09 7:12 AM +0530, Paul Walmsley wrote:
+/* Clocks for AM35XX */
+static struct clk emac_ick = {
+.name = emac_ick,
+.ops= clkops_omap2_dflt,
Shouldn't this clock use clkops_omap2_dflt_wait (or rather, some custom
version that knows how to read the _ACK bits in IPSS_CLK_CTRL) and test
CPGMAC_VBUSP_CLK_EN_ACK? Same for the other IPSS VBUSP clocks? (I
guess
VBUSP is a synonym for interface?)
I will ad a custom clkops to address this. Do we need a find_companion
to be defined? The VBUSP clock ACK's do not depend on functional clocks
and the functional clocks themselves don't have ant ACK or status bits.
EMAC, VPFE amd MUSBOTG are initiators, but the their ACK bits are just
for the target idle status.
I see four ACK bits marked as clock status bits in the TRM. Are these
interface clock status bits for initiator interfaces, or are they module
target IdleAck bits? If they are the former, then they are useless and
there is no point waiting for these clocks. If they are the latter, then
yes, you'll need a find_companion, because the clock code must ensure that
both the interface clock and main functional clock are both enabled before
checking the module's target idle status, and the AM35xx IPSS does this in
a completely different way than the OMAP35xx. I guess the IPSS was just
'bolted on' to the chip, rather than really integrated into the OMAP2 PRCM
design.
One of the issues on AM35xx is regarding the status indicator for new
clocks. Here 1 indicates as enabled and 0 as not ready state, similar to
24xx case but just opposite to 34xx clocks. And now we have a mix of
these two on AM35xx.
Wow, that's really craptacular.
In omap2_cm_wait_idlest, I do not get a per clock granularity to
decide what should be the status check for that particular
clock. One of the approach I am thinking is to define a new clock
flag (say INVERT_ENABLE_STATUS) and set it for the new AM35xx
clocks. And in omap2_module_wait_ready I will do the cpu check and
flag check on a per clock basis and determine the status that need
to be checked and pass it to omap2_module_wait_ready to check what
we want. omap2_module_wait_ready will not be doing any cpu checks as
its done today. Let me know what you think.
(I guess you mean omap2_cm_wait_module_ready() in the last two sentences?)
How about extending find_idlest to pass back whether to test against 0 or
1? The cpu code will then move into the find_idlest code, and you can
just create a few new find_idlest functions for the AM35xx clocks. Let's
try to avoid creating new clock flags for this, I'm trying to move all of
this module IDLEST testing code out of the clock code and into the hwmod
code where it belongs.
+static struct clk emac_fck = {
+ .name = emac_fck,
+ .ops= clkops_omap2_dflt,
+ .clkdm_name = core_l3_clkdm,
Is this the correct clockdomain for this clock? It seems unlikely that a
50MHz functional clock would be in core_l3_clkdm. Usually these are all
interface clocks. This applies for all the other functional clocks
listed
in this file also.
Would it be OK if we just don't set clkdm_name. I am not sure whether we
can map it to any existing OMAP3 clock domains that way
I'd like to see all new clocks added with a clockdomain, even if it is not
a software-controllable clockdomain. That makes it possible for others to
understand what is really going on from a power management point of view.
What is the clockdomain structure for these new clocks?
+ .rate = 5000,
What's the parent of this clock? Looking at TRM section 4.7.7.12 it
appears that it gets this from an off-chip source, rmii_clk? Guess
that
should probably be defined as the fixed source clock, and emac_fck should
list rmii_clk as its parent?
+ .enable_reg = OMAP343X_CTRL_REGADDR(AM35XX_CONTROL_IPSS_CLK_CTRL),
+ .enable_bit = AM35XX_CPGMAC_FCLK_SHIFT,
+ .recalc = omap2_clksel_recalc,
This .recalc field is wrong, since there's no .clksel field defined. If
you define that parent, then this should be followparent_recalc. The
parent should have .flags = RATE_FIXED and no .recalc.
Do we really need to define an rmii_ck? Can we make emac_fck itself as
the root clock with no parent? Here is what I was thinking of. Let me
know if you see any issues with this
Yes, please define the parent clocks appropriately. They will probably be
in different clockdomains from the downstream clocks. Where does rmii_clk
come from? Is this an off-chip clock? Is this coming from one of the
on-chip DPLLs?
static struct clk emac_fck = {
.name = emac_fck,
.ops= clkops_omap2_dflt,
.flags = RATE_FIXED,
.rate = 5000,
[PATCH 00/10] Series short description
OMAP2/3/4 clockdomains/powerdomains: split shared dependencies and clean up
Hi,
This series moves wakeup and sleep dependencies on the OMAP2/3 chips from
the powerdomain layer to the clockdomain layer, where they belong. It also
adds usecounting for clockdomain dependency usecounting, which fixes the
obvious problem that occurs when several different pieces of code need
to add clockdomain dependencies, and then one removes the dependency.
(To add usecounting, the dependencies that were shared between
clockdomains have been split into separate records.) These changes should
prepare the clockdomain code for OMAP4 clockdomain dependencies.
The series also does some cleanup. struct powerdomain is packed, the
dead function pwrdm_clk_state_switch() is removed, documentation is improved,
the nonexistent MDM clockdomain is removed from OMAP2420.
Boot-tested on N800, 2430SDP, and OMAP3 Beagle. Compile-tested with
omap_osk_5912_defconfig.
Applies on the 'for_2.6.34' branch of git://git.pwsan.com/linux-2.6
- Paul
---
textdata bss dec hex filename
3622921 198528 102984 3924433 3be1d1 vmlinux.beagle.orig
3623325 199168 102984 3925477 3be5e5 vmlinux.beagle
Paul Walmsley (10):
OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm
OMAP2/3 clockdomains: split shared structures so usecounting works
OMAP2 clockdomain: modem clockdomain is only present on OMAP2430
OMAP clockdomain/powerdomain: remove runtime register/unregister
OMAP clockdomains: add usecounting for wakeup and sleep dependencies
OMAP2/3/4 clockdomain: add clkdm_clear_all_{wkdep,sleepdep}s()
OMAP powerdomain/PM: use symbolic constants for the max number of power
states
OMAP powerdomain: rearrange struct powerdomain to save some memory
OMAP powerdomain: remove pwrdm_clk_state_switch
OMAP clockdomain/powerdomain: improve documentation
arch/arm/mach-omap2/clockdomain.c | 691 +++--
arch/arm/mach-omap2/clockdomains.h| 474 +
arch/arm/mach-omap2/io.c |2
arch/arm/mach-omap2/omap_hwmod.c | 10
arch/arm/mach-omap2/pm34xx.c | 10
arch/arm/mach-omap2/powerdomain.c | 570 -
arch/arm/mach-omap2/powerdomains.h| 88 ---
arch/arm/mach-omap2/powerdomains24xx.h| 87 ---
arch/arm/mach-omap2/powerdomains34xx.h| 145 -
arch/arm/mach-omap2/prcm.c| 12
arch/arm/plat-omap/include/plat/clockdomain.h | 99 ++--
arch/arm/plat-omap/include/plat/powerdomain.h | 78 +--
arch/arm/plat-omap/include/plat/prcm.h|8
13 files changed, 1241 insertions(+), 1033 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] OMAP2/3 clockdomains: split shared structures so usecounting works
Previously some of the clockdomain wakeup/sleep dependency structures
were shared between several domains. For the subsequent wakeup and sleep
dependency usecounting patch to work, these can no longer be
shared. This patch splits the shared structures apart.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomains.h | 163
1 files changed, 127 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index c7cc0e7..894973c 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -52,6 +52,8 @@
* 2420/2430 PM_WKDEP_GFX: CORE, MPU, WKUP
* 3430ES1 PM_WKDEP_GFX: adds IVA2, removes CORE
* 3430ES2 PM_WKDEP_SGX: adds IVA2, removes CORE
+ * These can share data since they will never be present simultaneously
+ * on the same device.
*/
static struct clkdm_dep gfx_sgx_wkdeps[] = {
{
@@ -86,11 +88,32 @@ static struct clkdm_dep gfx_sgx_wkdeps[] = {
/* Wakeup dependency source arrays */
+/* 2420/2430 PM_WKDEP_DSP: CORE, MPU, WKUP */
+static struct clkdm_dep dsp_24xx_wkdeps[] = {
+ {
+ .clkdm_name = core_l3_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = core_l4_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = mpu_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ {
+ .clkdm_name = wkup_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
+ },
+ { NULL },
+};
+
/*
- * 2420/2430 PM_WKDEP_DSP: CORE, MPU, WKUP
- * 2420/2430 PM_WKDEP_MDM: same as DSP
+ * 2420/2430 PM_WKDEP_MDM: CORE, MPU, WKUP
+ * XXX This is probably 2430-only; 2420 did not have a stacked modem config.
*/
-static struct clkdm_dep dsp_mdm_24xx_wkdeps[] = {
+static struct clkdm_dep mdm_24xx_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
@@ -172,11 +195,8 @@ static struct clkdm_dep core_24xx_wkdeps[] = {
#ifdef CONFIG_ARCH_OMAP34XX
-/*
- * 3430: PM_WKDEP_{PER,USBHOST}: CORE, IVA2, MPU, WKUP
- * (USBHOST is ES2 only)
- */
-static struct clkdm_dep per_usbhost_wkdeps[] = {
+/* 3430: PM_WKDEP_PER: CORE, IVA2, MPU, WKUP */
+static struct clkdm_dep per_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
@@ -200,9 +220,32 @@ static struct clkdm_dep per_usbhost_wkdeps[] = {
{ NULL },
};
-/*
- * 3430 PM_WKDEP_MPU: CORE, IVA2, DSS, PER
- */
+/* 3430ES2: PM_WKDEP_USBHOST: CORE, IVA2, MPU, WKUP */
+static struct clkdm_dep usbhost_wkdeps[] = {
+ {
+ .clkdm_name = core_l3_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = core_l4_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = iva2_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = mpu_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = wkup_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ { NULL },
+};
+
+/* 3430 PM_WKDEP_MPU: CORE, IVA2, DSS, PER */
static struct clkdm_dep mpu_34xx_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
@@ -227,9 +270,7 @@ static struct clkdm_dep mpu_34xx_wkdeps[] = {
{ NULL },
};
-/*
- * 3430 PM_WKDEP_IVA2: CORE, MPU, WKUP, DSS, PER
- */
+/* 3430 PM_WKDEP_IVA2: CORE, MPU, WKUP, DSS, PER */
static struct clkdm_dep iva2_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
@@ -259,8 +300,25 @@ static struct clkdm_dep iva2_wkdeps[] = {
};
-/* 3430 PM_WKDEP_{CAM,DSS}: IVA2, MPU, WKUP */
-static struct clkdm_dep cam_dss_wkdeps[] = {
+/* 3430 PM_WKDEP_CAM: IVA2, MPU, WKUP */
+static struct clkdm_dep cam_wkdeps[] = {
+ {
+ .clkdm_name = iva2_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = mpu_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ {
+ .clkdm_name = wkup_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ },
+ { NULL },
+};
+
+/* 3430 PM_WKDEP_DSS: IVA2, MPU, WKUP */
+static struct clkdm_dep dss_wkdeps[] = {
{
.clkdm_name = iva2_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
@@ -288,11 +346,8 @@ static struct clkdm_dep neon_wkdeps[] = {
/* Sleep dependency source arrays for 34xx-specific clkdms - 34XX only */
-/*
- * 3430: CM_SLEEPDEP_{DSS,PER}: MPU, IVA
- * 3430ES2: CM_SLEEPDEP_USBHOST: MPU,
[PATCH 09/10] OMAP powerdomain: remove pwrdm_clk_state_switch
Nothing calls pwrdm_clk_state_switch(), and the function that seems to be
its ideal use case calls pwrdm_clkdm_state_switch(clk-clkdm), so remove it.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index df6446a..9d4b8f5 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -928,12 +928,6 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
return -EINVAL;
}
-int pwrdm_clk_state_switch(struct clk *clk)
-{
- if (clk != NULL clk-clkdm != NULL)
- return pwrdm_clkdm_state_switch(clk-clkdm);
- return -EINVAL;
-}
int pwrdm_pre_transition(void)
{
--
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 03/10] OMAP2 clockdomain: modem clockdomain is only present on OMAP2430
For some reason, previously, we included the MDM clockdomain on all 24xx,
but the stacked die-on-die modem configuration (chassis mode) is only
available on OMAP2430.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomains.h | 49
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 894973c..1df12c7 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -110,10 +110,10 @@ static struct clkdm_dep dsp_24xx_wkdeps[] = {
};
/*
- * 2420/2430 PM_WKDEP_MDM: CORE, MPU, WKUP
- * XXX This is probably 2430-only; 2420 did not have a stacked modem config.
+ * 2420 PM_WKDEP_MPU: CORE, DSP, WKUP
+ * 2430 adds MDM
*/
-static struct clkdm_dep mdm_24xx_wkdeps[] = {
+static struct clkdm_dep mpu_24xx_wkdeps[] = {
{
.clkdm_name = core_l3_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
@@ -123,31 +123,35 @@ static struct clkdm_dep mdm_24xx_wkdeps[] = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = mpu_clkdm,
+ .clkdm_name = dsp_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
.clkdm_name = wkup_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
+ {
+ .clkdm_name = mdm_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ },
{ NULL },
};
/*
- * 2420 PM_WKDEP_MPU: CORE, DSP, WKUP
+ * 2420 PM_WKDEP_CORE: DSP, GFX, MPU, WKUP
* 2430 adds MDM
*/
-static struct clkdm_dep mpu_24xx_wkdeps[] = {
+static struct clkdm_dep core_24xx_wkdeps[] = {
{
- .clkdm_name = core_l3_clkdm,
+ .clkdm_name = dsp_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = core_l4_clkdm,
+ .clkdm_name = gfx_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = dsp_clkdm,
+ .clkdm_name = mpu_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
@@ -161,17 +165,21 @@ static struct clkdm_dep mpu_24xx_wkdeps[] = {
{ NULL },
};
-/*
- * 2420 PM_WKDEP_CORE: DSP, GFX, MPU, WKUP
- * 2430 adds MDM
- */
-static struct clkdm_dep core_24xx_wkdeps[] = {
+#endif
+
+
+/* 2430-specific possible wakeup dependencies */
+
+#ifdef CONFIG_ARCH_OMAP2430
+
+/* 2430 PM_WKDEP_MDM: CORE, MPU, WKUP */
+static struct clkdm_dep mdm_2430_wkdeps[] = {
{
- .clkdm_name = dsp_clkdm,
+ .clkdm_name = core_l3_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
- .clkdm_name = gfx_clkdm,
+ .clkdm_name = core_l4_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
{
@@ -182,14 +190,11 @@ static struct clkdm_dep core_24xx_wkdeps[] = {
.clkdm_name = wkup_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX)
},
- {
- .clkdm_name = mdm_clkdm,
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
- },
{ NULL },
};
-#endif
+#endif /* CONFIG_ARCH_OMAP2430 */
+
/* 34XX-specific possible dependencies */
@@ -549,7 +554,7 @@ static struct clockdomain mdm_clkdm = {
.clkstctrl_reg = OMAP2430_CM_REGADDR(OMAP2430_MDM_MOD,
OMAP2_CM_CLKSTCTRL),
.dep_bit= OMAP2430_PM_WKDEP_MPU_EN_MDM_SHIFT,
- .wkdep_srcs = mdm_24xx_wkdeps,
+ .wkdep_srcs = mdm_2430_wkdeps,
.clktrctrl_mask = OMAP2430_AUTOSTATE_MDM_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
--
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 10/10] OMAP clockdomain/powerdomain: improve documentation
This patch only affects documentation; no functional changes are
included.
Clean up comments in the current clockdomain, powerdomain code and
header files. This mostly involves conversion to kerneldoc format,
although some clarifications are also included.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 65 ++-
arch/arm/mach-omap2/powerdomain.c | 149 +
arch/arm/plat-omap/include/plat/clockdomain.h | 87 +++
arch/arm/plat-omap/include/plat/powerdomain.h | 40 +++
4 files changed, 167 insertions(+), 174 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index f44d9ea..2f68c10 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -351,10 +351,10 @@ static void _init_sleepdep_usecount(struct clockdomain
*clkdm)
* @init_autodeps: optional pointer to an array of autodeps to register
*
* Set up internal state. If a pointer to an array of clockdomains
- * was supplied, loop through the list of clockdomains, register all
- * that are available on the current platform. Similarly, if a pointer
- * to an array of clockdomain autodependencies was provided, register
- * those. No return value.
+ * @clkdms was supplied, loop through the list of clockdomains,
+ * register all that are available on the current platform. Similarly,
+ * if a pointer to an array of clockdomain autodependencies
+ * @init_autodeps was provided, register those. No return value.
*/
void clkdm_init(struct clockdomain **clkdms,
struct clkdm_autodep *init_autodeps)
@@ -386,8 +386,8 @@ void clkdm_init(struct clockdomain **clkdms,
* clkdm_lookup - look up a clockdomain by name, return a pointer
* @name: name of clockdomain
*
- * Find a registered clockdomain by its name. Returns a pointer to the
- * struct clockdomain if found, or NULL otherwise.
+ * Find a registered clockdomain by its name @name. Returns a pointer
+ * to the struct clockdomain if found, or NULL otherwise.
*/
struct clockdomain *clkdm_lookup(const char *name)
{
@@ -412,8 +412,8 @@ struct clockdomain *clkdm_lookup(const char *name)
* clkdm_for_each - call function on each registered clockdomain
* @fn: callback function *
*
- * Call the supplied function for each registered clockdomain.
- * The callback function can return anything but 0 to bail
+ * Call the supplied function @fn for each registered clockdomain.
+ * The callback function @fn can return anything but 0 to bail
* out early from the iterator. The callback function is called with
* the clkdm_mutex held, so no clockdomain structure manipulation
* functions should be called from the callback, although hardware
@@ -446,7 +446,7 @@ int clkdm_for_each(int (*fn)(struct clockdomain *clkdm,
void *user),
* @clkdm: struct clockdomain *
*
* Return a pointer to the struct powerdomain that the specified clockdomain
- * 'clkdm' exists in, or returns NULL if clkdm argument is NULL.
+ * @clkdm exists in, or returns NULL if @clkdm is NULL.
*/
struct powerdomain *clkdm_get_pwrdm(struct clockdomain *clkdm)
{
@@ -759,10 +759,10 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
/**
* omap2_clkdm_clktrctrl_read - read the clkdm's current state transition mode
- * @clk: struct clk * of a clockdomain
+ * @clkdm: struct clkdm * of a clockdomain
*
- * Return the clockdomain's current state transition mode from the
- * corresponding domain OMAP2_CM_CLKSTCTRL register. Returns -EINVAL if clk
+ * Return the clockdomain @clkdm current state transition mode from the
+ * corresponding domain CM_CLKSTCTRL register. Returns -EINVAL if @clkdm
* is NULL or the current mode upon success.
*/
static int omap2_clkdm_clktrctrl_read(struct clockdomain *clkdm)
@@ -784,7 +784,7 @@ static int omap2_clkdm_clktrctrl_read(struct clockdomain
*clkdm)
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a sleep transition on the specified
- * clockdomain 'clkdm'. Returns -EINVAL if clk is NULL or if
+ * clockdomain @clkdm. Returns -EINVAL if @clkdm is NULL or if
* clockdomain does not support software-initiated sleep; 0 upon
* success.
*/
@@ -828,7 +828,7 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a wakeup transition on the specified
- * clockdomain 'clkdm'. Returns -EINVAL if clkdm is NULL or if the
+ * clockdomain @clkdm. Returns -EINVAL if @clkdm is NULL or if the
* clockdomain does not support software-controlled wakeup; 0 upon
* success.
*/
@@ -871,7 +871,7 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
*
- * Allow the hardware to automatically switch the clockdomain into
+ * Allow the hardware to automatically switch the clockdomain @clkdm into
* active or idle
[PATCH 08/10] OMAP powerdomain: rearrange struct powerdomain to save some memory
This patch rearranges the order of structure members in struct powerdomain
to avoid wasting memory due to alignment restrictions.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/powerdomain.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index c590e2f..87e13f8 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -73,12 +73,12 @@ struct powerdomain {
/* Powerdomain name */
const char *name;
- /* the address offset from CM_BASE/PRM_BASE */
- const s16 prcm_offs;
-
/* Used to represent the OMAP chip types containing this pwrdm */
const struct omap_chip_id omap_chip;
+ /* the address offset from CM_BASE/PRM_BASE */
+ const s16 prcm_offs;
+
/* Possible powerdomain power states */
const u8 pwrsts;
--
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 07/10] OMAP powerdomain/PM: use symbolic constants for the max number of power states
Replace some bare constants with symbolic constants. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/powerdomain.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 411361f..df6446a 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -122,7 +122,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm) list_add(pwrdm-node, pwrdm_list); /* Initialize the powerdomain's state counter */ - for (i = 0; i 4; i++) + for (i = 0; i PWRDM_MAX_PWRSTS; i++) pwrdm-state_counter[i] = 0; pwrdm_wait_transition(pwrdm); -- 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 06/10] OMAP2/3/4 clockdomain: add clkdm_clear_all_{wkdep, sleepdep}s()
Add clkdm_clear_all_wkdeps() and clkdm_clear_all_sleepdeps(). These functions
provide a fast way for code to clear all hardware clockdomain dependencies,
since accesses to these registers can be quite slow. These functions
are currently targeted for use by PM branch code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clockdomain.c | 68 +
arch/arm/plat-omap/include/plat/clockdomain.h |2 +
2 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index d039df7..f44d9ea 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -565,6 +565,38 @@ int clkdm_read_wkdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
}
/**
+ * clkdm_clear_all_wkdeps - remove all wakeup dependencies from target clkdm
+ * @clkdm: struct clockdomain * to remove all wakeup dependencies from
+ *
+ * Remove all inter-clockdomain wakeup dependencies that could cause
+ * @clkdm to wake. Intended to be used during boot to initialize the
+ * PRCM to a known state, after all clockdomains are put into swsup idle
+ * and woken up. Returns -EINVAL if @clkdm pointer is invalid, or
+ * 0 upon success.
+ */
+int clkdm_clear_all_wkdeps(struct clockdomain *clkdm)
+{
+ struct clkdm_dep *cd;
+ u32 mask = 0;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (cd = clkdm-wkdep_srcs; cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ /* PRM accesses are slow, so minimize them */
+ mask |= 1 cd-clkdm-dep_bit;
+ atomic_set(cd-wkdep_usecount, 0);
+ }
+
+ prm_clear_mod_reg_bits(mask, clkdm-pwrdm.ptr-prcm_offs, PM_WKDEP);
+
+ return 0;
+}
+
+/**
* clkdm_add_sleepdep - add a sleep dependency from clkdm2 to clkdm1
* @clkdm1: prevent this struct clockdomain * from sleeping (dependent)
* @clkdm2: when this struct clockdomain * is active (source)
@@ -690,6 +722,42 @@ int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
}
/**
+ * clkdm_clear_all_sleepdeps - remove all sleep dependencies from target clkdm
+ * @clkdm: struct clockdomain * to remove all sleep dependencies from
+ *
+ * Remove all inter-clockdomain sleep dependencies that could prevent
+ * @clkdm from idling. Intended to be used during boot to initialize the
+ * PRCM to a known state, after all clockdomains are put into swsup idle
+ * and woken up. Returns -EINVAL if @clkdm pointer is invalid, or
+ * 0 upon success.
+ */
+int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
+{
+ struct clkdm_dep *cd;
+ u32 mask = 0;
+
+ if (!cpu_is_omap34xx())
+ return -EINVAL;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (cd = clkdm-sleepdep_srcs; cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ /* PRM accesses are slow, so minimize them */
+ mask |= 1 cd-clkdm-dep_bit;
+ atomic_set(cd-sleepdep_usecount, 0);
+ }
+
+ prm_clear_mod_reg_bits(mask, clkdm-pwrdm.ptr-prcm_offs,
+ OMAP3430_CM_SLEEPDEP);
+
+ return 0;
+}
+
+/**
* omap2_clkdm_clktrctrl_read - read the clkdm's current state transition mode
* @clk: struct clk * of a clockdomain
*
diff --git a/arch/arm/plat-omap/include/plat/clockdomain.h
b/arch/arm/plat-omap/include/plat/clockdomain.h
index 192cc95..45b5deb 100644
--- a/arch/arm/plat-omap/include/plat/clockdomain.h
+++ b/arch/arm/plat-omap/include/plat/clockdomain.h
@@ -132,9 +132,11 @@ struct powerdomain *clkdm_get_pwrdm(struct clockdomain
*clkdm);
int clkdm_add_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_del_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_read_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
+int clkdm_clear_all_wkdeps(struct clockdomain *clkdm);
int clkdm_add_sleepdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_del_sleepdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2);
int clkdm_read_sleepdep(struct clockdomain *clkdm1, struct clockdomain
*clkdm2);
+int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm);
void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
void omap2_clkdm_deny_idle(struct clockdomain *clkdm);
--
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 05/10] OMAP clockdomains: add usecounting for wakeup and sleep dependencies
Add usecounting for wakeup and sleep dependencies. In the current
situation, if several functions add dependencies on the same clockdomains,
when the first dependency removal function is called, the dependency will
be incorrectly removed from the hardware.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 150 ++---
arch/arm/plat-omap/include/plat/clockdomain.h |6 +
2 files changed, 135 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 2af9996..d039df7 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -113,7 +113,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
return ERR_PTR(-EINVAL);
for (cd = deps; cd-clkdm_name; cd++) {
-
if (!omap_chip_is(cd-omap_chip))
continue;
@@ -122,7 +121,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
if (cd-clkdm == clkdm)
break;
-
}
if (!cd-clkdm_name)
@@ -254,6 +252,96 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
}
+/**
+ * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize wkdep usecounts
+ *
+ * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
+ * If a wakeup dependency is present in the hardware, the usecount will be
+ * set to 1; otherwise, it will be set to 0. Software should clear all
+ * software wakeup dependencies prior to calling this function if it wishes
+ * to ensure that all usecounts start at 0. No return value.
+ */
+static void _init_wkdep_usecount(struct clockdomain *clkdm)
+{
+ u32 v;
+ struct clkdm_dep *cd;
+
+ if (!clkdm-wkdep_srcs)
+ return;
+
+ for (cd = clkdm-wkdep_srcs; cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ if (!cd-clkdm cd-clkdm_name)
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+
+ if (!cd-clkdm) {
+ WARN(!cd-clkdm, clockdomain: %s: wkdep clkdm %s not
+found\n, clkdm-name, cd-clkdm_name);
+ continue;
+ }
+
+ v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
+ PM_WKDEP,
+ (1 cd-clkdm-dep_bit));
+
+ if (v)
+ pr_debug(clockdomain: %s: wakeup dependency already
+set to wake up when %s wakes\n,
+clkdm-name, cd-clkdm-name);
+
+ atomic_set(cd-wkdep_usecount, (v) ? 1 : 0);
+ }
+}
+
+/**
+ * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize sleepdep usecounts
+ *
+ * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
+ * If a sleep dependency is present in the hardware, the usecount will be
+ * set to 1; otherwise, it will be set to 0. Software should clear all
+ * software sleep dependencies prior to calling this function if it wishes
+ * to ensure that all usecounts start at 0. No return value.
+ */
+static void _init_sleepdep_usecount(struct clockdomain *clkdm)
+{
+ u32 v;
+ struct clkdm_dep *cd;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ if (!clkdm-sleepdep_srcs)
+ return;
+
+ for (cd = clkdm-sleepdep_srcs; cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ if (!cd-clkdm cd-clkdm_name)
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+
+ if (!cd-clkdm) {
+ WARN(!cd-clkdm, clockdomain: %s: sleepdep clkdm %s
+not found\n, clkdm-name, cd-clkdm_name);
+ continue;
+ }
+
+ v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
+ OMAP3430_CM_SLEEPDEP,
+ (1 cd-clkdm-dep_bit));
+
+ if (v)
+ pr_debug(clockdomain: %s: sleep dependency already
+set to prevent from idling until %s
+idles\n, clkdm-name, cd-clkdm-name);
+
+ atomic_set(cd-sleepdep_usecount, (v) ? 1 : 0);
+ }
+};
/* Public functions */
@@ -272,6 +360,7 @@ void clkdm_init(struct clockdomain **clkdms,
struct clkdm_autodep *init_autodeps)
{
struct clockdomain **c = NULL;
+ struct clockdomain *clkdm;
struct clkdm_autodep *autodep = NULL;
if (clkdms)
@@ -282,6
Re: [PATCH] ARM: OMAP4 clock domains : Add the missing Clock Domain Structure
On Wed, 30 Dec 2009, Abhijit Pagare wrote: One of the clock domains was missing from the auto-generated file. It has been added here. Signed-off-by: Abhijit Pagare abhijitpag...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, queued for 2.6.34. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4 clock framework: Remove the checks preventing OMAP4 clockdomain validation
On Wed, 30 Dec 2009, Abhijit Pagare wrote: The clockdomain related code being in place, it is not necessary to have some part of the clock code commented out. This would help the validation of the clockdomain functions using the clock level interfaces. Signed-off-by: Abhijit Pagare abhijitpag...@ti.com Cc: Paul Walmsley p...@pwsan.com Thanks, queued for 2.6.34. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] ARM: OMAP4: PM: Add check for avoiding dependency related update.
On Wed, 30 Dec 2009, Pagare, Abhijit wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, December 30, 2009 2:02 PM But really, I'd rather not apply this patch. The best way forward is to apply a patch that adds the OMAP4 wakeup and sleep dependencies themselves. Have you had a chance to look at the series that I sent you a few weeks ago off-list that reorganizes the wakeup and sleep dependencies to determine if it is adequate for you to add the OMAP4 wakeup/sleep dependencies afterwards? I had a look at the dependency patches that you had sent to me earlier and it seems feasible to add the OMAP4 related dependency data on top of those patches. A small change exists but can be taken care of. Great, I've just cleaned those up, rebased them, and posted them to the list. If you prefer, you can also get from the 'move_wkdeps_sleepdeps_to_clkdm' branch at git://git.pwsan.com/linux-2.6 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP2/3/4 clockdomains/powerdomains: split shared dependencies and clean up
The above is what the subject line 'should' have been... - Paul -- 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
problem with n810 boot up
Luke-Jr wrote: Tested on Nokia N810 in Linux-OMAP tree. Mainline is not bootable yet. Hi Luke, I'm with some problems to boot-up latest l-o(commit abb74381235a05f15a3b07e9e3831034942c67fb) with n810. The error message can be found below and full boot output in the end of email. dsme: No correct bootreason found, entering the malfunction state I'm not sure if it's related with kernel or rootfs. I tried different distros(Maemo,Angstrom,Mamona and Mer) and I got the same problem using this kernel. What rootfs do you use? Did you change initfs? Any idea/help? Thanks in advance, Alecrim. PS: 2.6.30-rc8 is the last kernel version that I got working (http://www.natisbad.org/N810/index.html) Uncompressing Linux.. done, booting the kernel. [0.00] Linux version 2.6.33-rc2-06901-gabb7438 (alec...@alecrim) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #53 Tue Jan 5 18:35:16 AMT 2010 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387f [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Nokia N810 [0.00] Ignoring unrecognised tag 0x414f4d50 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP2420 [0.00] [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=1f03 rootfstype=jffs2 console=ttyS2,115200 [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 64MB 64MB = 128MB total [0.00] Memory: 127316KB available (2088K code, 184K data, 96K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:368 [0.00] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz [0.00] GPMC revision 2.0 [0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP GPIO hardware version 1.8 [0.00] OMAP clockevent source: GPTIMER1 at 32000 Hz [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 320.37 BogoMIPS (lpj=1253376) [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] NET: Registered protocol family 16 [ 307.198364] OMAP DMA hardware revision 2.0 [ 307.216583] bio: create slab bio-0 at 0 [ 307.221252] usbcore: registered new interface driver usbfs [ 307.90] usbcore: registered new interface driver hub [ 307.222869] usbcore: registered new device driver usb [ 307.225250] Switching to clocksource 32k_counter [ 307.229980] musb_hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0 [ 307.230895] NET: Registered protocol family 2 [ 307.231140] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [ 307.231597] TCP established hash table entries: 4096 (order: 3, 32768 bytes) [ 307.231872] TCP bind hash table entries: 4096 (order: 2, 16384 bytes) [ 307.232116] TCP: Hash tables configured (established 4096 bind 4096) [ 307.232147] TCP reno registered [ 307.232177] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 307.232238] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 307.232513] NET: Registered protocol family 1 [ 307.234924] NetWinder Floating Point Emulator V0.97 (double precision) [ 307.267059] JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 307.269897] msgmni has been set to 248 [ 307.270019] io scheduler noop registered [ 307.271697] io scheduler cfq registered (default) [ 307.310852] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 307.334625] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 [ 307.355895] serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 [ 307.376953] serial8250.2: ttyS2 at MMIO 0x4806e000 (irq = 74) is a ST16654 [ 307.685607] console [ttyS2] enabled [ 307.712738] brd: module loaded [ 307.716278] OneNAND driver initializing [ 307.720794] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x0400, virtual base c888 [ 307.730560] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 307.735382] OneNAND version = 0x0022 [ 307.740570] Scanning device for bad blocks [ 307.754882] onenand_bbt_wait: ecc error = 0x, controller error 0x2440 [ 307.761840] Bad eraseblock 183 at 0x016e [ 307.836791] onenand_bbt_wait: ecc error = 0x, controller error 0x2440 [ 307.843658] Bad eraseblock 1461 at 0x0b6a [ 307.880462] Creating 5 MTD partitions on omap2-onenand: [ 307.885925]
Re: [rfc/rft/patch-v2.6.32-omap1+ 2/2] arm: omap: add missing __initdata to omap_board_config_kernel
Tomi,
* Ladislav Michl ladislav.mi...@seznam.cz [091216 14:40]:
On Wed, Dec 16, 2009 at 11:52:35PM +0200, Felipe Balbi wrote:
we still need to get rid of the OMAP_TAG_LCD, but while
it's still there, let's kill the section mismatches.
Hmm, couldn't we just simply remove all empty declarations first? As data
section
is zeroed it should not cause any harm. Anyway, patch bellow is entirely
untested
and posted for your convenience only :-)
Can you please queue this (and any other fb/dss related board fixes) into your
dss fixes queue?
Signed-off-by: Ladislav Michl la...@linux-mips.org
Acked-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index e1195a3..bea32cf 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -57,9 +57,6 @@ static struct omap_usb_config generic1610_usb_config
__initdata = {
};
#endif
-static struct omap_board_config_kernel generic_config[] __initdata = {
-};
-
static void __init omap_generic_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
@@ -80,9 +77,6 @@ static void __init omap_generic_init(void)
omap_usb_init(generic1610_usb_config);
}
#endif
-
- omap_board_config = generic_config;
- omap_board_config_size = ARRAY_SIZE(generic_config);
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
}
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 1691835..5a95391 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -150,9 +150,6 @@ static struct omap_usb_config voiceblue_usb_config
__initdata = {
.pins[2]= 6,
};
-static struct omap_board_config_kernel voiceblue_config[] = {
-};
-
static void __init voiceblue_init_irq(void)
{
omap1_init_common_hw();
@@ -194,8 +191,6 @@ static void __init voiceblue_init(void)
set_irq_type(gpio_to_irq(15), IRQ_TYPE_EDGE_RISING);
platform_add_devices(voiceblue_devices, ARRAY_SIZE(voiceblue_devices));
- omap_board_config = voiceblue_config;
- omap_board_config_size = ARRAY_SIZE(voiceblue_config);
omap_serial_init();
omap_usb_init(voiceblue_usb_config);
omap_register_i2c_bus(1, 100, NULL, 0);
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c90b0d0..4bfd8e3 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -298,13 +298,8 @@ static struct platform_device *sdp3430_devices[]
__initdata = {
sdp3430_dss_device,
};
-static struct omap_board_config_kernel sdp3430_config[] __initdata = {
-};
-
static void __init omap_3430sdp_init_irq(void)
{
- omap_board_config = sdp3430_config;
- omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 7390596..f460d4f 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -72,13 +72,8 @@ static void __init omap_sdp_map_io(void)
omap2_map_common_io();
}
-static struct omap_board_config_kernel sdp_config[] __initdata = {
-};
-
static void __init omap_sdp_init_irq(void)
{
- omap_board_config = sdp_config;
- omap_board_config_size = ARRAY_SIZE(sdp_config);
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index b4e6eca..c16cb3f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,17 +35,11 @@
/*
* Board initialization
*/
-static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
-};
-
static struct platform_device *am3517_evm_devices[] __initdata = {
};
static void __init am3517_evm_init_irq(void)
{
- omap_board_config = am3517_evm_config;
- omap_board_config_size = ARRAY_SIZE(am3517_evm_config);
-
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
omap_gpio_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 2626a9f..3ec2687 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -462,14 +462,8 @@ static void __init cm_t35_init_i2c(void)
ARRAY_SIZE(cm_t35_i2c_boardinfo));
}
-static struct omap_board_config_kernel cm_t35_config[] __initdata = {
-};
-
static void __init cm_t35_init_irq(void)
{
- omap_board_config = cm_t35_config;
- omap_board_config_size = ARRAY_SIZE(cm_t35_config);
-
[APPLIED] [PATCH] OMAP: ZOOM2: Correcting key mapping for few keys
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 736687cd70885a0c669da188902af713005a57ee PatchWorks http://patchwork.kernel.org/patch/68622/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=736687cd70885a0c669da188902af713005a57ee -- 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: problem with n810 boot up
On Tuesday 05 January 2010 05:24:56 pm Francisco Alecrim wrote: Luke-Jr wrote: Tested on Nokia N810 in Linux-OMAP tree. Mainline is not bootable yet. I'm with some problems to boot-up latest l-o(commit abb74381235a05f15a3b07e9e3831034942c67fb) with n810. The error message can be found below and full boot output in the end of email. dsme: No correct bootreason found, entering the malfunction state That's DSME, part of Maemo userland. You can possibly write a LD_PRELOAD workaround if you want to run it anyway... What rootfs do you use? Did you change initfs? Gentoo. I modified my initfs to chainload its init if a new kernel is running. Unfortunately, I have come to the realisation that moving forward with the Linux port to N8x0 would take me more time than simply spending the same time doing paid work and buying a N900* or Pandora instead. So short some other reimbursement for porting Linux to N8x0 (like maybe a promise of BME sources or a N900 after the rest is done to finish the job), I'm probably not going to spend any more time on it. :( Luke * N900 is supposedly mostly mainlined already, and supposedly Nokia will actually finish the job with unlike N8x0; it also has nicer hardware, even if you just ignore the cellular capabilities -- 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: [PATCHv2 1/1] OMAP3: PM: Fix OTG autoidle workaround
* Felipe Balbi felipe.ba...@nokia.com [091218 03:12]: Hi, On Fri, Dec 18, 2009 at 11:39:23AM +0100, Valentin Eduardo (Nokia-D/Helsinki) wrote: From: Eduardo Valentin eduardo.valen...@nokia.com This patch fix the OTG autoidle workaround so now usb gadget modules can be properly loaded. Besides it also adds a cpu check, because this hardware but is present only in OMAP34xx chips. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com looks like after this patch we can drop the workaround from omap2430.c and use whatever platform code configured. FYI, tagging this for Kevin in patchwork as it's PM related. Regards, Tony -- 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
[APPLIED] [PATCH] OMAP3: add missing parentheses
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 0bc9c936162be8477229c929a65349c13cf28866 PatchWorks http://patchwork.kernel.org/patch/69437/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0bc9c936162be8477229c929a65349c13cf28866 -- 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
[APPLIED] [PATCH] OMAP3EVM: Choose OMAP_PACKAGE_CBB
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): a46b02659f8d2edff801441443ba85dec024d0f8 PatchWorks http://patchwork.kernel.org/patch/70349/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a46b02659f8d2edff801441443ba85dec024d0f8 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3EVM: Choose OMAP_PACKAGE_CBB
* hvaib...@ti.com hvaib...@ti.com [091230 22:22]: From: Vaibhav Hiremath hvaib...@ti.com Without this the kernel doesn't boot, it craches in omap_mux_package_fixup(), since the package_subset becomes NULL. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 10eafa7..606bf04 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -80,6 +80,7 @@ config MACH_OVERO config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX + select OMAP_PACKAGE_CBB config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board Also applying the following fix so uninitialized packages won't cause problems. Regards, Tony From a6f77c57a213d692ef61db8e7920390779960302 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Tue, 5 Jan 2010 15:54:58 -0800 Subject: [PATCH] omap: Fix booting if package is uninitialized Otherwise bringing up new boards can be harder: Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 5 [#1] last sysfs file: Modules linked in: CPU: 0Not tainted (2.6.33-rc2-00015-g0bc9c93-dirty #37) PC is at omap_mux_init+0xa4/0x3d8 LR is at omap_mux_init+0x3c/0x3d8 ... Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index e071b3f..459ef23 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -994,8 +994,10 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size, } #ifdef CONFIG_OMAP_MUX - omap_mux_package_fixup(package_subset, superset); - omap_mux_package_init_balls(package_balls, superset); + if (package_subset) + omap_mux_package_fixup(package_subset, superset); + if (package_balls) + omap_mux_package_init_balls(package_balls, superset); omap_mux_set_cmdline_signals(); omap_mux_set_board_signals(board_mux); #endif
[APPLIED] [PATCH v3] [OMAP] gpio: Simultaneously requested rising and falling
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 738321a2992ff49f96c5384feb28a94dff40b5d3 PatchWorks http://patchwork.kernel.org/patch/67436/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=738321a2992ff49f96c5384feb28a94dff40b5d3 -- 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
[PATCHv2 3/3] DSPBRIDGE: Validate Processor Handle from user.
From 84b37fc98b56b91ab364c40114d9cf072bbef345 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Wed, 16 Dec 2009 18:09:14 -0600
Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user.
Add check to validate the Processor handle received
from user.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 81 +++-
drivers/dsp/bridge/rmgr/proc.c | 300 ++--
2 files changed, 184 insertions(+), 197 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 917e549..55b436a 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -701,6 +701,7 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args-ARGS_PROC_CTRL.pArgs;
u8 *pArgs = NULL;
DSP_STATUS status = DSP_SOK;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_3trace(WCD_debugMask, GT_ENTER,
PROCWRAP_Ctrl: entered args:\n 0x%x
@@ -708,6 +709,10 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args, void *pr_ctxt)
args-ARGS_PROC_CTRL.hProcessor,
args-ARGS_PROC_CTRL.dwCmd,
args-ARGS_PROC_CTRL.pArgs);
+ if (args-ARGS_PROC_CTRL.hProcessor != pCtxt-hProcessor) {
+ status = DSP_EHANDLE;
+ goto func_end;
+ }
if (pSize) {
if (get_user(cbDataSize, pSize)) {
status = DSP_EFAIL;
@@ -759,6 +764,7 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
DSP_HNODE aNodeTab[MAX_NODES];
u32 uNumNodes;
u32 uAllocated;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_5trace(WCD_debugMask, GT_ENTER,
PROCWRAP_EnumNode_Info:entered args:\n0x
@@ -770,6 +776,9 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_PROC_ENUMNODE_INFO.puNumNodes,
args-ARGS_PROC_ENUMNODE_INFO.puAllocated);
+ if (args-ARGS_PROC_ENUMNODE_INFO.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (!args-ARGS_PROC_ENUMNODE_INFO.uNodeTabSize)
return DSP_ESIZE;
@@ -792,9 +801,13 @@ u32 PROCWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_FlushMemory: entered\n);
+ if (args-ARGS_PROC_FLUSHMEMORY.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_FLUSHMEMORY.ulFlags PROC_WRBK_INV_ALL)
return DSP_EINVALIDARG;
@@ -812,10 +825,14 @@ u32 PROCWRAP_FlushMemory(union Trapped_Args *args, void
*pr_ctxt)
u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args, void *pr_ctxt)
{
DSP_STATUS status;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER,
PROCWRAP_InvalidateMemory:entered\n);
+ if (args-ARGS_PROC_INVALIDATEMEMORY.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
status = PROC_InvalidateMemory(
args-ARGS_PROC_INVALIDATEMEMORY.hProcessor,
args-ARGS_PROC_INVALIDATEMEMORY.pMpuAddr,
@@ -831,6 +848,7 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
struct DSP_RESOURCEINFO pResourceInfo;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_4trace(WCD_debugMask, GT_ENTER,
PROCWRAP_EnumResources: entered args:\n
@@ -841,6 +859,9 @@ u32 PROCWRAP_EnumResources(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_PROC_ENUMRESOURCES.pResourceInfo,
args-ARGS_PROC_ENUMRESOURCES.uResourceInfoSize);
+ if (args-ARGS_PROC_ENUMRESOURCES.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_ENUMRESOURCES.uResourceInfoSize
sizeof(struct DSP_RESOURCEINFO))
return DSP_ESIZE;
@@ -864,8 +885,13 @@ u32 PROCWRAP_GetState(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
struct DSP_PROCESSORSTATE procStatus;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
+
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_GetState: entered\n);
+ if (args-ARGS_PROC_GETSTATE.hProcessor != pCtxt-hProcessor)
+ return DSP_EHANDLE;
+
if (args-ARGS_PROC_GETSTATE.uStateInfoSize
sizeof(struct DSP_PROCESSORSTATE))
return DSP_ESIZE;
@@ -884,9 +910,13 @@ u32 PROCWRAP_GetTrace(union Trapped_Args *args, void
*pr_ctxt)
{
DSP_STATUS status;
u8 *pBuf;
+ struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
GT_0trace(WCD_debugMask, GT_ENTER, PROCWRAP_GetTrace:
Re: [PATCH 1/4] OMAP2: Fix compile breaks
Hi,
* Rajendra Nayak rna...@ti.com [091214 01:11]:
Fixes a couple of implicit function definition errors
for functions defined only for omap3 and called in omap2/3
common code, and one function argument mismatch.
Looks like this needs to be refreshed to apply. Also
please fix the few cosmetic issues below :)
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/serial.c|1 +
arch/arm/plat-omap/i2c.c|2 ++
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index db9374b..dea1425 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -147,7 +147,7 @@ static void __init omap_2430sdp_init_irq(void)
{
omap_board_config = sdp2430_config;
omap_board_config_size = ARRAY_SIZE(sdp2430_config);
- omap2_init_common_hw(NULL, NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c067416..5c65d2d 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -500,6 +500,7 @@ DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show,
sleep_timeout_store);
#define DEV_CREATE_FILE(dev, attr) WARN_ON(device_create_file(dev, attr))
#else
static inline void omap_uart_idle_init(struct omap_uart_state *uart) {}
+static inline void omap_uart_block_sleep(struct omap_uart_state *uart){}
Should be like this for new entries:
static inline void omap_uart_block_sleep(struct omap_uart_state *uart)
{
}
Maybe also update the omap_uart_idle_init the same way?
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index fb447c1..f8eb3a0 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -117,6 +117,8 @@ static void omap_i2c_set_wfc_mpu_wkup_lat(struct device
*dev, int val)
{
omap_pm_set_max_mpu_wakeup_lat(dev, val);
}
+#else
+static inline void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int
val){}
#endif
Here too.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register.
On Wed, 23 Dec 2009, Gopinath, Thara wrote: Hi Paul,Kevin.. Does this patch look ok? Hello Thara, looking over this patch. Nice job on the descriptive patch comment; it explains the problem well. What do you think about a slightly different approach -- that is, to add a hook to the hwmod code to invalidate the cache if the module's powerdomain has lost context? - Paul -- 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: regression: crash from 'ls /sys/modules/wl1251_spi/notes'
On Thu, 31 Dec 2009 22:15:08 +0100
Helge Deller del...@gmx.de wrote:
On 12/30/2009 04:49 PM, James Bottomley wrote:
A better, and more comprehensive patch would be to try not to count the
empty text sections when we're building the notes section (and actually
anywhere else in the file). This patch actually relies on the fact that
if sh_size is zero for the text section it should be for the
corresponding notes section. If that doesn't work, we'd actually have
to do the matching in the construction piece.
Can you try it to see if it works for you? If it doesn't, I'll try
matching notes to text. It works fine on parisc, but as we don't have a
notes section, that's not saying much ...
Thanks,
James
Ben Hutchings already sent a similar patch.
See: http://patchwork.kernel.org/patch/68925/
IMHO James patch below seems better since it
checks if a section will be allocated at a few more
places...
Ben's patch (which is below) is currently in linux-next, via a Rusty
tree. It is marked for -stable backporting.
If James's patch is preferable then there's an opportunity to do the
swap if we move promptly.
commit 9e9b48a89ed43c73d7355ff999b8e87b0628e1cd
Author: Ben Hutchings b...@decadent.org.uk
AuthorDate: Sat Dec 19 14:43:01 2009 +
Commit: Stephen Rothwell s...@canb.auug.org.au
CommitDate: Tue Jan 5 08:44:50 2010 +1100
modules: Skip empty sections when exporting section notes
Commit 35dead4 modules: don't export section names of empty sections
via sysfs changed the set of sections that have attributes, but did
not change the iteration over these attributes in add_notes_attrs().
This can lead to add_notes_attrs() creating attributes with the wrong
names or with null name pointers.
Introduce a sect_empty() function and use it in both add_sect_attrs()
and add_notes_attrs().
Reported-by: Martin Michlmayr t...@cyrius.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Tested-by: Martin Michlmayr t...@cyrius.com
Cc: sta...@kernel.org
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/kernel/module.c b/kernel/module.c
index e96b8ed..f82386b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1010,6 +1010,12 @@ static const struct kernel_symbol
*resolve_symbol(Elf_Shdr *sechdrs,
* J. Corbet cor...@lwn.net
*/
#if defined(CONFIG_KALLSYMS) defined(CONFIG_SYSFS)
+
+static inline bool sect_empty(const Elf_Shdr *sect)
+{
+ return !(sect-sh_flags SHF_ALLOC) || sect-sh_size == 0;
+}
+
struct module_sect_attr
{
struct module_attribute mattr;
@@ -1051,8 +1057,7 @@ static void add_sect_attrs(struct module *mod, unsigned
int nsect,
/* Count loaded sections and allocate structures */
for (i = 0; i nsect; i++)
- if (sechdrs[i].sh_flags SHF_ALLOC
-sechdrs[i].sh_size)
+ if (!sect_empty(sechdrs[i]))
nloaded++;
size[0] = ALIGN(sizeof(*sect_attrs)
+ nloaded * sizeof(sect_attrs-attrs[0]),
@@ -1070,9 +1075,7 @@ static void add_sect_attrs(struct module *mod, unsigned
int nsect,
sattr = sect_attrs-attrs[0];
gattr = sect_attrs-grp.attrs[0];
for (i = 0; i nsect; i++) {
- if (! (sechdrs[i].sh_flags SHF_ALLOC))
- continue;
- if (!sechdrs[i].sh_size)
+ if (sect_empty(sechdrs[i]))
continue;
sattr-address = sechdrs[i].sh_addr;
sattr-name = kstrdup(secstrings + sechdrs[i].sh_name,
@@ -1156,7 +1159,7 @@ static void add_notes_attrs(struct module *mod, unsigned
int nsect,
/* Count notes sections and allocate structures. */
notes = 0;
for (i = 0; i nsect; i++)
- if ((sechdrs[i].sh_flags SHF_ALLOC)
+ if (!sect_empty(sechdrs[i])
(sechdrs[i].sh_type == SHT_NOTE))
++notes;
@@ -1172,7 +1175,7 @@ static void add_notes_attrs(struct module *mod, unsigned
int nsect,
notes_attrs-notes = notes;
nattr = notes_attrs-attrs[0];
for (loaded = i = 0; i nsect; ++i) {
- if (!(sechdrs[i].sh_flags SHF_ALLOC))
+ if (sect_empty(sechdrs[i]))
continue;
if (sechdrs[i].sh_type == SHT_NOTE) {
nattr-attr.name = mod-sect_attrs-attrs[loaded].name;
--
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: problem with n810 boot up
Hi Luke, Luke-Jr wrote: On Tuesday 05 January 2010 05:24:56 pm Francisco Alecrim wrote: Luke-Jr wrote: Tested on Nokia N810 in Linux-OMAP tree. Mainline is not bootable yet. I'm with some problems to boot-up latest l-o(commit abb74381235a05f15a3b07e9e3831034942c67fb) with n810. The error message can be found below and full boot output in the end of email. dsme: No correct bootreason found, entering the malfunction state That's DSME, part of Maemo userland. You can possibly write a LD_PRELOAD workaround if you want to run it anyway... I tried but it doesn't work. I included a line to print the /proc/bootreason value and there is no bootreason. :P cat: /proc/bootreason: No such file or directory I guess that's the problem. What rootfs do you use? Did you change initfs? Gentoo. I modified my initfs to chainload its init if a new kernel is running. I don't know how to do it. Could you send me yours? Unfortunately, I have come to the realisation that moving forward with the Linux port to N8x0 would take me more time than simply spending the same time doing paid work and buying a N900* or Pandora instead. So short some other reimbursement for porting Linux to N8x0 (like maybe a promise of BME sources or a N900 after the rest is done to finish the job), I'm probably not going to spend any more time on it. :( Maybe, you're right. Or they can produce something using a SoC cheaper than OMAP3. Luke * N900 is supposedly mostly mainlined already, and supposedly Nokia will actually finish the job with unlike N8x0; it also has nicer hardware, even if you just ignore the cellular capabilities Thank you! :) Alecrim -- 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: problem with n810 boot up
On Tuesday 05 January 2010 08:46:27 pm Francisco Alecrim wrote: Luke-Jr wrote: On Tuesday 05 January 2010 05:24:56 pm Francisco Alecrim wrote: Luke-Jr wrote: Tested on Nokia N810 in Linux-OMAP tree. Mainline is not bootable yet. I'm with some problems to boot-up latest l-o(commit abb74381235a05f15a3b07e9e3831034942c67fb) with n810. The error message can be found below and full boot output in the end of email. dsme: No correct bootreason found, entering the malfunction state That's DSME, part of Maemo userland. You can possibly write a LD_PRELOAD workaround if you want to run it anyway... I tried but it doesn't work. I included a line to print the /proc/bootreason value and there is no bootreason. :P cat: /proc/bootreason: No such file or directory I guess that's the problem. Yeah, that file isn't supposed to exist. It was a Nokia-specific hack. What rootfs do you use? Did you change initfs? Gentoo. I modified my initfs to chainload its init if a new kernel is running. I don't know how to do it. Could you send me yours? special=false if echo -n /writetest; then exec /$(uname -r).log exec 21 /dmesg.static ls -lh /dev # ifconfig usb0 192.168.1.2 # mount -t proc proc proc # ifconfig -a # umount proc # sync if true; then echo A mount -t proc proc proc mount /dev/mmcblk0p1 /mnt/new_root || exec /bin/sh echo B cd /mnt/new_root mkdir -p mnt/initfs echo C pivot_root . mnt/initfs echo D cd / mount sync echo E exec /usr/bin/chroot / /sbin/init fi special=true fi -- 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
