Re: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
--- On Tue, 12/7/10, Dave Martin wrote: > From: Dave Martin > Subject: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6... > This makes sense, because Thumb-2 > code can't execute on anything > prior to ARMv7. WRONG ... but you may be overlooking the fact that there are at least three flavors of Thumb-2 ... - Original, as on some ARMv6 chips ARM1156 was the introductory Thumb2 core). It's Thumb1 plus a very few 32-bit instructions. (And maybe the SIMD instructions too; I forget. Not suitable for OS work like IRQ handling, ISTR; or at least, not as suitable as the ARMv7 flavors. -Microcontroller ... ARMv7M chips, and likely not available on Linux-capable hardware ... Suitable for RTOS work like IRQ handling. - Applications ... ARMv7A chips ... like those V6 chips with THUMB2, but with SIMD "multimedia" instructions and maybe a bit more. Worth tossing THUMB-EE in this bag too. > > > config THUMB2_KERNEL > bool "Compile the kernel in Thumb-2 > mode" > - depends on CPU_V7 && > EXPERIMENTAL > + depends on CPU_V7 && !CPU_V6 > && EXPERIMENTAL > select AEABI > select ARM_ASM_UNIFIED > help > -- > 1.7.1 > > -- > 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
[PATCH v2 resend] OMAP4: Pandaboard: Add omap_reserve functionality
This patch adds omap_reserve functionality to board-omap4panda.c. Helps in the reserving boot time memory in SDRAM, used here for framebuffer allocation. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Raghuveer Murthy --- arch/arm/mach-omap2/board-omap4panda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index da24745..0ccc24f 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") /* Maintainer: David Anders - Texas Instruments Inc */ .boot_params= 0x8100, .map_io = omap4_panda_map_io, + .reserve= omap_reserve, .init_irq = omap4_panda_init_irq, .init_machine = omap4_panda_init, .timer = &omap_timer, -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP4: Pandaboard: Add omap_reserve functionality
This patch adds omap_reserve functionality to board-omap4panda.c. Helps in the reserving boot time memory in SDRAM, used here for framebuffer allocation. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Cc: Russell King Cc: linux-...@lists.arm.linux.org.uk Signed-off-by: Raghuveer Murthy --- arch/arm/mach-omap2/board-omap4panda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index da24745..0ccc24f 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") /* Maintainer: David Anders - Texas Instruments Inc */ .boot_params= 0x8100, .map_io = omap4_panda_map_io, + .reserve= omap_reserve, .init_irq = omap4_panda_init_irq, .init_machine = omap4_panda_init, .timer = &omap_timer, -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Salut Benoît, On Tue, 7 Dec 2010, Cousson, Benoit wrote: > Salut Paul, > > On 12/7/2010 2:25 AM, Paul Walmsley wrote: > > Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files > > so they match their underlying OMAP hardware modules. Add clockdomain > > offset information. > > > > Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the > > SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI > > should do this. > > And we did it :-) Even better :-) > I sent it last week along with clock data series: > https://patchwork.kernel.org/patch/373751/ > > OK, I've just realized that it was a little bit hidden in the clock data > patch, and maybe we should have been sent two patches. > Sorry for that. Do you want to take it in that series, or should I re-sent the > clock data one? I guess it's better done in the clock series; that should avoid a branch dependency between the PRCM patchsets and the clock patch sets. One thing that would be nice on the scrm44xx.h file is to keep the _OFFSET macros. It would be nice in the long run to get rid of the absolute addressing macros in case someone decides to shuffle around the IP block addresses again... can you update your clock series with that change? Getting the clock patchsets put together for 2.6.38 is one of the next big projects here. - Paul
RE: [PATCH v6 8/8] Input: omap4 - pm runtime
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti > Sent: Monday, December 06, 2010 6:30 PM > To: Kevin Hilman; Arce, Abraham > Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org > Subject: RE: [PATCH v6 8/8] Input: omap4 - pm runtime > > > Kevin, > > -Original Message- > > From: linux-input-ow...@vger.kernel.org [mailto:linux-input- > > ow...@vger.kernel.org] On Behalf Of Kevin Hilman > > Sent: Thursday, September 30, 2010 7:21 PM > > To: Arce, Abraham > > Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org > > Subject: Re: [PATCH v6 8/8] Input: omap4 - pm runtime > > > > Abraham Arce writes: > > > > > Enable pm runtime in driver > > > > So power is enabled on probe and cut on _remove(). Did you consider > > doing any more fine grained PM for this device? For example, cutting > > power after some inactivity timer and re-enabling on a > > keypress/interrupt? > My idea is that the clock needs to be on to get interrupts (OMAP4 the > control is at module level and ick/fclk level control is difficult). > So disabling will prevent interrupts. > The keypad is in wakeup domain which is always on. So the power impact > may be minimal. > > What do you think. Kevin, I hope you are OK with this. > > > > Kevin > > > > > > > > > Reviewed-by: Basak, Partha > > > Signed-off-by: Abraham Arce > > > --- > > > drivers/input/keyboard/omap4-keypad.c |7 +++ > > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > > > diff --git a/drivers/input/keyboard/omap4-keypad.c > > b/drivers/input/keyboard/omap4-keypad.c > > > index 45bd097..ed47e9a 100644 > > > --- a/drivers/input/keyboard/omap4-keypad.c > > > +++ b/drivers/input/keyboard/omap4-keypad.c > > > @@ -29,6 +29,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include > > > > > > @@ -239,6 +240,9 @@ static int __devinit omap4_keypad_probe(struct > > platform_device *pdev) > > > matrix_keypad_build_keymap(pdata->keymap_data, row_shift, > > > input_dev->keycode, input_dev->keybit); > > > > > > + pm_runtime_enable(&pdev->dev); > > > + pm_runtime_get_sync(&pdev->dev); > > > + > > > omap4_keypad_config(keypad_data); > > > > > > error = request_irq(keypad_data->irq, omap4_keypad_interrupt, > > > @@ -277,6 +281,9 @@ static int __devexit omap4_keypad_remove(struct > > platform_device *pdev) > > > struct omap4_keypad *keypad_data = platform_get_drvdata(pdev); > > > struct resource *res; > > > > > > + pm_runtime_put_sync(&pdev->dev); > > > + pm_runtime_disable(&pdev->dev); > > > + > > > free_irq(keypad_data->irq, keypad_data); > > > input_unregister_device(keypad_data->input); > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > input" 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 -- 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
On Tue, 7 Dec 2010, Cousson, Benoit wrote: > On 12/7/2010 2:25 AM, Paul Walmsley wrote: > > [...] > > > + * > > + * XXX This file needs to be updated to align on one of "OMAP4", > > "OMAP44XX", > > + * or "OMAP4430". > > Yep, I was thinking to change that as well. My first thought was OMAP4 to get > a shorter name, but when we will introduce OMAP4440, we might have some new > entries, that will looks ugly close to OMAP4. > So at the end I will prefer OMAP44XX for the moment and we might renamed to > OMAP4430 or OMAP4440 for the entries that will diverge. > > Do you want to change that for 2.6.38? > It will require some sync with the various users of these defines, but that > should be doable. I don't mind waiting until after 2.6.38, I think we'll have a pretty huge pile of patches on our hands to merge already for .38... maybe Tony or Kevin have some opinions though. - 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/14] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part one
On Tue, 7 Dec 2010, Kevin Hilman wrote: > Paul Walmsley writes: > > > This patch series, intended for 2.6.38: > > [...] > > > Kevin, I'd appreciate review and acks, if appropriate, on the patches > > that touch code that you maintain. > > Reviewed-by: Kevin Hilman > Tested-by: Kevin Hilman > > I did some PM testing of this series on 34xx/n900 and 35xx/beagle using > retention idle & sususpend and off-idle and suspend. > > For testing with other PM features that are targetted for 2.6.38, I've > included it as part of my pm-core branch (which also includes your > previous hwmod series and the watchdog series, among other things.) Thanks for testing, Kevin, I'll update the patches accordingly. - 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 08/11] OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses
Reverse some of the effects of commit
84c0c39aec31a09571fc08a752a2f4da0fe9fcf2 ("ARM: OMAP4: PM: Make OMAP3
Clock-domain framework compatible for OMAP4"). On OMAP2/3, the
CM_CLKSTCTRL register is at a constant offset from the powerdomain's
CM instance.
Also, remove some of the direct CM register access from the
clockdomain code, moving it to the OMAP2/3 CM code instead. The
intention here is to simplify the clockdomain code. (The long-term
goal is to move all direct CM register access across the OMAP core
code to the appropriate cm*.c file.)
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c| 135 +++---
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 40 ---
arch/arm/mach-omap2/cm-regbits-24xx.h|5 +
arch/arm/mach-omap2/cm2xxx_3xxx.c| 68 +++
arch/arm/mach-omap2/cm2xxx_3xxx.h|9 +
arch/arm/plat-omap/include/plat/clockdomain.h|5 -
6 files changed, 127 insertions(+), 135 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index f83a1d4..84cdd1d 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -29,7 +29,7 @@
#include "prm2xxx_3xxx.h"
#include "prm-regbits-24xx.h"
#include "cm2xxx_3xxx.h"
-#include "cm-regbits-34xx.h"
+#include "cm-regbits-24xx.h"
#include "cminst44xx.h"
#include "prcm44xx.h"
@@ -244,30 +244,18 @@ static void _clkdm_del_autodeps(struct clockdomain *clkdm)
*/
static void _enable_hwsup(struct clockdomain *clkdm)
{
- u32 bits, v;
-
if (cpu_is_omap24xx())
- bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
+ omap2xxx_cm_clkdm_enable_hwsup(clkdm->pwrdm.ptr->prcm_offs,
+ clkdm->clktrctrl_mask);
else if (cpu_is_omap34xx())
- bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
+ omap3xxx_cm_clkdm_enable_hwsup(clkdm->pwrdm.ptr->prcm_offs,
+ clkdm->clktrctrl_mask);
else if (cpu_is_omap44xx())
return omap4_cminst_clkdm_enable_hwsup(clkdm->prcm_partition,
clkdm->cm_inst,
clkdm->clkdm_offs);
else
BUG();
-
- bits = bits << __ffs(clkdm->clktrctrl_mask);
-
- /*
-* XXX clkstctrl_reg is known on OMAP2 - this clkdm
-* field is not needed
-*/
- v = __raw_readl(clkdm->clkstctrl_reg);
- v &= ~(clkdm->clktrctrl_mask);
- v |= bits;
- __raw_writel(v, clkdm->clkstctrl_reg);
-
}
/**
@@ -280,29 +268,18 @@ static void _enable_hwsup(struct clockdomain *clkdm)
*/
static void _disable_hwsup(struct clockdomain *clkdm)
{
- u32 bits, v;
-
if (cpu_is_omap24xx())
- bits = OMAP24XX_CLKSTCTRL_DISABLE_AUTO;
+ omap2xxx_cm_clkdm_disable_hwsup(clkdm->pwrdm.ptr->prcm_offs,
+ clkdm->clktrctrl_mask);
else if (cpu_is_omap34xx())
- bits = OMAP34XX_CLKSTCTRL_DISABLE_AUTO;
+ omap3xxx_cm_clkdm_disable_hwsup(clkdm->pwrdm.ptr->prcm_offs,
+ clkdm->clktrctrl_mask);
else if (cpu_is_omap44xx())
return omap4_cminst_clkdm_disable_hwsup(clkdm->prcm_partition,
clkdm->cm_inst,
clkdm->clkdm_offs);
else
BUG();
-
- bits = bits << __ffs(clkdm->clktrctrl_mask);
-
- /*
-* XXX clkstctrl_reg is known on OMAP2 - this clkdm
-* field is not needed
-*/
- v = __raw_readl(clkdm->clkstctrl_reg);
- v &= ~(clkdm->clktrctrl_mask);
- v |= bits;
- __raw_writel(v, clkdm->clkstctrl_reg);
}
/* Public functions */
@@ -731,34 +708,6 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
}
/**
- * omap2_clkdm_clktrctrl_read - read the clkdm's current state transition mode
- * @clkdm: struct clkdm * of a clockdomain
- *
- * 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)
-{
- u32 v = 0;
-
- if (!clkdm)
- return -EINVAL;
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- v = __raw_readl(clkdm->clkstctrl_reg);
- v &= clkdm->clktrctrl_mask;
- v >>= __ffs(clkdm->clktrctrl_mask);
- } else if (cpu_is_omap44xx()) {
- pr_warn("OMAP4 clockdomain: missing wakeup/sleep deps\n");
- } else {
- BUG();
- }
-
- return v;
-}
-
-/**
* omap2_clkdm_sleep - force clockdomain sle
[PATCH 07/11] OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support
Add PRCM partition, CM instance register address offset, and clockdomain
register address offset to each OMAP4 struct clockdomain record. Add OMAP4
clockdomain code to use this new data to access registers properly.
While here, clean up some nearby clockdomain code to allocate auto variables
in my recollection of Linus's preferred style.
The autogeneration scripts have been updated.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Santosh Shilimkar
Cc: Benoît Cousson
---
arch/arm/mach-omap2/clockdomain.c | 75 ---
arch/arm/mach-omap2/clockdomains44xx_data.c | 121 +++--
arch/arm/mach-omap2/cm-regbits-34xx.h | 11 ++
arch/arm/mach-omap2/cminst44xx.c | 105 ++
arch/arm/plat-omap/include/plat/clockdomain.h | 20 +++-
5 files changed, 260 insertions(+), 72 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index b1a6908..f83a1d4 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -29,6 +29,9 @@
#include "prm2xxx_3xxx.h"
#include "prm-regbits-24xx.h"
#include "cm2xxx_3xxx.h"
+#include "cm-regbits-34xx.h"
+#include "cminst44xx.h"
+#include "prcm44xx.h"
#include
#include
@@ -245,13 +248,21 @@ static void _enable_hwsup(struct clockdomain *clkdm)
if (cpu_is_omap24xx())
bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
- else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ else if (cpu_is_omap34xx())
bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
+ else if (cpu_is_omap44xx())
+ return omap4_cminst_clkdm_enable_hwsup(clkdm->prcm_partition,
+ clkdm->cm_inst,
+ clkdm->clkdm_offs);
else
BUG();
bits = bits << __ffs(clkdm->clktrctrl_mask);
+ /*
+* XXX clkstctrl_reg is known on OMAP2 - this clkdm
+* field is not needed
+*/
v = __raw_readl(clkdm->clkstctrl_reg);
v &= ~(clkdm->clktrctrl_mask);
v |= bits;
@@ -271,21 +282,27 @@ static void _disable_hwsup(struct clockdomain *clkdm)
{
u32 bits, v;
- if (cpu_is_omap24xx()) {
+ if (cpu_is_omap24xx())
bits = OMAP24XX_CLKSTCTRL_DISABLE_AUTO;
- } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ else if (cpu_is_omap34xx())
bits = OMAP34XX_CLKSTCTRL_DISABLE_AUTO;
- } else {
+ else if (cpu_is_omap44xx())
+ return omap4_cminst_clkdm_disable_hwsup(clkdm->prcm_partition,
+ clkdm->cm_inst,
+ clkdm->clkdm_offs);
+ else
BUG();
- }
bits = bits << __ffs(clkdm->clktrctrl_mask);
+ /*
+* XXX clkstctrl_reg is known on OMAP2 - this clkdm
+* field is not needed
+*/
v = __raw_readl(clkdm->clkstctrl_reg);
v &= ~(clkdm->clktrctrl_mask);
v |= bits;
__raw_writel(v, clkdm->clkstctrl_reg);
-
}
/* Public functions */
@@ -723,14 +740,20 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
*/
static int omap2_clkdm_clktrctrl_read(struct clockdomain *clkdm)
{
- u32 v;
+ u32 v = 0;
if (!clkdm)
return -EINVAL;
- v = __raw_readl(clkdm->clkstctrl_reg);
- v &= clkdm->clktrctrl_mask;
- v >>= __ffs(clkdm->clktrctrl_mask);
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ v = __raw_readl(clkdm->clkstctrl_reg);
+ v &= clkdm->clktrctrl_mask;
+ v >>= __ffs(clkdm->clktrctrl_mask);
+ } else if (cpu_is_omap44xx()) {
+ pr_warn("OMAP4 clockdomain: missing wakeup/sleep deps\n");
+ } else {
+ BUG();
+ }
return v;
}
@@ -746,6 +769,8 @@ static int omap2_clkdm_clktrctrl_read(struct clockdomain
*clkdm)
*/
int omap2_clkdm_sleep(struct clockdomain *clkdm)
{
+ u32 bits, v;
+
if (!clkdm)
return -EINVAL;
@@ -762,16 +787,22 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
omap2_cm_set_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
clkdm->pwrdm.ptr->prcm_offs, OMAP2_PM_PWSTCTRL);
- } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+ } else if (cpu_is_omap34xx()) {
- u32 bits = (OMAP34XX_CLKSTCTRL_FORCE_SLEEP <<
-__ffs(clkdm->clktrctrl_mask));
+ bits = (OMAP34XX_CLKSTCTRL_FORCE_SLEEP <<
+ __ffs(clkdm->clktrctrl_mask));
- u32 v = __raw_readl(clkdm->clkstctrl_reg);
+ v = __raw_readl(clkdm->clkstctrl_reg);
v &= ~(clkdm->clktrctrl_mask);
v |= bits;
__raw_writel(v, clkdm->clkstctrl_reg)
[PATCH 05/11] OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup().
While here, also document that the autodeps are deprecated and that they
should be removed at the earliest opportunity.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clockdomain.c | 67 +++--
1 files changed, 49 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index da74f71..b1a6908 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -140,6 +140,9 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
* clockdomain is in hardware-supervised mode. Meant to be called
* once at clockdomain layer initialization, since these should remain
* fixed for a particular architecture. No return value.
+ *
+ * XXX autodeps are deprecated and should be removed at the earliest
+ * opportunity
*/
static void _autodep_lookup(struct clkdm_autodep *autodep)
{
@@ -167,6 +170,9 @@ static void _autodep_lookup(struct clkdm_autodep *autodep)
* Add the "autodep" sleep & wakeup dependencies to clockdomain 'clkdm'
* in hardware-supervised mode. Meant to be called from clock framework
* when a clock inside clockdomain 'clkdm' is enabled. No return value.
+ *
+ * XXX autodeps are deprecated and should be removed at the earliest
+ * opportunity
*/
static void _clkdm_add_autodeps(struct clockdomain *clkdm)
{
@@ -198,6 +204,9 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
* Remove the "autodep" sleep & wakeup dependencies from clockdomain 'clkdm'
* in hardware-supervised mode. Meant to be called from clock framework
* when a clock inside clockdomain 'clkdm' is disabled. No return value.
+ *
+ * XXX autodeps are deprecated and should be removed at the earliest
+ * opportunity
*/
static void _clkdm_del_autodeps(struct clockdomain *clkdm)
{
@@ -222,28 +231,50 @@ static void _clkdm_del_autodeps(struct clockdomain *clkdm)
}
}
-/*
- * _omap2_clkdm_set_hwsup - set the hwsup idle transition bit
+/**
+ * _enable_hwsup - set the hwsup idle transition bit
+ * @clkdm: struct clockdomain *
+ *
+ * XXX fix doco
+ * Internal helper for actually switching the bit that controls hwsup
+ * idle transitions for clkdm.
+ */
+static void _enable_hwsup(struct clockdomain *clkdm)
+{
+ u32 bits, v;
+
+ if (cpu_is_omap24xx())
+ bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
+ else if (cpu_is_omap34xx() || cpu_is_omap44xx())
+ bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
+ else
+ BUG();
+
+ bits = bits << __ffs(clkdm->clktrctrl_mask);
+
+ v = __raw_readl(clkdm->clkstctrl_reg);
+ v &= ~(clkdm->clktrctrl_mask);
+ v |= bits;
+ __raw_writel(v, clkdm->clkstctrl_reg);
+
+}
+
+/**
+ * _disable_hwsup - set the hwsup idle transition bit
* @clkdm: struct clockdomain *
- * @enable: int 0 to disable, 1 to enable
*
+ * XXX fix doco
* Internal helper for actually switching the bit that controls hwsup
* idle transitions for clkdm.
*/
-static void _omap2_clkdm_set_hwsup(struct clockdomain *clkdm, int enable)
+static void _disable_hwsup(struct clockdomain *clkdm)
{
u32 bits, v;
if (cpu_is_omap24xx()) {
- if (enable)
- bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
- else
- bits = OMAP24XX_CLKSTCTRL_DISABLE_AUTO;
+ bits = OMAP24XX_CLKSTCTRL_DISABLE_AUTO;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- if (enable)
- bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
- else
- bits = OMAP34XX_CLKSTCTRL_DISABLE_AUTO;
+ bits = OMAP34XX_CLKSTCTRL_DISABLE_AUTO;
} else {
BUG();
}
@@ -828,7 +859,7 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
_clkdm_add_autodeps(clkdm);
}
- _omap2_clkdm_set_hwsup(clkdm, 1);
+ _enable_hwsup(clkdm);
pwrdm_clkdm_state_switch(clkdm);
}
@@ -856,7 +887,7 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
pr_debug("clockdomain: disabling automatic idle transitions for %s\n",
clkdm->name);
- _omap2_clkdm_set_hwsup(clkdm, 0);
+ _disable_hwsup(clkdm);
/*
* XXX This should be removed once TI adds wakeup/sleep
@@ -916,9 +947,9 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm,
struct clk *clk)
if ((cpu_is_omap34xx() && v == OMAP34XX_CLKSTCTRL_ENABLE_AUTO) ||
(cpu_is_omap24xx() && v == OMAP24XX_CLKSTCTRL_ENABLE_AUTO)) {
/* Disable HW transitions when we are changing deps */
- _omap2_clkdm_set_hwsup(clkdm, 0);
+ _disable_hwsup(clkdm);
_clkdm_add_autodeps(clkdm);
- _omap2_clkdm_set_hwsup(clkdm, 1);
+ _enable_hwsup(clkdm);
[PATCH 11/11] OMAP3: control/PM: move padconf save code to mach-omap2/control.c
Move the padconf save code from pm34xx.c to the System Control Module
code in mach-omap2/control.c. This is part of the general push to
move direct register access from middle-layer core code to low-level
core code, so the middle-layer code can be abstracted to work on
multiple platforms and cleaned up.
In the medium-to-long term, this code should be called by the mux
layer code, not the PM idle code. This is because, according to the
TRM, saving the padconf only needs to be done when the padconf
changes[1].
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H]
Section 4.11.4 "Device Off-Mode Sequences"
---
arch/arm/mach-omap2/control.c | 32
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/pm34xx.c | 11 +--
arch/arm/plat-omap/include/plat/prcm.h |3 ---
4 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 16bde76..891df18 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -26,6 +26,10 @@
#include "pm.h"
#include "control.h"
+/* Used by omap3_ctrl_save_padconf() */
+#define START_PADCONF_SAVE 0x2
+#define PADCONF_SAVE_DONE 0x1
+
static void __iomem *omap2_ctrl_base;
static void __iomem *omap4_ctrl_pad_base;
@@ -512,4 +516,32 @@ void omap3_control_restore_context(void)
OMAP343X_CONTROL_PADCONF_SYSNIRQ);
return;
}
+
+/**
+ * omap3_ctrl_save_padconf - save padconf registers to scratchpad RAM
+ *
+ * Tell the SCM to start saving the padconf registers, then wait for
+ * the process to complete. Returns 0 unconditionally, although it
+ * should also eventually be able to return -ETIMEDOUT, if the save
+ * does not complete.
+ *
+ * XXX This function is missing a timeout. What should it be?
+ */
+int omap3_ctrl_save_padconf(void)
+{
+ u32 cpo;
+
+ /* Save the padconf registers */
+ cpo = omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
+ cpo |= START_PADCONF_SAVE;
+ omap_ctrl_writel(cpo, OMAP343X_CONTROL_PADCONF_OFF);
+
+ /* wait for the save to complete */
+ while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
+& PADCONF_SAVE_DONE))
+ udelay(1);
+
+ return 0;
+}
+
#endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a9325ad..5289461 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -351,6 +351,7 @@ extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
extern void omap3_ctrl_write_boot_mode(u8 bootmode);
+extern int omap3_ctrl_save_padconf(void);
#else
#define omap_ctrl_base_get() 0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e804a9f..be755a6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -117,16 +117,7 @@ static void omap3_disable_io_chain(void)
static void omap3_core_save_context(void)
{
- u32 control_padconf_off;
-
- /* Save the padconf registers */
- control_padconf_off = omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
- control_padconf_off |= START_PADCONF_SAVE;
- omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
- /* wait for the save to complete */
- while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
- & PADCONF_SAVE_DONE))
- udelay(1);
+ omap3_ctrl_save_padconf();
/*
* Force write last pad into memory, as this can fail in some
diff --git a/arch/arm/plat-omap/include/plat/prcm.h
b/arch/arm/plat-omap/include/plat/prcm.h
index 078906d..2fdf8c8 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -32,9 +32,6 @@ void omap_prcm_arch_reset(char mode, const char *cmd);
int omap2_cm_wait_idlest(void __iomem *reg, u32 mask, u8 idlest,
const char *name);
-#define START_PADCONF_SAVE 0x2
-#define PADCONF_SAVE_DONE 0x1
-
#endif
--
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/11] OMAP2+: powerdomain: move header file from plat-omap to mach-omap2
The OMAP powerdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h
to mach-omap2/powerdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access powerdomain code
and data directly.
As part of this process, remove the references to powerdomain data from
the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clockdomain.c|2 +
arch/arm/mach-omap2/clockdomain.h|2 +
arch/arm/mach-omap2/cpuidle34xx.c|2 +
arch/arm/mach-omap2/io.c |2 +
arch/arm/mach-omap2/omap_hwmod.c |2 +
arch/arm/mach-omap2/pm-debug.c |2 +
arch/arm/mach-omap2/pm.c |2 +
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm24xx.c |4 +--
arch/arm/mach-omap2/pm34xx.c |6 +++-
arch/arm/mach-omap2/pm44xx.c |2 +
arch/arm/mach-omap2/powerdomain-common.c |1 -
arch/arm/mach-omap2/powerdomain.c|2 +
arch/arm/mach-omap2/powerdomain.h| 23 +
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |2 +
arch/arm/mach-omap2/powerdomain44xx.c|3 +-
arch/arm/mach-omap2/powerdomains.h | 30 --
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |4 +--
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.h |2 +
arch/arm/mach-omap2/powerdomains2xxx_data.c |3 +-
arch/arm/mach-omap2/powerdomains3xxx_data.c |3 +-
arch/arm/mach-omap2/powerdomains44xx_data.c |3 +-
arch/arm/plat-omap/gpio.c|5 +---
arch/arm/plat-omap/include/plat/gpio.h |2 +
arch/arm/plat-omap/include/plat/omap-pm.h|2 -
arch/arm/plat-omap/omap-pm-noop.c|2 -
26 files changed, 44 insertions(+), 71 deletions(-)
rename arch/arm/{plat-omap/include/plat/powerdomain.h =>
mach-omap2/powerdomain.h} (92%)
delete mode 100644 arch/arm/mach-omap2/powerdomains.h
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index dadfb3f..4ebfa26 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -34,7 +34,7 @@
#include "prcm44xx.h"
#include
-#include
+#include "powerdomain.h"
#include "clockdomain.h"
#include
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 372c646..de3faa2 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -18,7 +18,7 @@
#include
-#include
+#include "powerdomain.h"
#include
#include
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 568dff7..81b0a90 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -27,7 +27,7 @@
#include
#include
-#include
+#include "powerdomain.h"
#include "clockdomain.h"
#include
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 1151f4a..a31acff 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -39,7 +39,7 @@
#include "io.h"
#include
-#include
+#include "powerdomain.h"
#include "clockdomain.h"
#include
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 10bd001..38652d0 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -139,7 +139,7 @@
#include
#include
#include "clockdomain.h"
-#include
+#include "powerdomain.h"
#include
#include
#include
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 3fc7707..ed892ae 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -29,7 +29,7 @@
#include
#include
-#include
+#include "powerdomain.h"
#include "clockdomain.h"
#include
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 60cfe67..cf1c4c9 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -18,7 +18,7 @@
#include
#include
-#include
+#include "powerdomain.h"
#include "clockdomain.h"
static struct omap_device_pm_latency *pm_lats;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..642e519 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -11,7 +11,7 @@
#ifndef __ARCH_ARM_MACH_OMAP2_PM_H
#define __ARCH_ARM_MACH_OMAP2_PM_H
-#include
+#include "powerdomain.h"
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 7d4933b..0413314 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -50,7 +50,7 @@
[PATCH 09/11] OMAP2+: clockdomain: move header file from plat-omap to mach-omap2
The OMAP clockdomain code and data is all OMAP2+-specific. This seems
unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h
to mach-omap2/clockdomain.h. The primary point of doing this is to remove
the temptation for unrelated upper-layer code to access clockdomain code
and data directly.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/mach-omap2/clockdomain.c|2 +-
arch/arm/mach-omap2/clockdomain.h|6 ++
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
arch/arm/mach-omap2/cpuidle34xx.c|2 +-
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/omap_hwmod.c |2 +-
arch/arm/mach-omap2/pm-debug.c |2 +-
arch/arm/mach-omap2/pm.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/powerdomain.c|2 +-
13 files changed, 14 insertions(+), 16 deletions(-)
rename arch/arm/{plat-omap/include/plat/clockdomain.h =>
mach-omap2/clockdomain.h} (97%)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index cda2f1d..2a2f152 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -24,7 +24,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include
#include
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 84cdd1d..dadfb3f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include
/* clkdm_list contains all registered struct clockdomains */
diff --git a/arch/arm/plat-omap/include/plat/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
similarity index 97%
rename from arch/arm/plat-omap/include/plat/clockdomain.h
rename to arch/arm/mach-omap2/clockdomain.h
index e91ae92..372c646 100644
--- a/arch/arm/plat-omap/include/plat/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -11,12 +11,10 @@
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
- *
- * XXX This should be moved to mach-omap2/ at the earliest opportunity.
*/
-#ifndef __ASM_ARM_ARCH_OMAP_CLOCKDOMAIN_H
-#define __ASM_ARM_ARCH_OMAP_CLOCKDOMAIN_H
+#ifndef __ARCH_ARM_MACH_OMAP2_CLOCKDOMAIN_H
+#define __ARCH_ARM_MACH_OMAP2_CLOCKDOMAIN_H
#include
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 6e9ec49..e4a7133 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -35,7 +35,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include "prm2xxx_3xxx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-24xx.h"
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 2d3d1ef..51920fc 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -26,7 +26,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include "cm1_44xx.h"
#include "cm2_44xx.h"
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d50b45..568dff7 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include "clockdomain.h"
#include
#include "pm.h"
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d05638ac..1151f4a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -41,7 +41,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 63d3f4d..10bd001 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -138,7 +138,7 @@
#include
#include
-#include
+#include "clockdomain.h"
#include
#include
#include
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 73f8ec0..3fc7707 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include "clockdomain.h"
#include
#include "cm2xxx_3xxx.h"
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 59ca03b..60cfe67 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -19,7 +19,7 @@
#include
#include
-#include
+#include "clockdomain.h"
static struct omap_device_pm_latency *pm_lats;
diff --git a/a
[PATCH 04/11] OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions
OMAP4 powerdomain control registers are split between the PRM hardware
module and the PRCM_MPU local PRCM. Add this PRCM partition
information to each OMAP4 powerdomain record, and convert the OMAP4
powerdomain function implementations to use the OMAP4 PRM instance
functions.
Also fixes a potential null pointer dereference of pwrdm->name.
The autogeneration scripts have been updated.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Santosh Shilimkar
Cc: Benoît Cousson
---
arch/arm/mach-omap2/powerdomain.c | 10 ++
arch/arm/mach-omap2/powerdomain44xx.c | 122 +
arch/arm/mach-omap2/powerdomains44xx_data.c | 17 +++
arch/arm/plat-omap/include/plat/powerdomain.h |7 +
4 files changed, 115 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 8a0dcd0..a76ad3f 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -20,6 +20,7 @@
#include
#include
#include "cm2xxx_3xxx.h"
+#include "prcm44xx.h"
#include "cm44xx.h"
#include "prm2xxx_3xxx.h"
#include "prm44xx.h"
@@ -72,12 +73,19 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
{
int i;
- if (!pwrdm)
+ if (!pwrdm || !pwrdm->name)
return -EINVAL;
if (!omap_chip_is(pwrdm->omap_chip))
return -EINVAL;
+ if (cpu_is_omap44xx() &&
+ pwrdm->prcm_partition == OMAP4430_INVALID_PRCM_PARTITION) {
+ pr_err("powerdomain: %s: missing OMAP4 PRCM partition ID\n",
+ pwrdm->name);
+ return -EINVAL;
+ }
+
if (_pwrdm_lookup(pwrdm->name))
return -EEXIST;
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 4c5ab1a..28bf5e3 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -20,48 +20,70 @@
#include
#include "prm2xxx_3xxx.h"
#include "prm44xx.h"
+#include "prminst44xx.h"
#include "prm-regbits-44xx.h"
#include "powerdomains.h"
static int omap4_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
- omap2_prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
- (pwrst << OMAP_POWERSTATE_SHIFT),
- pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
+ omap4_prminst_rmw_inst_reg_bits(OMAP_POWERSTATE_MASK,
+ (pwrst << OMAP_POWERSTATE_SHIFT),
+ pwrdm->prcm_partition,
+ pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
return 0;
}
static int omap4_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
{
- return omap2_prm_read_mod_bits_shift(pwrdm->prcm_offs,
- OMAP4_PM_PWSTCTRL, OMAP_POWERSTATE_MASK);
+ u32 v;
+
+ v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
+ OMAP4_PM_PWSTCTRL);
+ v &= OMAP_POWERSTATE_MASK;
+ v >>= OMAP_POWERSTATE_SHIFT;
+
+ return v;
}
static int omap4_pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
- return omap2_prm_read_mod_bits_shift(pwrdm->prcm_offs,
- OMAP4_PM_PWSTST, OMAP_POWERSTATEST_MASK);
+ u32 v;
+
+ v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
+ OMAP4_PM_PWSTST);
+ v &= OMAP_POWERSTATEST_MASK;
+ v >>= OMAP_POWERSTATEST_SHIFT;
+
+ return v;
}
static int omap4_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
{
- return omap2_prm_read_mod_bits_shift(pwrdm->prcm_offs, OMAP4_PM_PWSTST,
- OMAP4430_LASTPOWERSTATEENTERED_MASK);
+ u32 v;
+
+ v = omap4_prminst_read_inst_reg(pwrdm->prcm_partition, pwrdm->prcm_offs,
+ OMAP4_PM_PWSTST);
+ v &= OMAP4430_LASTPOWERSTATEENTERED_MASK;
+ v >>= OMAP4430_LASTPOWERSTATEENTERED_SHIFT;
+
+ return v;
}
static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
{
- omap2_prm_rmw_mod_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
- (1 << OMAP4430_LOWPOWERSTATECHANGE_SHIFT),
- pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
+ (1 <<
OMAP4430_LOWPOWERSTATECHANGE_SHIFT),
+ pwrdm->prcm_partition,
+ pwrdm->prcm_offs, OMAP4_PM_PWSTCTRL);
return 0;
}
static int omap4_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm)
{
- omap2_prm_rmw_mod_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK,
- OMAP4430_LASTPOWERSTATEENTERED_MASK,
- pwrdm->prcm_offs, OMAP
[PATCH 06/11] OMAP4: CM instances: add clockdomain register offsets
In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP, CM_DYNAMICDEP, and the module-specific registers underneath) are organized by clockdomain. Add the clockdomain offset macros to the appropriate PRCM module header files. This data was almost completely autogenerated from the TI hardware database; the autogeneration scripts have been updated. Signed-off-by: Paul Walmsley Cc: Benoît Cousson --- arch/arm/mach-omap2/cm1_44xx.h |5 + arch/arm/mach-omap2/cm2_44xx.h | 19 +++ arch/arm/mach-omap2/prcm_mpu44xx.h |5 + arch/arm/mach-omap2/prm44xx.h | 15 +++ 4 files changed, 44 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h index 63ef9e3..e2d7a56 100644 --- a/arch/arm/mach-omap2/cm1_44xx.h +++ b/arch/arm/mach-omap2/cm1_44xx.h @@ -40,6 +40,11 @@ #define OMAP4430_CM1_RESTORE_INST 0x0e00 #define OMAP4430_CM1_INSTR_INST0x0f00 +/* CM1 clockdomain register offsets (from instance start) */ +#define OMAP4430_CM1_ABE_ABE_CDOFFS0x +#define OMAP4430_CM1_MPU_MPU_CDOFFS0x +#define OMAP4430_CM1_TESLA_TESLA_CDOFFS0x + /* CM1 */ /* CM1.OCP_SOCKET_CM1 register offsets */ diff --git a/arch/arm/mach-omap2/cm2_44xx.h b/arch/arm/mach-omap2/cm2_44xx.h index 0fd0210..aa47450 100644 --- a/arch/arm/mach-omap2/cm2_44xx.h +++ b/arch/arm/mach-omap2/cm2_44xx.h @@ -46,6 +46,25 @@ #define OMAP4430_CM2_RESTORE_INST 0x1e00 #define OMAP4430_CM2_INSTR_INST0x1f00 +/* CM2 clockdomain register offsets (from instance start) */ +#define OMAP4430_CM2_ALWAYS_ON_ALWON_CDOFFS0x +#define OMAP4430_CM2_CORE_L3_1_CDOFFS 0x +#define OMAP4430_CM2_CORE_L3_2_CDOFFS 0x0100 +#define OMAP4430_CM2_CORE_DUCATI_CDOFFS0x0200 +#define OMAP4430_CM2_CORE_SDMA_CDOFFS 0x0300 +#define OMAP4430_CM2_CORE_MEMIF_CDOFFS 0x0400 +#define OMAP4430_CM2_CORE_D2D_CDOFFS 0x0500 +#define OMAP4430_CM2_CORE_L4CFG_CDOFFS 0x0600 +#define OMAP4430_CM2_CORE_L3INSTR_CDOFFS 0x0700 +#define OMAP4430_CM2_IVAHD_IVAHD_CDOFFS0x +#define OMAP4430_CM2_CAM_CAM_CDOFFS0x +#define OMAP4430_CM2_DSS_DSS_CDOFFS0x +#define OMAP4430_CM2_GFX_GFX_CDOFFS0x +#define OMAP4430_CM2_L3INIT_L3INIT_CDOFFS 0x +#define OMAP4430_CM2_L4PER_L4PER_CDOFFS0x +#define OMAP4430_CM2_L4PER_L4SEC_CDOFFS0x0180 +#define OMAP4430_CM2_CEFUSE_CEFUSE_CDOFFS 0x + /* CM2 */ diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h index e5190e9..729a644 100644 --- a/arch/arm/mach-omap2/prcm_mpu44xx.h +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h @@ -37,6 +37,11 @@ #define OMAP4430_PRCM_MPU_CPU0_INST0x0400 #define OMAP4430_PRCM_MPU_CPU1_INST0x0800 +/* PRCM_MPU clockdomain register offsets (from instance start) */ +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x + + /* * PRCM_MPU * diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 95542ae..67a0d3f 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -56,6 +56,21 @@ #define OMAP4430_PRM_DEVICE_INST 0x1b00 #define OMAP4430_PRM_INSTR_INST0x1f00 +/* PRM clockdomain register offsets (from instance start) */ +#define OMAP4430_PRM_MPU_MPU_CDOFFS0x +#define OMAP4430_PRM_TESLA_TESLA_CDOFFS0x +#define OMAP4430_PRM_ABE_ABE_CDOFFS0x +#define OMAP4430_PRM_CORE_CORE_CDOFFS 0x +#define OMAP4430_PRM_IVAHD_IVAHD_CDOFFS0x +#define OMAP4430_PRM_CAM_CAM_CDOFFS0x +#define OMAP4430_PRM_DSS_DSS_CDOFFS0x +#define OMAP4430_PRM_GFX_GFX_CDOFFS0x +#define OMAP4430_PRM_L3INIT_L3INIT_CDOFFS 0x +#define OMAP4430_PRM_L4PER_L4PER_CDOFFS0x +#define OMAP4430_PRM_CEFUSE_CEFUSE_CDOFFS 0x +#define OMAP4430_PRM_WKUP_CM_WKUP_CDOFFS 0x +#define OMAP4430_PRM_EMU_EMU_CDOFFS0x +#define OMAP4430_PRM_EMU_CM_EMU_CDOFFS 0x /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -- 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/11] OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file
Move the OMAP4 global software reset function to the OMAP4-specific
prm44xx.c file, where it belongs. Part of the long-term process of
moving all of the direct PRCM register writes into lower-layer code.
Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
will continue executing while the system is supposed to be resetting
itself.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/prcm.c| 17 -
arch/arm/mach-omap2/prm44xx.c | 14 ++
arch/arm/mach-omap2/prm44xx.h |2 ++
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fe0865b..68c541f 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -68,17 +68,16 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
} else if (cpu_is_omap34xx()) {
prcm_offs = OMAP3430_GR_MOD;
omap3_ctrl_write_boot_mode((cmd ? (u8)*cmd : 0));
- } else if (cpu_is_omap44xx())
- prcm_offs = OMAP4430_PRM_DEVICE_INST;
- else
+ } else if (cpu_is_omap44xx()) {
+ omap4_prm_global_warm_sw_reset(); /* never returns */
+ } else {
WARN_ON(1);
+ }
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
- prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
-OMAP2_RM_RSTCTRL);
- if (cpu_is_omap44xx())
- prm_set_mod_reg_bits(OMAP4430_RST_GLOBAL_WARM_SW_MASK,
-prcm_offs, OMAP4_RM_RSTCTRL);
+ /* XXX should be moved to some OMAP2/3 specific code */
+ prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
+OMAP2_RM_RSTCTRL);
+ prm_read_mod_reg(prcm_offs, OMAP2_RM_RSTCTRL); /* OCP barrier */
}
/**
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index c016ae4..a2a04bf 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -179,3 +179,17 @@ int omap4_prm_deassert_hardreset(void __iomem
*rstctrl_reg, u8 shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+void omap4_prm_global_warm_sw_reset(void)
+{
+ u32 v;
+
+ v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_RM_RSTCTRL);
+ v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
+ omap4_prm_write_inst_reg(v, OMAP4430_PRM_DEVICE_INST,
+OMAP4_RM_RSTCTRL);
+
+ /* OCP barrier */
+ v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+ OMAP4_RM_RSTCTRL);
+}
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 3588653..95542ae 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -756,6 +756,8 @@ extern int omap4_prm_is_hardreset_asserted(void __iomem
*rstctrl_reg, u8 shift);
extern int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
extern int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
+extern void omap4_prm_global_warm_sw_reset(void);
+
# endif
#endif
--
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 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a "local PRCM" exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which "PRCM partition" to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Signed-off-by: Paul Walmsley Cc: Benoît Cousson Cc: Rajendra Nayak Cc: Santosh Shilimkar --- arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/cm1_44xx.h |5 + arch/arm/mach-omap2/cm2_44xx.h |6 ++ arch/arm/mach-omap2/cm44xx.c | 52 ++ arch/arm/mach-omap2/cm4xxx.c | 62 - arch/arm/mach-omap2/cminst44xx.c | 118 arch/arm/mach-omap2/prcm.c | 26 --- arch/arm/mach-omap2/prcm44xx.h | 42 +++ arch/arm/mach-omap2/prcm_mpu44xx.c | 45 arch/arm/mach-omap2/prcm_mpu44xx.h |8 ++ arch/arm/mach-omap2/prm44xx.c | 65 ++ arch/arm/mach-omap2/prm44xx.h |6 ++ arch/arm/mach-omap2/prminst44xx.c | 74 arch/arm/mach-omap2/prminst44xx.h | 25 +++ arch/arm/plat-omap/include/plat/prcm.h |7 +- 15 files changed, 454 insertions(+), 91 deletions(-) create mode 100644 arch/arm/mach-omap2/cm44xx.c delete mode 100644 arch/arm/mach-omap2/cm4xxx.c create mode 100644 arch/arm/mach-omap2/cminst44xx.c create mode 100644 arch/arm/mach-omap2/prcm44xx.h create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c create mode 100644 arch/arm/mach-omap2/prminst44xx.c create mode 100644 arch/arm/mach-omap2/prminst44xx.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 7f3302f..0fa48a882 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,7 +68,9 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o # XXX The presence of cm2xxx_3xxx.o on the line below is temporary and # will be removed once the OMAP4 part of the codebase is converted to # use OMAP4-specific PRCM functions. -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cm4xxx.o +obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ + cm44xx.o prcm_mpu44xx.o \ + prminst44xx.o # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h index aa2ee78..63ef9e3 100644 --- a/arch/arm/mach-omap2/cm1_44xx.h +++ b/arch/arm/mach-omap2/cm1_44xx.h @@ -248,4 +248,9 @@ #define OMAP4_CM_DYN_DEP_PRESCAL_RESTORE_OFFSET0x0040 #define OMAP4430_CM_DYN_DEP_PRESCAL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_INST, 0x0040) +/* Function prototypes */ +extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx); +extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx); +extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); + #endif diff --git a/arch/arm/mach-omap2/cm2_44xx.h b/arch/arm/mach-omap2/cm2_44xx.h index 89c9522..0fd0210 100644 --- a/arch/arm/mach-omap2/cm2_44xx.h +++ b/arch/arm/mach-omap2/cm2_44xx.h @@ -480,4 +480,10 @@ #define OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL_RESTORE OMAP44XX_CM2_REGADDR(OMAP4430_CM2_RESTORE_INST, 0x0058) #define OMAP4_CM_SDMA_STATICDEP_RESTORE_OFFSET 0x005c #define OMAP4430_CM_SDMA_STATICDEP_RESTORE OMAP44XX_CM2_REGADDR(OMAP4430_CM2_RESTORE_INST, 0x005c) + +/* Function prototyp
[PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part two
This patch series, intended for 2.6.38:
- adds OMAP4-specific PRM and CM instance functions, which are capable
of writing to PRM/CM instances, no matter what PRCM partition they
appear in;
- renames the old OMAP2/3 PRM and CM functions to prefix them with
'omap2_';
- adds OMAP4 clockdomain offset addressing to the OMAP4 clockdomain
definitions;
- removes the (now unused) OMAP clockdomain .clkstctrl_reg field;
- moves plat-omap/include/plat/{clock,power}domain.h to mach-omap2/, since
these are OMAP2-specific;
- moves the OMAP3 SCM padconf save code from pm34xx.c into the SCM common
code.
This series is available via git from git://git.pwsan.com/linux-2.6 in
the branch 'pwrdm_prcm_b_2.6.38'. It applies on top of the "OMAP:
PRCM/powerdomain/clockdomain patches for 2.6.38, part one" series,
sent earlier.
Kevin and OMAP ASoC-hackers, I'd appreciate review and acks, if
appropriate, on the patches that touch code that you maintain. TI
OMAP4 PM people, I would appreciate any testing assistance that you
may be able to provide. Benoît, I've tried to keep the kernel data
files and the output of the scripts relatively similar, but we might
need to do some tweaking of the scripts or data files to align them
in the way that makes the most sense.
Boot-tested on N800, OMAP35xx Beagle, and OMAP4430ES2 Panda.
- Paul
---
pwrdm_prcm_b_2.6.38
textdata bss dec hex filename
5709988 473952 5608800 11792740 b3f164 vmlinux.orig
5712868 474496 5608800 11796164 b3fec4 vmlinux.patched
Paul Walmsley (11):
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific
file
OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with "omap2_"
OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions
OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
OMAP4: CM instances: add clockdomain register offsets
OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support
OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct
CM register accesses
OMAP2+: clockdomain: move header file from plat-omap to mach-omap2
OMAP2+: powerdomain: move header file from plat-omap to mach-omap2
OMAP3: control/PM: move padconf save code to mach-omap2/control.c
arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/clkt2xxx_apll.c | 10 -
arch/arm/mach-omap2/clkt2xxx_dpllcore.c |8
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 12 -
arch/arm/mach-omap2/clock.c |2
arch/arm/mach-omap2/clockdomain.c| 209 ++-
arch/arm/mach-omap2/clockdomain.h| 33 +-
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 42 --
arch/arm/mach-omap2/clockdomains44xx_data.c | 123 --
arch/arm/mach-omap2/cm-regbits-24xx.h|5
arch/arm/mach-omap2/cm-regbits-34xx.h| 11 +
arch/arm/mach-omap2/cm1_44xx.h | 10 +
arch/arm/mach-omap2/cm2_44xx.h | 25 +
arch/arm/mach-omap2/cm2xxx_3xxx.c| 420 +-
arch/arm/mach-omap2/cm2xxx_3xxx.h| 19 +
arch/arm/mach-omap2/cm44xx.c | 52 +++
arch/arm/mach-omap2/cm4xxx.c | 62 ---
arch/arm/mach-omap2/cminst44xx.c | 223
arch/arm/mach-omap2/control.c| 72 +++-
arch/arm/mach-omap2/control.h|1
arch/arm/mach-omap2/cpuidle34xx.c|4
arch/arm/mach-omap2/io.c |4
arch/arm/mach-omap2/omap_hwmod.c |4
arch/arm/mach-omap2/pm-debug.c | 12 -
arch/arm/mach-omap2/pm.c |4
arch/arm/mach-omap2/pm.h |2
arch/arm/mach-omap2/pm24xx.c | 200 +-
arch/arm/mach-omap2/pm34xx.c | 162
arch/arm/mach-omap2/pm44xx.c |2
arch/arm/mach-omap2/powerdomain-common.c |1
arch/arm/mach-omap2/powerdomain.c| 14 +
arch/arm/mach-omap2/powerdomain.h| 30 +-
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 68 ++--
arch/arm/mach-omap2/powerdomain44xx.c| 122 --
arch/arm/mach-omap2/powerdomains.h | 30 --
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |4
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.h |2
arch/arm/mach-omap2/powerdomains2xxx_data.c |3
arch/arm/mach-omap2/powerdomains3xxx_data.c |3
arch/arm/mach-omap2/powerdomains44xx_data.c | 20 +
arch/arm/mach-omap2/prcm.c | 51 +--
arch/arm/mach-omap2/prcm44xx.h | 42 ++
arch/arm/mach-omap2/prcm_mpu44xx.c | 45 ++
arch/arm/mach
Re: [PATCH 0/7] usb: otg: TWL6030: OMAP4430: musb & transceiver driver support for OMAP4
Please ignore this series of patches. I sent the older version the patches by mistake. I will send new versions again. Sorry for cluttering .. Regards, Hema On Wed, Dec 8, 2010 at 5:39 AM, Hema HK wrote: > This patch series has the support for TWL6030-usb > transceiver driver and changes in the musb driver to make it functional > with OMAP4430. > > OMAP4 musb support UTMI and ULPI transceiver interfaces. > > In UTMI mode, the transceiver functionality is split between > the TWL6030 PMIC chip and OMAP4 embedded PHY. > The TWL6030 transceiver driver code is under otg folder and > internal UTMI PHY specific code changes are defined under > mach-omap2 directory and functions are passed through platform_data > structure. > > This patch series is based on V2.6.37-rc4 + [1]+[2]+[3]+[4]. > > [1] http://www.listware.net/201011/linux-usb/ > 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html > > [2] http://www.spinics.net/lists/linux-usb/msg37105.html > > [3] http://permalink.gmane.org/gmane.linux.usb.general/37123 > > [4] Felipe's musb-reorg patch series. > http://gitorious.org/usb/usb/commits/musb-hw > > Tested musb device and host mode functionality with OMAP4430SDP > and OMAP3630 ZOOM3. > > Cc: Felipe Balbi > Cc: Tony Lindgren > Cc: David Brownell > Cc: Samuel Ortiz > --- > > Hema HK (7): > mfd: TWL6030: USBOTG VBUS event generation on charger VBUS events. > usb: otg: Adding twl6030-usb transceiver driver for OMAP4430 musb > usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver. > mfd: TWL6030: OMAP4: Registering the TWL6030-usb device > usb: musb: TWL6030: Selecting TWL6030_USB transceiver for OMAP4 > usb: musb: Adding musb support for OMAP4430 > arm: OMAP4430: musb: Enable musb device initialization for OMAP4430 > > arch/arm/mach-omap2/Makefile | 1 + > arch/arm/mach-omap2/board-4430sdp.c | 15 +- > arch/arm/mach-omap2/board-omap4panda.c | 9 +- > arch/arm/mach-omap2/omap_phy_internal.c | 123 +++ > arch/arm/plat-omap/include/plat/usb.h | 4 + > drivers/mfd/twl-core.c | 44 +++- > drivers/mfd/twl6030-irq.c | 9 +- > drivers/usb/musb/Kconfig | 1 + > drivers/usb/musb/musb_core.c | 5 + > drivers/usb/musb/musb_core.h | 1 + > drivers/usb/musb/musb_gadget.c | 1 + > drivers/usb/musb/omap2430.c | 85 +- > drivers/usb/otg/Kconfig | 11 + > drivers/usb/otg/Makefile | 1 + > drivers/usb/otg/twl6030-usb.c | 527 > +++ > include/linux/i2c/twl.h | 6 + > 16 files changed, 824 insertions(+), 19 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 v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
Dave, > -Original Message- > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > Sent: Wednesday, December 08, 2010 11:27 AM > To: Dave Martin > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > o...@vger.kernel.org; linaro-...@lists.linaro.org > Subject: RE: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > forCONFIG_THUMB2_KERNEL > > > -Original Message- > > From: Dave Martin [mailto:dave.mar...@linaro.org] > > Sent: Tuesday, December 07, 2010 10:21 PM > > To: Santosh Shilimkar > > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > > o...@vger.kernel.org; linaro-...@lists.linaro.org > > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > > forCONFIG_THUMB2_KERNEL > > > > Hi, > > > > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar > > wrote: > > > Dave, [.] > > > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 > > capable (and hence reasonably new) tools. > > > > I'll follow up shortly with a patch to the generic ARM Kconfig to make > > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally > > be configured together. > > > sure When you are doing the changes can you please check if you could build the THUMB2 kernel with omap2plus_defconfig. I suspect the build will fail. Regards, Santosh -- 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 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
> -Original Message- > From: Dave Martin [mailto:dave.mar...@linaro.org] > Sent: Tuesday, December 07, 2010 10:21 PM > To: Santosh Shilimkar > Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux- > o...@vger.kernel.org; linaro-...@lists.linaro.org > Subject: Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > forCONFIG_THUMB2_KERNEL > > Hi, > > On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar > wrote: > > Dave, > >> -Original Message- > >> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- > >> boun...@lists.linaro.org] On Behalf Of Dave Martin > >> Sent: Monday, December 06, 2010 11:06 PM > >> To: linux-arm-ker...@lists.infradead.org > >> Cc: Tony Lindgren; Dave Martin; linux-omap@vger.kernel.org; linaro- > >> d...@lists.linaro.org > >> Subject: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() > >> forCONFIG_THUMB2_KERNEL > >> > >> For the Thumb-2 case, the "wfi" mnemonic is used, since in this > >> case the tools will necessarily be new enough to support it. > >> > >> Signed-off-by: Dave Martin > >> --- > >> KernelVersion: 2.6.37-rc4 > > > > The choice of opcode instead of instruction here was not because > > of toolchain. The problem was it breaks multi-omap build where > > ARMv6 and ARMv7 are build together. > > > > For this reason I NAK this patch. > > You can't built a kernel for pre-v7 platforms with > CONFIG_THUMB2_KERNEL: the code can't run on those platforms because > they don't support Thumb-2. > That's better. > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 > capable (and hence reasonably new) tools. > > I'll follow up shortly with a patch to the generic ARM Kconfig to make > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally > be configured together. > sure -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] arm: OMAP4430: musb: Enable musb device initialization for OMAP4430
musb device registration during board initialization of OMAP4430SDP
and OMAP4430 PANDA.Enable the musb OTG mode.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|6 ++
arch/arm/mach-omap2/board-omap4panda.c |2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,7 +227,7 @@ static void __init omap_4430sdp_init_irq
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
- .mode = MUSB_PERIPHERAL,
+ .mode = MUSB_OTG,
.power = 100,
};
@@ -522,9 +522,7 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
- if (!cpu_is_omap44xx())
- usb_musb_init(&musb_board_data);
+ usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
if (status) {
Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
+++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
@@ -133,7 +133,7 @@ error1:
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
- .mode = MUSB_PERIPHERAL,
+ .mode = MUSB_OTG,
.power = 100,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: musb: Adding musb support for OMAP4430
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
musb driver is register for atomic notifications from the transceiver
driver to get the event notifications for connect/disconnect and ID-GND.
Based on these events call the transceiver init/shutdown function to
configure the transceiver to toggle the VBUS valid, session end and ID_GND
signals to musb.
For ID_GND event notifications, toggle the ID_GND signal and then wait for
musb to be configured as "A" device, and then call the transceiver function
to set the VBUS.
using otg_get_last_event function to get the missed transceiver events
if the cable or device is connected before registration(musb driver load).
In OTG mode and musb as a host, When the Micro A connector used, VBUS is turned
on
and session bit set. When the device is connected, enumeration goes through.
When the device disconnected from the other end of the connector(ID is still
grounded),
link will detect the disconnect and end the session. When the device is
connected back,
there are no events generated in the TWL6030-usb, and link is already down.So
the device is
not detected.Removed the session bit disable code which will recognize the
connect of the device..
Signed-off-by: Hema HK
Cc: Felipe Balbi
---
drivers/usb/musb/musb_core.c |5 ++
drivers/usb/musb/musb_core.h |1
drivers/usb/musb/musb_gadget.c |1
drivers/usb/musb/omap2430.c| 88 ++---
4 files changed, 89 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/usb/musb/musb_core.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.c
+++ linux-2.6/drivers/usb/musb/musb_core.c
@@ -2116,6 +2116,11 @@ bad_config:
& MUSB_DEVCTL_BDEVICE
? 'B' : 'A'));
+ /*
+* Host only mode, check whether the device is already
+* connected
+*/
+ otg_get_last_event(musb->xceiv);
} else /* peripheral is enabled */ {
MUSB_DEV_MODE(musb);
musb->xceiv->default_a = 0;
Index: linux-2.6/drivers/usb/musb/musb_core.h
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -411,6 +411,7 @@ struct musb {
struct timer_list otg_timer;
#endif
+ struct notifier_block nb;
/* called with IRQs blocked; ON/nonzero implies starting a session,
* and waiting at least a_wait_vrise_tmout.
Index: linux-2.6/drivers/usb/musb/musb_gadget.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_gadget.c
+++ linux-2.6/drivers/usb/musb/musb_gadget.c
@@ -1809,6 +1809,7 @@ int usb_gadget_probe_driver(struct usb_g
hcd->self.uses_pio_for_control = 1;
}
}
+ otg_get_last_event(musb->xceiv);
}
return retval;
Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c
@@ -57,13 +57,8 @@ static void musb_do_idle(unsigned long _
spin_lock_irqsave(&musb->lock, flags);
- devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
-
switch (musb->xceiv->state) {
case OTG_STATE_A_WAIT_BCON:
- devctl &= ~MUSB_DEVCTL_SESSION;
- musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
-
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE) {
musb->xceiv->state = OTG_STATE_B_IDLE;
@@ -142,20 +137,34 @@ static void omap2430_try_idle(struct mus
static void omap2430_set_vbus(struct musb *musb, int is_on)
{
u8 devctl;
+ long int timeout = 0x;
/* HDRC controls CPEN, but beware current surges during device
* connect. They can trigger transient overcurrent conditions
* that must be ignored.
*/
-
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
if (is_on) {
- musb->is_active = 1;
- musb->xceiv->default_a = 1;
-
[PATCH 5/7] usb: musb: TWL6030: Selecting TWL6030_USB transceiver
Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and adding OMAP4 internal phy code for compilation Signed-off-by: Hema HK Cc: Felipe Balbi Cc: Tony Lindgren --- arch/arm/mach-omap2/Makefile |1 + drivers/usb/musb/Kconfig |1 + 2 files changed, 2 insertions(+) Index: linux-2.6/arch/arm/mach-omap2/Makefile === --- linux-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-2.6/arch/arm/mach-omap2/Makefile @@ -180,6 +180,7 @@ obj-$(CONFIG_MACH_SBC3530) += board-oma usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o obj-y += $(usbfs-m) $(usbfs-y) obj-y += usb-musb.o +obj-$(CONFIG_TWL6030_USB) += omap_phy_internal.o obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o obj-y += usb-ehci.o Index: linux-2.6/drivers/usb/musb/Kconfig === --- linux-2.6.orig/drivers/usb/musb/Kconfig +++ linux-2.6/drivers/usb/musb/Kconfig @@ -12,6 +12,7 @@ config USB_MUSB_HDRC depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP + select TWL6030_USB if (MACH_OMAP_3430SDP || MACH_OMAP4_PANDA) select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' help -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] mfd: TWL6030: OMAP4: Registering the TWL6030-usb device
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to be used twl630-usb driver.
Signed-off-by: Hema HK
Cc: Samuel Ortiz
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|9 +-
arch/arm/mach-omap2/board-omap4panda.c |7 +
drivers/mfd/twl-core.c | 44 +
include/linux/i2c/twl.h|6
4 files changed, 59 insertions(+), 7 deletions(-)
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -231,6 +231,13 @@ static struct omap_musb_board_data musb_
.power = 100,
};
+static struct twl4030_usb_data omap4_usbphy_data = {
+ .phy_init = omap4430_phy_init,
+ .phy_exit = omap4430_phy_exit,
+ .phy_power = omap4430_phy_power,
+ .phy_set_clock = omap4430_phy_set_clk,
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -450,6 +457,7 @@ static struct twl4030_platform_data sdp4
.vaux1 = &sdp4430_vaux1,
.vaux2 = &sdp4430_vaux2,
.vaux3 = &sdp4430_vaux3,
+ .usb= &omap4_usbphy_data
};
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
@@ -514,8 +522,6 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* OMAP4 SDP uses internal transceiver so register nop transceiver */
- usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(&musb_board_data);
Index: linux-2.6/drivers/mfd/twl-core.c
===
--- linux-2.6.orig/drivers/mfd/twl-core.c
+++ linux-2.6/drivers/mfd/twl-core.c
@@ -95,7 +95,8 @@
#define twl_has_rtc() false
#endif
-#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE)
+#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE) ||\
+ defined(CONFIG_TWL6030_USB) || defined(CONFIG_TWL6030_USB_MODULE)
#define twl_has_usb() true
#else
#define twl_has_usb() false
@@ -682,6 +683,43 @@ add_children(struct twl4030_platform_dat
usb3v1.dev = child;
}
}
+ if (twl_has_usb() && pdata->usb && twl_class_is_6030()) {
+
+ static struct regulator_consumer_supply usb3v3 = {
+ .supply = "vusb",
+ };
+
+ if (twl_has_regulator()) {
+ /* this is a template that gets copied */
+ struct regulator_init_data usb_fixed = {
+ .constraints.valid_modes_mask =
+ REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .constraints.valid_ops_mask =
+ REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ };
+
+ child = add_regulator_linked(TWL6030_REG_VUSB,
+ &usb_fixed, &usb3v3, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
+ child = add_child(0, "twl6030_usb",
+ pdata->usb, sizeof(*pdata->usb),
+ true,
+ /* irq1 = VBUS_PRES, irq0 = USB ID*/
+ pdata->irq_base + USBOTG_INTR_OFFSET,
+ pdata->irq_base + USB_PRES_INTR_OFFSET);
+
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ /* we need to connect regulators to this transceiver */
+ if (twl_has_regulator() && child)
+ usb3v3.dev = child;
+
+ }
if (twl_has_watchdog()) {
child = add_child(0, "twl4030_wdt", NULL, 0, false, 0, 0);
@@ -815,10 +853,6 @@ add_children(struct twl4030_platform_dat
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6030_REG_VUSB, pdata->vusb);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
child = add_regulator(TWL6030_REG_VAUX1_6030, pdata->vaux1);
if (IS_ERR(child))
return PTR_ERR(child);
Index: linux-2.6/
[PATCH 3/7] usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver.
Added the TWL6030-usb transceiver option in the Kconfig Signed-off-by: Hema HK Cc: Felipe Balbi Cc: David Brownell --- drivers/usb/otg/Kconfig | 12 1 file changed, 12 insertions(+) Index: linux-2.6/drivers/usb/otg/Kconfig === --- linux-2.6.orig/drivers/usb/otg/Kconfig +++ linux-2.6/drivers/usb/otg/Kconfig @@ -59,6 +59,18 @@ config TWL4030_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config TWL6030_USB + tristate "TWL6030 USB Transceiver Driver" + depends on TWL4030_CORE + select USB_OTG_UTILS + help + Enable this to support the USB OTG transceiver on TWL6030 + family chips. This TWL6030 transceiver has the VBUS and ID GND + and OTG SRP events capabilities. For all other transceiver functionality + UTMI PHY is embedded in OMAP4430.The internal PHY configurations APIs + are hooked to this driver through platform_data structure. + The definition of internal PHY APIs are in the mach-omap2 layer. + config NOP_USB_XCEIV tristate "NOP USB Transceiver Driver" select USB_OTG_UTILS -- 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/7] usb: otg: Adding twl6030-usb transceiver driver for
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
Cc: David Brownell
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h |4
drivers/usb/otg/Makefile|1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,148 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#defineAVALID BIT(0)
+#defineBVALID BIT(1)
+#defineVBUSVALID BIT(2)
+#defineSESSEND BIT(3)
+#defineIDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, "control module ioremap failed\n");
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n");
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m");
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n");
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, "usb_phy_cm_clk32k");
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n");
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+ static int state;
+
+ if (on && !state) {
+ /* Enable the phy clocks */
+ clk_enable(phyclk);
+ clk_enable(clk48m);
+ clk_enable(clk32k);
+ state = 1;
+ } else if (state) {
+ /* Disable the phy clocks */
+ clk_disable(phyclk);
+ clk_disable(clk48m);
+ clk_disable(clk32k);
+ state = 0;
+ }
+ return 0;
+}
+
+int omap4430_phy_power(struct
[PATCH 0/7] usb: otg: TWL6030: OMAP4430: musb & transceiver driver support for OMAP4
This patch series has the support for TWL6030-usb transceiver driver and changes in the musb driver to make it functional with OMAP4430. OMAP4 musb support UTMI and ULPI transceiver interfaces. In UTMI mode, the transceiver functionality is split between the TWL6030 PMIC chip and OMAP4 embedded PHY. The TWL6030 transceiver driver code is under otg folder and internal UTMI PHY specific code changes are defined under mach-omap2 directory and functions are passed through platform_data structure. This patch series is based on V2.6.37-rc4 + [1]+[2]+[3]+[4]. [1] http://www.listware.net/201011/linux-usb/ 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html [2] http://www.spinics.net/lists/linux-usb/msg37105.html [3] http://permalink.gmane.org/gmane.linux.usb.general/37123 [4] Felipe's musb-reorg patch series. http://gitorious.org/usb/usb/commits/musb-hw Tested musb device and host mode functionality with OMAP4430SDP and OMAP3630 ZOOM3. Cc: Felipe Balbi Cc: Tony Lindgren Cc: David Brownell Cc: Samuel Ortiz --- Hema HK (7): mfd: TWL6030: USBOTG VBUS event generation on charger VBUS events. usb: otg: Adding twl6030-usb transceiver driver for OMAP4430 musb usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver. mfd: TWL6030: OMAP4: Registering the TWL6030-usb device usb: musb: TWL6030: Selecting TWL6030_USB transceiver for OMAP4 usb: musb: Adding musb support for OMAP4430 arm: OMAP4430: musb: Enable musb device initialization for OMAP4430 arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-4430sdp.c | 15 +- arch/arm/mach-omap2/board-omap4panda.c |9 +- arch/arm/mach-omap2/omap_phy_internal.c | 123 +++ arch/arm/plat-omap/include/plat/usb.h |4 + drivers/mfd/twl-core.c | 44 +++- drivers/mfd/twl6030-irq.c |9 +- drivers/usb/musb/Kconfig|1 + drivers/usb/musb/musb_core.c|5 + drivers/usb/musb/musb_core.h|1 + drivers/usb/musb/musb_gadget.c |1 + drivers/usb/musb/omap2430.c | 85 +- drivers/usb/otg/Kconfig | 11 + drivers/usb/otg/Makefile|1 + drivers/usb/otg/twl6030-usb.c | 527 +++ include/linux/i2c/twl.h |6 + 16 files changed, 824 insertions(+), 19 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 1/7] mfd: TWL6030: USBOTG VBUS event generation on
With TWL6030-usb, VBUS SESS_VLD and SESS_END events are not generated
as expected. When these interrupts are enabled, charger VBUS detection
interrupt does not get generated. So USBOTG has to be dependent on charger
VBUS interrupts.
So added one bit for USBOTG and changed the handler to call the
USBOTG handler whenever there is a charger VBUS interrpt.
VBUS SESS_VLD and SESS_END event generation issue is under debug with
HW team. This fix might not be required once after fixing the issue.
Signed-off-by: Balaji TK
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Samuel Ortiz
---
drivers/mfd/twl6030-irq.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/mfd/twl6030-irq.c
===
--- linux-2.6.orig/drivers/mfd/twl6030-irq.c
+++ linux-2.6/drivers/mfd/twl6030-irq.c
@@ -74,7 +74,7 @@ static int twl6030_interrupt_mapping[24]
USBOTG_INTR_OFFSET, /* Bit 16 ID_WKUP */
USBOTG_INTR_OFFSET, /* Bit 17 VBUS_WKUP */
USBOTG_INTR_OFFSET, /* Bit 18 ID */
- USBOTG_INTR_OFFSET, /* Bit 19 VBUS*/
+ USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
CHARGER_INTR_OFFSET,/* Bit 21 EXT_CHRG*/
CHARGER_INTR_OFFSET,/* Bit 22 INT_CHRG*/
@@ -128,6 +128,13 @@ static int twl6030_irq_thread(void *data
sts.bytes[3] = 0; /* Only 24 bits are valid*/
+ /*
+* Since VBUS status bit is not reliable for VBUS disconnect
+* use CHARGER VBUS detection status bit instead.
+*/
+ if (sts.bytes[2] & 0x10)
+ sts.bytes[2] |= 0x08;
+
for (i = 0; sts.int_sts; sts.int_sts >>= 1, i++) {
local_irq_disable();
if (sts.int_sts & 0x1) {
--
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 12/11] omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xx
Tony, On Wed, Dec 8, 2010 at 04:53, Tony Lindgren wrote: > * Tony Lindgren [101204 13:16]: >> * Varadarajan, Charulatha [101202 06:08]: >> > On Thu, Dec 2, 2010 at 15:28, Kevin Hilman >> > wrote: >> > >> > > >> > > Tony, you can also add >> > > >> > > Acked-by: Kevin Hilman >> >> OK, updated. Also made one more GPIO patch to allow us to deal >> with the 7xx vs 15xx/16xx MPUIO registers. Thanks for this patch which uses bank stride for OMAP1 MPUIO GPIO. This would be very helpful while doing GPIO driver cleanup. Thanks, V Charulatha > > Turns out that broke drivers/mtd/nand/ams-delta.c as it directly uses > multiple lines in parallel. So let's use 15xx/16xx offsets instead > and divide them by two. > > Regards, > > Tony > > > From: Tony Lindgren > Date: Sat, 4 Dec 2010 12:39:43 -0800 > Subject: [PATCH] omap1: Fix gpio mpuio bank to work for multi-omap for > 7xx/15xx/16xx > > We need to divide the 15xx/16xx offset by 2 for 7xx. Use bank->stride > for that. This allows us to get rid of the duplicate defines for the > MPUIO registers. > > Note that this will cause omap-keypad.c driver to not work on 7xx. > However, the right fix there is to move over to gpio-keys instead as > suggested by Cory Maccarrone and > Janusz Krzysztofik . > > Cc: Cory Maccarrone > Cc: Janusz Krzysztofik > Signed-off-by: Tony Lindgren > <> -- 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] omap: Disable omap_read/write functions for omap2+
* Tony Lindgren [101207 17:32]:
> * Tony Lindgren [101204 13:27]:
> > These should be now long gone and break multi-omap support for omap1
> > as the cpu_class_is_omap1() won't work until the SOC is detected.
> >
> > So just disable and warn for omap2+ in case somebody still attampts
> > to use these.
>
> Heh this was totally not working and had several copy paste bugs..
> Instead of including more files, let's just make them dummy inline
> functions.
One more time, this time let's just split it for omap1 and omap2,
at least omap2 still depends on it.. Fixing it is another series.
Regards,
Tony
From: Tony Lindgren
Date: Tue, 7 Dec 2010 16:57:01 -0800
Subject: [PATCH] omap: Split omap_read/write functions for omap1 and omap2+
Otherwise multi-omap1 support for omap1 won't work as the cpu_class_is_omap1()
won't work until the SoC is detected.
Note that eventually these will go away, please use ioremap + read/write
instead.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 0ce3fec..870886a 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -142,3 +142,42 @@ void __init omap1_init_common_hw(void)
omap1_mux_init();
}
+/*
+ * NOTE: Please use ioremap + __raw_read/write where possible instead of these
+ */
+
+u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readb);
+
+u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readw);
+
+u32 omap_readl(u32 pa)
+{
+ return __raw_readl(OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readl);
+
+void omap_writeb(u8 v, u32 pa)
+{
+ __raw_writeb(v, OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writeb);
+
+void omap_writew(u16 v, u32 pa)
+{
+ __raw_writew(v, OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writew);
+
+void omap_writel(u32 v, u32 pa)
+{
+ __raw_writel(v, OMAP1_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3d18349..9804385 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -375,3 +375,43 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap_irq_base_init();
}
+
+/*
+ * NOTE: Please use ioremap + __raw_read/write where possible instead of these
+ */
+
+u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readb);
+
+u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readw);
+
+u32 omap_readl(u32 pa)
+{
+ return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_readl);
+
+void omap_writeb(u8 v, u32 pa)
+{
+ __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writeb);
+
+void omap_writew(u16 v, u32 pa)
+{
+ __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writew);
+
+void omap_writel(u32 v, u32 pa)
+{
+ __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index b0078cf..f1295fa 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -136,61 +136,3 @@ void omap_iounmap(volatile void __iomem *addr)
__iounmap(addr);
}
EXPORT_SYMBOL(omap_iounmap);
-
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-
-u8 omap_readb(u32 pa)
-{
- if (cpu_class_is_omap1())
- return __raw_readb(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readb);
-
-u16 omap_readw(u32 pa)
-{
- if (cpu_class_is_omap1())
- return __raw_readw(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readw);
-
-u32 omap_readl(u32 pa)
-{
- if (cpu_class_is_omap1())
- return __raw_readl(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readl);
-
-void omap_writeb(u8 v, u32 pa)
-{
- if (cpu_class_is_omap1())
- __raw_writeb(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writeb);
-
-void omap_writew(u16 v, u32 pa)
-{
- if (cpu_class_is_omap1())
- __raw_writew(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writew);
-
-void omap_writel(u32 v, u32 pa)
-{
- if (cpu_class_is_omap1())
- __raw_writel(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writel);
--
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.ht
Re: State of LDP3430 platform
On Tue, 7 Dec 2010, Paul Walmsley wrote: > I do have a LDP3430 here though. It doesn't boot past: > > [0.00] Linux version 2.6.37-rc5 (p...@twilight) (gcc version 4.3.2 > (Sourcery G++ Lite 2008q3-72) ) #68 SMP Tue Dec 7 17:42:20 > [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f > [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction > cache > [0.00] Machine: OMAP Zoom2 board > [0.00] debug: ignoring loglevel setting. > [0.00] bootconsole [earlycon0] enabled > [0.00] Memory policy: ECC disabled, Data cache writeback > [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) > [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 > > Looking into it now. My Zoom2 dies in the memset() in omap2_map_sram(). Not sure why, since yours seems to make it quite a bit further. It dies in the same place with 2.6.36. The Zoom2 here may be broken; it does not receive regular use. Regarding the watchdog problem, unfortunately, I can't reproduce on the BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or omap2plus_defconfig without CONFIG_WATCHDOG. If you send along your .config, one of us can try to reproduce the problem with it. Do the 2.6.38 hwmod and wdt patchsets fix the problem for .38, at least? - 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] MFD: TWL/TPS: fix twl_probe section mismatch warning in mfd/twl-core.c
Fix the following section mismatch warning when building omap2plus_defconfig:
WARNING: vmlinux.o(.data+0x47d7c): Section mismatch in reference from the
variable twl_driver to the function .init.text:twl_probe()
Signed-off-by: Bryan Wu
Signed-off-by: Paul Walmsley
---
drivers/mfd/twl-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 35275ba..3aa46ff 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -969,7 +969,7 @@ static int twl_remove(struct i2c_client *client)
}
/* NOTE: this driver only handles a single twl4030/tps659x0 chip */
-static int __init
+static int __devinit
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
int status;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: kill all section mismatch warning for omap2plus_defconfig
This patch will kill following section mismatch warnings:
WARNING: vmlinux.o(.text+0x24a00): Section mismatch in reference from the
function zoom_twl_gpio_setup() to the (unknown reference) .init.data:(unknown)
The function zoom_twl_gpio_setup() references
the (unknown reference) __initdata (unknown).
This is often because zoom_twl_gpio_setup lacks a __initdata
annotation or the annotation of (unknown) is wrong.
WARNING: vmlinux.o(.text+0x24bfc): Section mismatch in reference from the
function cm_t35_twl_gpio_setup() to the (unknown reference) .init.data:(unknown)
The function cm_t35_twl_gpio_setup() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_twl_gpio_setup lacks a __initdata
annotation or the annotation of (unknown) is wrong.
WARNING: vmlinux.o(.data+0x1d3e0): Section mismatch in reference from the
variable h4_config to the (unknown reference) .init.data:(unknown)
The variable h4_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0x1dc08): Section mismatch in reference from the
variable sdp2430_config to the (unknown reference) .init.data:(unknown)
The variable sdp2430_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0x1e1d8): Section mismatch in reference from the
variable apollon_config to the (unknown reference) .init.data:(unknown)
The variable apollon_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Bryan Wu
Cc: Paul Walmsley
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c | 11 +++
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
5 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index b527f8d..9ab8bb1 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -135,7 +135,7 @@ static inline void board_smc91x_init(void)
#endif
-static struct omap_board_config_kernel sdp2430_config[] = {
+static struct omap_board_config_kernel sdp2430_config[] __initdata = {
{OMAP_TAG_LCD, &sdp2430_lcd_config},
};
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 2c6db1a..5c432d8 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -270,7 +270,7 @@ static struct omap_lcd_config apollon_lcd_config __initdata
= {
.ctrl_name = "internal",
};
-static struct omap_board_config_kernel apollon_config[] = {
+static struct omap_board_config_kernel apollon_config[] __initdata = {
{ OMAP_TAG_LCD, &apollon_lcd_config },
};
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..cd97159 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -600,8 +600,8 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[0] = OMAP_MAX_GPIO_LINES + 6,
+ .reset_gpio_port[1] = OMAP_MAX_GPIO_LINES + 7,
.reset_gpio_port[2] = -EINVAL
};
@@ -630,12 +630,6 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
cm_t35_vmmc1_supply.dev = mmc[0].dev;
cm_t35_vsim_supply.dev = mmc[0].dev;
- /* setup USB with proper PHY reset GPIOs */
- ehci_pdata.reset_gpio_port[0] = gpio + 6;
- ehci_pdata.reset_gpio_port[1] = gpio + 7;
-
- usb_ehci_init(&ehci_pdata);
-
return 0;
}
@@ -805,6 +799,7 @@ static void __init cm_t35_init(void)
cm_t35_init_display();
usb_musb_init(&musb_board_data);
+ usb_ehci_init(&ehci_pdata);
}
MACHINE_START(CM_T35, "Compulab CM-T35")
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 929993b..5549f2c 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -283,7 +283,7 @@ static struct omap_usb_config h4_usb_config __initdata = {
.hmc_mode = 0x00, /* 0:dev|otg 1:disable 2:disable */
};
-static struct omap_board_con
Re: [PATCH 2/7] usb: otg: Adding twl6030-usb transceiver driver for
Hema,
On Tue, Dec 7, 2010 at 6:11 PM, Hema HK wrote:
> Adding the twl6030-usb transceiver support for OMAP4 musb driver.
>
> OMAP4 supports 2 types of transceiver interface.
> +}
> +
> +int omap4430_phy_set_clk(struct device *dev, int on)
> +{
> + static int state;
probably good to initialize to zero.
> +
> + if (on && !state) {
Thank you,
Best regards,
Hari
--
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] omap1: Add omap1_defconfig
* Felipe Contreras [101207 04:28]: > On Sat, Dec 4, 2010 at 11:36 PM, Tony Lindgren wrote: > > The omap1_defconfig this should be eventually usable for booting > > all omap1 machines. Generated based on: > > > > $ grep ARCH_OMAP1=y arch/arm/configs/* | cut -d: -f1 | xargs cat | \ > > sort | uniq >> arch/arm/configs/omap1_defconfig > > > > Then change few things manually, like use Nokia 770 CONFIG_CMDLINE > > as it does not allow setting it in the bootloader. > > > > After make oldconfig, ran reduce_defconfig python script on it > > as posted by Uwe Kleine-König : > > AFAIK you should use 'make savedefconfig'. OK cool thanks for the tip. Updating the description for that and also will take out CONFIG_DEBUG_DRIVER=y as it's too noisy. 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
[PATCH 3/3] omap2+: Initialize omap_irq_base for entry-macro.S from platform code
This way we can use the generic omap SoC detection code instead.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 06e64e1..6032941 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -38,41 +38,27 @@
*/
#ifdef MULTI_OMAP2
+
+/*
+ * We use __glue to avoid errors with multiple definitions of
+ * .globl omap_irq_base as it's included from entry-armv.S but not
+ * from entry-common.S.
+ */
+#ifdef __glue
.pushsection .data
-omap_irq_base: .word 0
+ .globl omap_irq_base
+omap_irq_base:
+ .word 0
.popsection
+#endif
- /* Configure the interrupt base on the first interrupt */
+ /*
+* Configure the interrupt base on the first interrupt.
+* See also omap_irq_base_init for setting omap_irq_base.
+*/
.macro get_irqnr_preamble, base, tmp
-9:
ldr \base, =omap_irq_base @ irq base address
ldr \base, [\base, #0] @ irq base value
- cmp \base, #0 @ already configured?
- bne 9997f @ nothing to do
-
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x000f @ only check architecture
- cmp \tmp, #0x0007 @ is v6?
- beq 2400f @ found v6 so it's omap24xx
- mrc p15, 0, \tmp, c0, c0, 0 @ get processor revision
- and \tmp, \tmp, #0x00f0 @ check cortex 8 or 9
- cmp \tmp, #0x0080 @ cortex A-8?
- beq 3400f @ found A-8 so it's omap34xx
- cmp \tmp, #0x0090 @ cortex A-9?
- beq 4400f @ found A-9 so it's omap44xx
-2400: ldr \base, =OMAP2_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-3400: ldr \base, =OMAP3_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-4400: ldr \base, =OMAP4_IRQ_BASE
- ldr \tmp, =omap_irq_base
- str \base, [\tmp, #0]
- b 9b
-9997:
.endm
/* Check the pending interrupts. Note that base already set */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..3d18349 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -46,6 +46,7 @@
#include "clockdomains.h"
#include
+#include
/*
* The machine specific code may provide the extra mapping besides the
@@ -311,6 +312,25 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+/*
+ * Initialize asm_irq_base for entry-macro.S
+ */
+static inline void omap_irq_base_init(void)
+{
+ extern void __iomem *omap_irq_base;
+
+#ifdef MULTI_OMAP2
+ if (cpu_is_omap242x())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
+ else if (cpu_is_omap34xx())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
+ else if (cpu_is_omap44xx())
+ omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
+ else
+ pr_err("Could not initialize omap_irq_base\n");
+#endif
+}
+
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
@@ -352,4 +372,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
gpmc_init();
+
+ omap_irq_base_init();
}
--
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/4] Patches to make multi-soc handling in entry-armv.S easier
* Tony Lindgren [101204 19:00]: > * Nicolas Pitre [101204 18:26]: > > On Sat, 4 Dec 2010, Tony Lindgren wrote: > > > > My only problem with your approach is the global addition of > > asm_irq_base and asm_irq_flags in generic code which might not be useful > > and/or appropriate for all targets. If you were confining them to some > > OMAP specific file then I wouldn't mind as much. Looking at the patch I > > see that you had omap_irq_base before. Why wasn't that sufficient? > > Only omap_irq_flags would be missing. > > I guess I was thinking this is something that might help others > to build more machines into one defconfig. If that's not the case, > sure these can be kept omap specific. > > After a quick browsing of the entry-macro.S files, looks like > there's some similar ifdeffery for get_irqnr_* macros that just might > be possible to clear out with asm_irq_base and asm_irq_flags: > > arch/arm/mach-davinci/include/mach/entry-macro.S > arch/arm/mach-s5p64x0/include/mach/entry-macro.S > arch/arm/mach-ixp4xx/include/mach/entry-macro.S > arch/arm/mach-h720x/include/mach/entry-macro.S > arch/arm/plat-mxc/include/mach/entry-macro.S > > Maybe let's wait a while to see if there are other use cases, > if not, I'll make them omap specific. OK, no other people interested, will post the omap specific versions as a reply to this message. 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
[PATCH 2/3] omap1: Use get_irqnr_preamble
This saves some cycles for multiple interrupts case. Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S b/arch/arm/mach-omap1/include/mach/entry-macro.S index c9be6d4..584bf7b 100644 --- a/arch/arm/mach-omap1/include/mach/entry-macro.S +++ b/arch/arm/mach-omap1/include/mach/entry-macro.S @@ -31,13 +31,13 @@ omap_irq_flags: .endm .macro get_irqnr_preamble, base, tmp + ldr \base, =OMAP1_IO_ADDRESS(OMAP_IH1_BASE) .endm .macro arch_ret_to_user, tmp1, tmp2 .endm .macro get_irqnr_and_base, irqnr, irqstat, base, tmp - ldr \base, =OMAP1_IO_ADDRESS(OMAP_IH1_BASE) ldr \irqnr, [\base, #IRQ_ITR_REG_OFFSET] ldr \tmp, [\base, #IRQ_MIR_REG_OFFSET] mov \irqstat, #0x -- 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/3] omap1: Use asm_irq_flags for entry-macro.S
Initialize asm_irq_flags in omap_init_irq and use it in
get_irqnr_and_base to detect between omap7xx and omap15xx/16xx.
Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined
as 0, so use INT_1510_IH2_IRQ for both of them.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/include/mach/entry-macro.S
b/arch/arm/mach-omap1/include/mach/entry-macro.S
index df9060e..c9be6d4 100644
--- a/arch/arm/mach-omap1/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap1/include/mach/entry-macro.S
@@ -14,18 +14,17 @@
#include
#include
-#if (defined(CONFIG_ARCH_OMAP730)||defined(CONFIG_ARCH_OMAP850)) && \
- (defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX))
-#error "FIXME: OMAP7XX doesn't support multiple-OMAP"
-#elif defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
-#define INT_IH2_IRQINT_7XX_IH2_IRQ
-#elif defined(CONFIG_ARCH_OMAP15XX)
-#define INT_IH2_IRQINT_1510_IH2_IRQ
-#elif defined(CONFIG_ARCH_OMAP16XX)
-#define INT_IH2_IRQINT_1610_IH2_IRQ
-#else
-#warning "IH2 IRQ defaulted"
-#define INT_IH2_IRQINT_1510_IH2_IRQ
+/*
+ * We use __glue to avoid errors with multiple definitions of
+ * .globl omap_irq_flags as it's included from entry-armv.S but not
+ * from entry-common.S.
+ */
+#ifdef __glue
+ .pushsection .data
+ .globl omap_irq_flags
+omap_irq_flags:
+ .word 0
+ .popsection
#endif
.macro disable_fiq
@@ -47,9 +46,11 @@
beq 1510f
ldr \irqnr, [\base, #IRQ_SIR_FIQ_REG_OFFSET]
+ ldr \tmp, =omap_irq_flags @ irq flags address
+ ldr \tmp, [\tmp, #0]@ irq flags value
cmp \irqnr, #0
ldreq \irqnr, [\base, #IRQ_SIR_IRQ_REG_OFFSET]
- cmpeq \irqnr, #INT_IH2_IRQ
+ cmpeq \irqnr, \tmp
ldreq \base, =OMAP1_IO_ADDRESS(OMAP_IH2_BASE)
ldreq \irqnr, [\base, #IRQ_SIR_IRQ_REG_OFFSET]
addeqs \irqnr, \irqnr, #32
diff --git a/arch/arm/mach-omap1/irq.c b/arch/arm/mach-omap1/irq.c
index db913c3..6bddbc8 100644
--- a/arch/arm/mach-omap1/irq.c
+++ b/arch/arm/mach-omap1/irq.c
@@ -176,26 +176,31 @@ static struct irq_chip omap_irq_chip = {
void __init omap_init_irq(void)
{
+ extern unsigned int omap_irq_flags;
int i, j;
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
if (cpu_is_omap7xx()) {
+ omap_irq_flags = INT_7XX_IH2_IRQ;
irq_banks = omap7xx_irq_banks;
irq_bank_count = ARRAY_SIZE(omap7xx_irq_banks);
}
#endif
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
+ omap_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap1510_irq_banks;
irq_bank_count = ARRAY_SIZE(omap1510_irq_banks);
}
if (cpu_is_omap310()) {
+ omap_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap310_irq_banks;
irq_bank_count = ARRAY_SIZE(omap310_irq_banks);
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
if (cpu_is_omap16xx()) {
+ omap_irq_flags = INT_1510_IH2_IRQ;
irq_banks = omap1610_irq_banks;
irq_bank_count = ARRAY_SIZE(omap1610_irq_banks);
}
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..2910de9 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -77,7 +77,7 @@
/*
* OMAP-1610 specific IRQ numbers for interrupt handler 1
*/
-#define INT_1610_IH2_IRQ 0
+#define INT_1610_IH2_IRQ INT_1510_IH2_IRQ
#define INT_1610_IH2_FIQ 2
#define INT_1610_McBSP2_TX 4
#define INT_1610_McBSP2_RX 5
--
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] omap: Disable omap_read/write functions for omap2+
* Tony Lindgren [101204 13:27]:
> These should be now long gone and break multi-omap support for omap1
> as the cpu_class_is_omap1() won't work until the SOC is detected.
>
> So just disable and warn for omap2+ in case somebody still attampts
> to use these.
Heh this was totally not working and had several copy paste bugs..
Instead of including more files, let's just make them dummy inline
functions.
Tony
From: Tony Lindgren
Date: Tue, 7 Dec 2010 16:57:01 -0800
Subject: [PATCH] omap: Disable omap_read/write functions for omap2+
These should be now long gone and break multi-omap support for omap1
as the cpu_class_is_omap1() won't work until the SOC is detected.
So just disable them for omap2+.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/plat-omap/include/plat/io.h
b/arch/arm/plat-omap/include/plat/io.h
index 128b549..0e3b907 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -247,6 +247,8 @@
* NOTE: Please use ioremap + __raw_read/write where possible instead of these
*/
+#ifdef CONFIG_ARCH_OMAP1
+
extern u8 omap_readb(u32 pa);
extern u16 omap_readw(u32 pa);
extern u32 omap_readl(u32 pa);
@@ -254,6 +256,36 @@ extern void omap_writeb(u8 v, u32 pa);
extern void omap_writew(u16 v, u32 pa);
extern void omap_writel(u32 v, u32 pa);
+#else
+
+static inline u8 omap_readb(u32 pa)
+{
+ return 0;
+}
+
+static inline u16 omap_readw(u32 pa)
+{
+ return 0;
+}
+
+static inline u32 omap_readl(u32 pa)
+{
+ return 0;
+}
+
+static inline void omap_writeb(u8 v, u32 pa)
+{
+}
+
+static inline void omap_writew(u16 v, u32 pa)
+{
+}
+
+static inline void omap_writel(u32 v, u32 pa)
+{
+}
+#endif
+
struct omap_sdrc_params;
extern void omap1_map_common_io(void);
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index b0078cf..b89182b 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -138,59 +138,45 @@ void omap_iounmap(volatile void __iomem *addr)
EXPORT_SYMBOL(omap_iounmap);
/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
+ * NOTE: Please use ioremap + __raw_read/write where possible instead of these.
+ * These are only working for omap1 and will disappear eventually.
*/
+#ifdef CONFIG_ARCH_OMAP1
u8 omap_readb(u32 pa)
{
- if (cpu_class_is_omap1())
- return __raw_readb(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+ return __raw_readb(OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_readb);
u16 omap_readw(u32 pa)
{
- if (cpu_class_is_omap1())
- return __raw_readw(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+ return __raw_readw(OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_readw);
u32 omap_readl(u32 pa)
{
- if (cpu_class_is_omap1())
- return __raw_readl(OMAP1_IO_ADDRESS(pa));
- else
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
+ return __raw_readl(OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_readl);
void omap_writeb(u8 v, u32 pa)
{
- if (cpu_class_is_omap1())
- __raw_writeb(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
+ __raw_writeb(v, OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_writeb);
void omap_writew(u16 v, u32 pa)
{
- if (cpu_class_is_omap1())
- __raw_writew(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
+ __raw_writew(v, OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_writew);
void omap_writel(u32 v, u32 pa)
{
- if (cpu_class_is_omap1())
- __raw_writel(v, OMAP1_IO_ADDRESS(pa));
- else
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
+ __raw_writel(v, OMAP1_IO_ADDRESS(pa));
}
EXPORT_SYMBOL(omap_writel);
+
+#endif
--
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] MFD: TWL/TPS: fix twl_probe section mismatch warning in mfd/twl-core.c
On Wed, Dec 8, 2010 at 12:12 AM, Paul Walmsley wrote: > Hello Samuel, > > On Tue, 7 Dec 2010, Samuel Ortiz wrote: > >> On Mon, Dec 06, 2010 at 06:40:38PM -0700, Paul Walmsley wrote: >> > >> > That's fine with me. Samuel et al, Bryan's already done a patch >> > for this stuff: >> > >> > https://patchwork.kernel.org/patch/367011/ >> > >> > so we should use that instead, if you're happy with it. Samuel, maybe we >> > could get an ack from you on it? >> The twl driver is not OMAP specific, so this should be a separate patch thatI >> will merge to my mfd tree. >> If you really insist in pushing this through Tony's tree, then please add my >> Acked-by for the mfd part. > > I don't insist at all :-) > > Bryan, maybe split your patch into a mach-omap2 patch and a TWL > driver-specific patch, and send the latter for Samuel? > > No problem. I'll do soon. Thanks, -- Bryan Wu Kernel Developer +86.138-1617-6545 Mobile Ubuntu Kernel Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.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
[PATCH] OMAP1: SRAM: fix size for OMAP1611 SoCs
Kernel was failing to boot on omap1611 based OSK boards due to
mis-configured SRAM size. Existing code was using a hard-coded value
for 250k, which was then rounded down by PAGE_SIZE. Increasing this to
256k allows kernel to boot on omap1611 SoCs.
Problem reported by and initial fix suggested by Tim Bird.
Thanks to Tony Lindgren for helping diagnose the problem to being
specific to OMAP1611 and not affecting OMAP1610/OMAP1623.
Reported-by: Tim Bird
Signed-off-by: Kevin Hilman
---
Applies to Tony's omap-fixes branch, and should probably be
targetted for .37-rc.
arch/arm/plat-omap/sram.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index e2c8eeb..74dac41 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
cpu_is_omap1710())
omap_sram_size = 0x4000;/* 16K */
else if (cpu_is_omap1611())
- omap_sram_size = 0x3e800; /* 250K */
+ omap_sram_size = SZ_256K;
else {
printk(KERN_ERR "Could not detect SRAM size\n");
omap_sram_size = 0x4000;
--
1.7.2.1
--
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: disable idle early in the suspend sequence
Hi Jean, Jean Pihet writes: > Some bad interaction between the idle and the suspend paths has been > noticed: the idle code is called during the suspend enter and exit > sequences. This could cause corruption or lock-up of resources. > > The solution is to move the call to disable_hlt at the very beginning > of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare), > and the call to enable_hlt at the very end of the suspend sequence > (in omap3_pm_end instead of omap3_pm_finish). > > Tested with RET and OFF on Beagle and OMAP3EVM. > > Signed-off-by: Jean Pihet > Cc: Kevin Hilman > --- > arch/arm/mach-omap2/pm34xx.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Can you update this to do similar for OMAP2 and OMAP4? Thanks, Kevin -- 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 12/11] omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xx
* Tony Lindgren [101207 15:13]: > > Note that this will cause omap-keypad.c driver to not work on 7xx. > However, the right fix there is to move over to gpio-keys instead as > suggested by Cory Maccarrone and > Janusz Krzysztofik . Updated that to say matrix-keypad instead of gpio-keys as pointed out by Janusz. 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 v8 00/11] OMAP: GPIO: Implement GPIO as platform device
* Varadarajan, Charulatha [101125 04:39]:
> Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO
> module uses hwmod FW.
I'll add the following patch underneath this series as otherwise some
gpio_request calls will fail after this series.
Regards,
Tony
From: Tony Lindgren
Date: Tue, 7 Dec 2010 16:26:55 -0800
Subject: [PATCH] omap: Fix gpio_request calls to happen as arch_initcall
Looks like some boards are calling gpio_request from init_irq.
This will make the request_irq fail, as GPIO will be initialized
as postcore_initcall.
Reported-by: Paul Walmsley
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 149fdd3..295ab67 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -120,6 +120,15 @@ static struct resource smc91x_resources[] = {
},
};
+static void __init fsample_init_smc91x(void)
+{
+ fpga_write(1, H2P2_DBG_FPGA_LAN_RESET);
+ mdelay(50);
+ fpga_write(fpga_read(H2P2_DBG_FPGA_LAN_RESET) & ~1,
+ H2P2_DBG_FPGA_LAN_RESET);
+ mdelay(50);
+}
+
static struct mtd_partition nor_partitions[] = {
/* bootloader (U-Boot, etc) in first sector */
{
@@ -285,6 +294,8 @@ static struct omap_board_config_kernel fsample_config[] = {
static void __init omap_fsample_init(void)
{
+ fsample_init_smc91x();
+
if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, "NAND ready") < 0)
BUG();
gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN);
@@ -312,21 +323,11 @@ static void __init omap_fsample_init(void)
omap_register_i2c_bus(1, 100, NULL, 0);
}
-static void __init fsample_init_smc91x(void)
-{
- fpga_write(1, H2P2_DBG_FPGA_LAN_RESET);
- mdelay(50);
- fpga_write(fpga_read(H2P2_DBG_FPGA_LAN_RESET) & ~1,
- H2P2_DBG_FPGA_LAN_RESET);
- mdelay(50);
-}
-
static void __init omap_fsample_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
omap_gpio_init();
- fsample_init_smc91x();
}
/* Only FPGA needs to be mapped here. All others are done with ioremap */
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 197adb4..dd35efd 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -375,7 +375,6 @@ static void __init h2_init_irq(void)
omap1_init_common_hw();
omap_init_irq();
omap_gpio_init();
- h2_init_smc91x();
}
static struct omap_usb_config h2_usb_config __initdata = {
@@ -403,6 +402,8 @@ static struct omap_board_config_kernel h2_config[]
__initdata = {
static void __init h2_init(void)
{
+ h2_init_smc91x();
+
/* Here we assume the NOR boot config: NOR on CS3 (possibly swapped
* to address 0 by a dip switch), NAND on CS2B. The NAND driver will
* notice whether a NAND chip is enabled at probe time.
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 9126e3e..7871919 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -264,6 +264,15 @@ static struct platform_device smc91x_device = {
.resource = smc91x_resources,
};
+static void __init h3_init_smc91x(void)
+{
+ omap_cfg_reg(W15_1710_GPIO40);
+ if (gpio_request(40, "SMC91x irq") < 0) {
+ printk("Error requesting gpio 40 for smc91x irq\n");
+ return;
+ }
+}
+
#define GPTIMER_BASE 0xFFFB1400
#define GPTIMER_REGS(x)(0xFFFB1400 + (x * 0x800))
#define GPTIMER_REGS_SIZE 0x46
@@ -376,6 +385,8 @@ static struct i2c_board_info __initdata h3_i2c_board_info[]
= {
static void __init h3_init(void)
{
+ h3_init_smc91x();
+
/* Here we assume the NOR boot config: NOR on CS3 (possibly swapped
* to address 0 by a dip switch), NAND on CS2B. The NAND driver will
* notice whether a NAND chip is enabled at probe time.
@@ -422,21 +433,11 @@ static void __init h3_init(void)
h3_mmc_init();
}
-static void __init h3_init_smc91x(void)
-{
- omap_cfg_reg(W15_1710_GPIO40);
- if (gpio_request(40, "SMC91x irq") < 0) {
- printk("Error requesting gpio 40 for smc91x irq\n");
- return;
- }
-}
-
static void __init h3_init_irq(void)
{
omap1_init_common_hw();
omap_init_irq();
omap_gpio_init();
- h3_init_smc91x();
}
static void __init h3_map_io(void)
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index dc2b86f..0feaa67 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -296,7 +296,6 @@ static void __init innovator_init_irq(void)
omap1510_fpga_init_irq();
}
#endif
- innovator_init_smc91x();
}
#ifdef CONFIG_ARCH_OMAP15XX
@@ -387,6 +386,8 @@ static struct omap_board_config_kern
Re: State of LDP3430 platform
On Tue, 7 Dec 2010, Russell King - ARM Linux wrote: > So LDP will remain unusable until after the 2.6.38 merge window? I don't think that Tony or I realized that LDP3430 was broken until your E-mail. Usually I use a BeagleBoard 35xx for OMAP3430 testing, and I think Tony uses an Overo. The BeagleBoard boots cleanly with v2.6.37-rc5. I do have a LDP3430 here though. It doesn't boot past: [0.00] Linux version 2.6.37-rc5 (p...@twilight) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #68 SMP Tue Dec 7 17:42:20 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP Zoom2 board [0.00] debug: ignoring loglevel setting. [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 Looking into it now. - 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/14] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part one
Paul Walmsley writes: > This patch series, intended for 2.6.38: [...] > Kevin, I'd appreciate review and acks, if appropriate, on the patches > that touch code that you maintain. Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman I did some PM testing of this series on 34xx/n900 and 35xx/beagle using retention idle & sususpend and off-idle and suspend. For testing with other PM features that are targetted for 2.6.38, I've included it as part of my pm-core branch (which also includes your previous hwmod series and the watchdog series, among other things.) Kevin -- 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: UbiFS + HWECC(?) + BeagleBoard = fail
On Tuesday 07 December 2010 23:29:59 Luca Ceresoli wrote: > Luca Ceresoli wrote: > > While I thank you for you proposed solution, I see it does not work here. > > In fact I commented the #define CONFIG_MTD_NAND_OMAP_HWECC and left > > MTD_NAND_OMAP_PREFETCH disabled as it previously was, and got compilation > > errors: > > Wrong, sorry. Your solution compiles and works. I had another change in > that file that broke compilation. Luca, I have been having similar problems on a hacked Overo kernel. I have no problems with 2.6.35. I tried just commenting out the define and disabling PREFETCH and did not get a good boot due to ubi not finding the volume info. Are you loading up a UBI image with uboot? Are you using the ubi volume as rootfs? > > Nevertheless, it's not clear to me whether the long-term direction is to > switch to HWECC, and if it is expected to work in current builds, or if > SWECC in here to stay. > Clearly HWECC has some advantages, but UBI and HWECC need some effort to get working together. -- Charles -- 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] add BUG_ON_MAPPABLE_NULL macro
On Sun, 5 Dec 2010 12:06:03 +0200
Ohad Ben-Cohen wrote:
> Introduce BUG_ON_MAPPABLE_NULL in order to eliminate redundant BUG_ON
> code, checking for NULL addresses, on architectures where the zero
> address can never be mapped.
>
> Originally proposed by Russell King
>
> Signed-off-by: Ohad Ben-Cohen
> ---
> Compile tested on ARM and x86-64.
>
> Relevant threads:
> 1. Original proposal by Russell - http://lkml.org/lkml/2010/1/21/238
> 2. Recent discussion - https://lkml.org/lkml/2010/11/26/78
>
> Notes:
> * Implementation still feels hacky, especially since we don't care about the
> len param of arch_mmap_check.
> * Just like BUG_ON, this new macro is compiled out on !CONFIG_BUG. We might
> want to add a CONFIG_BUG commentary, so users will at least be aware of the
> security implications of compiling this out.
> * To get an (extremely!) rough upper bound of the profit of this macro, I did:
>
> 1. find . -name '*.[ch]' | xargs sed -i 's/BUG_ON(!/BUG_ON_MAPPABLE_NULL(!/'
> 2. removed some obviously bogus sed hits
>
> With omap2plus_defconfig, uImage shrank by ~4Kb (obviously this doesn't
> include the potential gain in modules)
>
Every time someone sends me a patch with text after the "---", I decide
it was good changelog material and I promote it to above the "---".
How's about you save us the effort :)
The changelog is a bit vague really, but the code comment explains it
all, and that's a good place to explain things.
> +/**
> + * BUG_ON_MAPPABLE_NULL() - BUG_ON(condition) only if address 0 is mappable
> + * @condition: condition to check, should contain a NULL check
> + *
> + * In general, NULL dereference Oopses are not desirable, since they take
> down
> + * the system with them and make the user extremely unhappy. So as a general
> + * rule drivers should avoid dereferencing NULL pointers by doing a simple
s/drivers/code/
> + * check (when appropriate), and just return an error rather than crash.
> + * This way the system, despite having reduced functionality, will just keep
> + * running rather than immediately reboot.
> + *
> + * _Critical_ kernel code, OTOH, that should not (/cannot) keep running when
> + * given an unexpected NULL pointer, should just crash. On some
> architectures,
> + * a NULL dereference will always reliably produce an Oops. On others, where
> + * the zero address can be mmapped, an Oops is not guaranteed. Relying on
> + * NULL dereference Oopses to happen on these architectures might lead to
> + * data corruptions (system will keep running despite a critical bug and
> + * the results will be horribly undefined). In addition, these situations
> + * can also have security implications - we have seen several privilege
> + * escalation exploits with which an attacker gained full control over the
> + * system due to NULL dereference bugs.
yup.
> + * This macro will BUG_ON if @condition is true on architectures where the
> zero
> + * address can be mapped. On other architectures, where the zero address
> + * can never be mapped, this macro is compiled out. It only makes sense to
> + * use this macro if @condition contains a NULL check, in order to optimize
> that
> + * check out on architectures where the zero address can never be mapped.
> + * On such architectures, those checks are not necessary, since the code
> + * itself will reliably reproduce an Oops as soon as the NULL address will
> + * be dereferenced.
> + *
> + * As with BUG_ON, use this macro only if @condition cannot be tolerated.
> + * If proceeding with degraded functionality is an option, it's much
> + * better to just simply check for @condition and return some error code
> rather
> + * than crash the system.
> + */
> +#define BUG_ON_MAPPABLE_NULL(cond) do { \
> + if (arch_mmap_check(0, 1, MAP_FIXED) == 0) \
> + BUG_ON(cond); \
> +} while (0)
- arch_mmap_check() didn't have any documentation. Please fix?
- arch_mmap_check() is a pretty poor identifier (identifiers which
include the word "check" are usually poor ones). Maybe
arch_address_accessible()?
- I worry about arch_mmap_check(). Is it expected that it will
perform a runtime check, like probe_kernel_address()? Spell out the
expectations, please.
- BUG_ON_MAPPABLE_NULL() will evaluate arch_mmap_check() even if
CONFIG_BUG=n. Seems bad, depending on what those unspelled-out
expectations are!
- BUG_ON_MAPPABLE_NULL() is a mouthful. I can't immedaitely think of
anythinjg nicer :(
- Is BUG_ON_MAPPABLE_NULL() really the interface you want? Or do we
just want an interface which checks a pointer for nearly-nullness?
--
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] OMAP2+: PM/serial: fix console semaphore acquire during suspend
commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
hold console semaphore while OMAP UARTs are disabled) added use of the
console semaphore to protect UARTs from being accessed after disabled
during idle, but this causes problems in suspend.
During suspend, the console semaphore is already held by the time we reach
the OMAP suspend path, so the try_acquire_console_sem() will always fail and
suspend will be aborted.
To fix, introduce a check so the console semaphore is only attempted
during idle, and not during suspend. Also use the same check so that
the console semaphore is not prematurely released during resume.
Thanks to Paul Walmsley for suggesting adding the same check during
resume.
Cc: Paul Walmsley
Tested-by: Jean Pihet
Tested-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
Applies to Tony's omap-fixes branch.
arch/arm/mach-omap2/pm34xx.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..648b8c5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,19 @@
#include "sdrc.h"
#include "control.h"
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
@@ -387,10 +400,11 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)
- if (try_acquire_console_sem())
- goto console_still_active;
+ if (!is_suspending())
+ if (per_next_state < PWRDM_POWER_ON ||
+ core_next_state < PWRDM_POWER_ON)
+ if (try_acquire_console_sem())
+ goto console_still_active;
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
@@ -470,7 +484,8 @@ void omap_sram_idle(void)
omap_uart_resume_idle(3);
}
- release_console_sem();
+ if (!is_suspending())
+ release_console_sem();
console_still_active:
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -514,8 +529,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static suspend_state_t suspend_state;
-
static int omap3_pm_prepare(void)
{
disable_hlt();
--
1.7.2.1
--
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: OMAP HSMMC problems with off-mode
Hi, > Looks like 0xfa09c014 is the MMC SYSSTATUS register... maybe there's > something wrong with the clock control. Just sent a patch for this one, it's relatively minor. After applying it and the 'brutal context save/restore test' patch, HSMMC off-mode indeed seems to work much better. Are there are any remaining fixes that anyone is aware of that need to go in for this driver to work reliably in off-mode? Or is it considered to be in good shape for off-mode in mainline once the OMAP PM no-op context loss tracking code is fixed? regards - 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] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
In the OMAP HSMMC driver, the code path entered via mmc_host_enable() can
include register accesses to the HSMMC IP block. For this to work, both
the device interface clock and functional clock need to be enabled before
mmc_host_enable() is called. However, omap_hsmmc_probe() calls
mmc_host_enable() before enabling the device interface clock. This can
crash the kernel with:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09c014
Fix by calling mmc_host_enable() after the device interface clock is
enabled.
Signed-off-by: Paul Walmsley
Cc: Madhusudhan Chikkature Rajashekar
Cc: Adrian Hunter
Cc: Kishore Kadiyala
Cc: Tero Kristo
---
drivers/mmc/host/omap_hsmmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5d46021..58a2c5e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2101,14 +2101,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
/* we start off in DISABLED state */
host->dpm_state = DISABLED;
- if (mmc_host_enable(host->mmc) != 0) {
+ if (clk_enable(host->iclk) != 0) {
clk_put(host->iclk);
clk_put(host->fclk);
goto err1;
}
- if (clk_enable(host->iclk) != 0) {
- mmc_host_disable(host->mmc);
+ if (mmc_host_enable(host->mmc) != 0) {
+ clk_disable(host->iclk);
clk_put(host->iclk);
clk_put(host->fclk);
goto err1;
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/11] omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xx
* Tony Lindgren [101204 13:16]:
> * Varadarajan, Charulatha [101202 06:08]:
> > On Thu, Dec 2, 2010 at 15:28, Kevin Hilman
> > wrote:
> >
> > >
> > > Tony, you can also add
> > >
> > > Acked-by: Kevin Hilman
>
> OK, updated. Also made one more GPIO patch to allow us to deal
> with the 7xx vs 15xx/16xx MPUIO registers.
Turns out that broke drivers/mtd/nand/ams-delta.c as it directly uses
multiple lines in parallel. So let's use 15xx/16xx offsets instead
and divide them by two.
Regards,
Tony
From: Tony Lindgren
Date: Sat, 4 Dec 2010 12:39:43 -0800
Subject: [PATCH] omap1: Fix gpio mpuio bank to work for multi-omap for
7xx/15xx/16xx
We need to divide the 15xx/16xx offset by 2 for 7xx. Use bank->stride
for that. This allows us to get rid of the duplicate defines for the
MPUIO registers.
Note that this will cause omap-keypad.c driver to not work on 7xx.
However, the right fix there is to move over to gpio-keys instead as
suggested by Cory Maccarrone and
Janusz Krzysztofik .
Cc: Cory Maccarrone
Cc: Janusz Krzysztofik
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index dbd8168..04c4b04 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -38,6 +38,7 @@ static struct __initdata omap_gpio_platform_data
omap15xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
.bank_type = METHOD_MPUIO,
.bank_width = 16,
+ .bank_stride= 1,
};
static struct __initdata platform_device omap15xx_mpu_gpio = {
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 8d4d0a0..5dd0d4c 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -41,6 +41,7 @@ static struct __initdata omap_gpio_platform_data
omap16xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
.bank_type = METHOD_MPUIO,
.bank_width = 16,
+ .bank_stride= 1,
};
static struct __initdata platform_device omap16xx_mpu_gpio = {
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 94bccd4..1204c8b 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -43,6 +43,7 @@ static struct __initdata omap_gpio_platform_data
omap7xx_mpu_gpio_config = {
.virtual_irq_start = IH_MPUIO_BASE,
.bank_type = METHOD_MPUIO,
.bank_width = 32,
+ .bank_stride= 2,
};
static struct __initdata platform_device omap7xx_mpu_gpio = {
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 59afe77..de93251 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -159,6 +159,7 @@ struct gpio_bank {
u32 dbck_enable_mask;
struct device *dev;
bool dbck_flag;
+ int stride;
};
#ifdef CONFIG_ARCH_OMAP3
@@ -267,7 +268,7 @@ static void _set_gpio_direction(struct gpio_bank *bank, int
gpio, int is_input)
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
- reg += OMAP_MPUIO_IO_CNTL;
+ reg += OMAP_MPUIO_IO_CNTL / bank->stride;
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -315,7 +316,7 @@ static void _set_gpio_dataout(struct gpio_bank *bank, int
gpio, int enable)
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
- reg += OMAP_MPUIO_OUTPUT;
+ reg += OMAP_MPUIO_OUTPUT / bank->stride;
l = __raw_readl(reg);
if (enable)
l |= 1 << gpio;
@@ -387,7 +388,7 @@ static int _get_gpio_datain(struct gpio_bank *bank, int
gpio)
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
- reg += OMAP_MPUIO_INPUT_LATCH;
+ reg += OMAP_MPUIO_INPUT_LATCH / bank->stride;
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -433,7 +434,7 @@ static int _get_gpio_dataout(struct gpio_bank *bank, int
gpio)
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
- reg += OMAP_MPUIO_OUTPUT;
+ reg += OMAP_MPUIO_OUTPUT / bank->stride;
break;
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -620,7 +621,7 @@ static void _toggle_gpio_edge_triggering(struct gpio_bank
*bank, int gpio)
switch (bank->method) {
case METHOD_MPUIO:
- reg += OMAP_MPUIO_GPIO_INT_EDGE;
+ reg += OMAP_MPUIO_GPIO_INT_EDGE / bank->stride;
break;
#ifdef CONFIG_ARCH_OMAP15XX
case METHOD_GPIO_1510:
@@ -654,7 +655,7 @@ static int _set_gpio_triggering(struct gpio_bank *bank, int
gpio, int trigger)
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP1
case METHOD_MPUIO:
- reg += OMAP_MPUIO_GPIO_INT_EDGE;
+ reg += OMAP_MPUIO_GPIO_INT_EDGE
Re: OMAP HSMMC problems with off-mode
Hi, On Tue, 7 Dec 2010, Chikkature Rajashekar, Madhusudhan wrote: > On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter wrote: > > > > It is at least because omap_pm_get_dev_context_loss_count() is not > > implemented. Tero Kristo was looking at that recently. > > > > Yes. I agree that is the problem. In the .32 kernel I had hooked it to > "get_last_off_on_transaction_id" which helped. > But that functionality does not exist anymore. So something equivalent > to tell the driver when the OFF was hit will make it work. OK, let's see if we can get that fixed in at least some trivial way for 2.6.38. While working on this, I applied this trivial patch: diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c index e129ce8..781aa5f 100644 --- a/arch/arm/plat-omap/omap-pm-noop.c +++ b/arch/arm/plat-omap/omap-pm-noop.c @@ -30,6 +30,8 @@ struct omap_opp *dsp_opps; struct omap_opp *mpu_opps; struct omap_opp *l3_opps; +static int dummy_context_loss_counter; + /* * Device-driver-originated constraints (via board-*.c files) */ @@ -303,7 +305,7 @@ int omap_pm_get_dev_context_loss_count(struct device *dev) * off counter. */ - return 0; + return dummy_context_loss_counter++; } ... which causes drivers to believe that device context has been lost after each call to omap_pm_get_dev_context_loss_count(). Brutal, but effective for chasing out context save/restore bugs. This patch causes an abort in the MMC driver with the current linux-omap master: [1.960693] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09c014 [1.968872] Internal error: : 1028 [#1] SMP [1.973266] last sysfs file: [1.976379] Modules linked in: [1.979583] CPU: 0Not tainted (2.6.37-rc4-09012-gfea0fb8 #65) [1.986083] PC is at omap_hsmmc_context_restore+0x58/0x2ec [1.991851] LR is at omap_hsmmc_context_restore+0x4c/0x2ec [1.997619] pc : []lr : []psr: 2013 [1.997619] sp : cf82deb0 ip : cf82c000 fp : cf890408 [2.009643] r10: cf826160 r9 : 0053 r8 : 0001 [2.015136] r7 : cfad2000 r6 : cfad23c0 r5 : r4 : 6b1f [2.021972] r3 : 000e r2 : fa09c000 r1 : fa09c014 r0 : 6b22 [2.028808] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [2.036499] Control: 10c5387d Table: 80004019 DAC: 0017 [2.042510] Process swapper (pid: 1, stack limit = 0xcf82c2f8) [2.048645] Stack: (0xcf82deb0 to 0xcf82e000) [2.053192] dea0: cfad23c0 cfad2000 cfad23c0 [2.061798] dec0: c0345844 cfad2000 cfad2000 c0338040 0001 [2.070373] dee0: cfad2000 c002c728 0003 cf886c08 cfad0a60 c05fdbc0 cf890408 [2.078948] df00: cf890408 c05fdbc0 cfaef1a0 c05f06b8 c02a0368 [2.087524] df20: cf890408 c029f388 cf890408 cf89043c c05fdbc0 c029f4b0 c029f448 [2.096130] df40: c05fdbc0 c029eb3c cf826eb8 cf8b5890 cf8001e0 0080 c05fdbc0 c029e468 [2.104705] df60: c04f3804 0468 c05fdbac c061bd54 c05fdbc0 c061bd4c c002c400 [2.113281] df80: c029f7a8 c05fdbac c061bd54 c05aa190 c061bd4c c002c400 c02a0770 [2.121856] dfa0: c00335dc c061bd54 c05aa190 c0050574 c0503d6c 0192 [2.130462] dfc0: c061bd54 c00335dc c061bd54 c05aa190 c061bd4c c00084ec [2.139038] dfe0: c00083a0 c005bcf0 0013 c005bcf0 1177ed0a 0073ef00 [2.147644] [] (omap_hsmmc_context_restore+0x58/0x2ec) from [] (omap_hsmmc_enable_fclk+0x20/0x28) [2.158782] [] (omap_hsmmc_enable_fclk+0x20/0x28) from [] (mmc_host_enable+0x6c/0x90) [2.168823] [] (mmc_host_enable+0x6c/0x90) from [] (omap_hsmmc_probe+0x314/0x96c) [2.178497] [] (omap_hsmmc_probe+0x314/0x96c) from [] (platform_drv_probe+0x18/0x1c) [2.188476] [] (platform_drv_probe+0x18/0x1c) from [] (driver_probe_device+0xc8/0x188) [2.198608] [] (driver_probe_device+0xc8/0x188) from [] (__driver_attach+0x68/0x8c) [2.208465] [] (__driver_attach+0x68/0x8c) from [] (bus_for_each_dev+0x44/0x74) [2.217956] [] (bus_for_each_dev+0x44/0x74) from [] (bus_add_driver+0x104/0x294) [2.227569] [] (bus_add_driver+0x104/0x294) from [] (driver_register+0xa8/0x130) [2.237152] [] (driver_register+0xa8/0x130) from [] (platform_driver_probe+0x18/0x8c) [2.247192] [] (platform_driver_probe+0x18/0x8c) from [] (do_one_initcall+0xc8/0x1a0) [2.257263] [] (do_one_initcall+0xc8/0x1a0) from [] (kernel_init+0x14c/0x214) [2.266571] [] (kernel_init+0x14c/0x214) from [] (kernel_thread_exit+0x0/0x8) [2.275878] Code: ebf53fa3 e5962048 e2821014 e084 (e5913000) [2.282409] ---[ end trace a0fb0e5d1754cad1 ]--- [2.287353] Kernel panic - not syncing: Attempted to kill init! Looks like 0xfa09c014 is the MMC SYSSTATUS register... maybe there's something wrong with the clock control. - Paul
Re: [PATCH] OMAP2+: PM/serial: fix console semaphore acquire during suspend
Hi,
Two comments:
On Tue, 7 Dec 2010, Kevin Hilman wrote:
> commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
> hold console semaphore while OMAP UARTs are disabled) added use of the
> console semaphore to protect UARTs from being accessed after disabled
> during idle, but this causes problems in suspend.
>
> During suspend, the console semaphore is already held by the time we reach
> the OMAP suspend path, so the try_acquire_console_sem() will always fail and
> suspend will be aborted.
>
> To fix, introduce a check so the console semaphore is only attempted
> during idle, and not during suspend.
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> Applies to Tony's omap-fixes branch.
>
> arch/arm/mach-omap2/pm34xx.c | 24 ++--
> 1 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0ec8a04..122ef3c 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -50,6 +50,19 @@
> #include "sdrc.h"
> #include "control.h"
>
> +#ifdef CONFIG_SUSPEND
> +static suspend_state_t suspend_state = PM_SUSPEND_ON;
> +static inline bool is_suspending(void)
> +{
> + return (suspend_state != PM_SUSPEND_ON);
> +}
> +#else
> +static inline bool is_suspending(void)
> +{
> + return false;
> +}
> +#endif
> +
> /* Scratchpad offsets */
> #define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
> #define OMAP343X_TABLE_VALUE_OFFSET 0xc0
> @@ -387,10 +400,11 @@ void omap_sram_idle(void)
> }
>
> /* Block console output in case it is on one of the OMAP UARTs */
> - if (per_next_state < PWRDM_POWER_ON ||
> - core_next_state < PWRDM_POWER_ON)
> - if (try_acquire_console_sem())
> - goto console_still_active;
> + if (!is_suspending())
> + if (per_next_state < PWRDM_POWER_ON ||
> + core_next_state < PWRDM_POWER_ON)
> + if (try_acquire_console_sem())
> + goto console_still_active;
This same is_suspending() test needs to be applied to the
release_console_sem() later in the pm34xx.c, otherwise the console
semaphore will be released before the Linux suspend code expects it to be.
Also, I'd assume that a similar patch to the above needs to be applied to
pm24xx.c.
- 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] omap1: pm_bus: Fix compilation warning.
Marek Belisko writes:
> Fix following compilation warning:
> arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_resume':
> arch/arm/mach-omap1/pm_bus.c:51: warning: unused variable 'ret'
>
> Signed-off-by: Marek Belisko
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap1/pm_bus.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
> index 8b66392..f97c6e9 100644
> --- a/arch/arm/mach-omap1/pm_bus.c
> +++ b/arch/arm/mach-omap1/pm_bus.c
> @@ -48,7 +48,6 @@ static int omap1_pm_runtime_suspend(struct device *dev)
>
> static int omap1_pm_runtime_resume(struct device *dev)
> {
> - int ret = 0;
> struct clk *iclk, *fclk;
>
> dev_dbg(dev, "%s\n", __func__);
--
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/3] OMAP: I2C and UART device name cleanup
Benoit Cousson writes: > Hi All, > > In order to enforce a little bit of consistency in the omap devices name, > the convention for omap devices name will be now omap_XXX. All the drivers > adapted to hwmod will be named like that during the on-going adaptations. > > The I2C and UART drivers are already adapted to hwmod but with > the original names. > > Rename i2c and uart using this convention: > i2c_omap -> omap_i2c > omap-hsuart -> omap_uart > > Tested on OMAP4 ES2 on Panda / sdp4430. Some more validation will be needed > on OMAP2 & 3. > > This series is based on Kevin's pm-hwmod-i2c branch and is available here: > git://gitorious.org/omap-pm/linux.git for_2.6.38/device_name > > > Regards, > Benoit > > > Benoit Cousson (3): > OMAP: clock: Change device name in clock nodes: i2c_omap -> omap_i2c > OMAP: i2c: Change device name: i2c_omap -> omap_i2c These two should probably be combined, as they cannot work separately. > OMAP: serial: Change device name: omap-hsuart -> omap_uart > Also, can you Cc linux-arm-kernel when you post updated version? Thanks, Kevin -- 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 v8 10/11] OMAP: GPIO: Implement GPIO as a platform device
* Varadarajan, Charulatha [101206 22:58]:
> On Tue, Dec 7, 2010 at 11:05, Varadarajan, Charulatha wrote:
> >
> > On Tue, Dec 7, 2010 at 10:49, Cory Maccarrone
> > wrote:
> >>
> >> omap_gpio omap_gpio.5: Could not get gpio dbck
> >> omap_gpio omap_gpio.6: Could not get gpio dbck
> >>
> >> I think that 'if' should be:
> >>
> >> if (bank->dbck_flag && !bank->dbck) {
> >
> > You are right. Will send a patch now.
Looks like if that's a warning no need to merge it into the
earlier patches.
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/8] OMAP2+: hwmod core upgrades for 2.6.38: first set
Paul Walmsley writes: > On Mon, 22 Nov 2010, Kevin Hilman wrote: > >> Paul Walmsley writes: >> >> > On Tue, 16 Nov 2010, Paul Walmsley wrote: >> > >> >> This patch series contains upgrades for the OMAP2+ hwmod core >> >> code, intended for 2.6.38. Most of these patches were developed >> >> in response to use-cases discovered while converting device >> >> drivers to use the hwmod code. >> >> >> >> Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. >> > >> > Just FYI, this branch 'hwmod_a_2.6.38' is available at >> > git://git.pwsan.com/linux-2.6 >> > >> > Warning: it's based on Tony's tree, not the mainline, due to the recent >> > board file changes. >> >> Looks like Tony has collected the board file changes into his >> devel-board branch. Can this rebased there? >> >> That way, I can included it as part of the PM branch testing without >> having to pull in master. > > hwmod_a_2.6.38 is now based on devel-board and wdt_2.6.38 is now rebased > on the updated hwmod_a_2.6.38. Tested-by: Kevin Hilman Tested on 35xx/omap3evm, 34xx/n900 and 35xx/beagle. Kevin -- 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: Unbalanced IRQ wake disable during resume from static suspend
Paul Walmsley writes:
> Hi Kevin
>
> On Thu, 2 Dec 2010, Kevin Hilman wrote:
>
>> I guess this hasn't been seen before since we haven't tested the sysfs
>> wakeup interface for the omap-serial driver. For on-chip OMAP UARTs,
>> using the sysfs interface isn't needed as the serial core is already
>> doing device_init_wakeup(dev, true);
>
> Is this the code you're referring to, in serial_core.c?
>
> tty_dev = tty_register_device(drv->tty_driver, uport->line, uport->dev);
> if (likely(!IS_ERR(tty_dev))) {
> device_init_wakeup(tty_dev, 1);
> device_set_wakeup_enable(tty_dev, 0);
> } else
>
> I may be misreading it, but it appears that the code leaves wakeups
> disabled for the serial port, by default.
No, I was referring to the code in mach-omap2/serial.c, in
omap_serial_init_port():
if ((cpu_is_omap34xx() && uart->padconf) ||
(uart->wk_en && uart->wk_mask)) {
device_init_wakeup(&od->pdev.dev, true);
DEV_CREATE_FILE(&od->pdev.dev, &dev_attr_sleep_timeout);
}
Kevin
> As an aside, this code is somewhat perplexing: it doesn't seem accurate to
> assume that every serial device really is capable of waking up the system.
--
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] OMAP2+: PM/serial: fix console semaphore acquire during suspend
On Tue, 7 Dec 2010, Kevin Hilman wrote: > commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial: > hold console semaphore while OMAP UARTs are disabled) added use of the > console semaphore to protect UARTs from being accessed after disabled > during idle, but this causes problems in suspend. > > During suspend, the console semaphore is already held by the time we reach > the OMAP suspend path, so the try_acquire_console_sem() will always fail and > suspend will be aborted. > > To fix, introduce a check so the console semaphore is only attempted > during idle, and not during suspend. > > Cc: Paul Walmsley > Signed-off-by: Kevin Hilman Tested-by: Paul Walmsley - 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] OMAP2+: PM/serial: fix console semaphore acquire during suspend
On Tue, Dec 7, 2010 at 9:50 PM, Kevin Hilman
wrote:
> commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
> hold console semaphore while OMAP UARTs are disabled) added use of the
> console semaphore to protect UARTs from being accessed after disabled
> during idle, but this causes problems in suspend.
>
> During suspend, the console semaphore is already held by the time we reach
> the OMAP suspend path, so the try_acquire_console_sem() will always fail and
> suspend will be aborted.
>
> To fix, introduce a check so the console semaphore is only attempted
> during idle, and not during suspend.
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
Tested OK on Beagleboard with suspend and idle with RET and OFF modes
Tested-by: Jean Pihet
Thanks,
Jean
> ---
> Applies to Tony's omap-fixes branch.
>
> arch/arm/mach-omap2/pm34xx.c | 24 ++--
> 1 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0ec8a04..122ef3c 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -50,6 +50,19 @@
> #include "sdrc.h"
> #include "control.h"
>
> +#ifdef CONFIG_SUSPEND
> +static suspend_state_t suspend_state = PM_SUSPEND_ON;
> +static inline bool is_suspending(void)
> +{
> + return (suspend_state != PM_SUSPEND_ON);
> +}
> +#else
> +static inline bool is_suspending(void)
> +{
> + return false;
> +}
> +#endif
> +
> /* Scratchpad offsets */
> #define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
> #define OMAP343X_TABLE_VALUE_OFFSET 0xc0
> @@ -387,10 +400,11 @@ void omap_sram_idle(void)
> }
>
> /* Block console output in case it is on one of the OMAP UARTs */
> - if (per_next_state < PWRDM_POWER_ON ||
> - core_next_state < PWRDM_POWER_ON)
> - if (try_acquire_console_sem())
> - goto console_still_active;
> + if (!is_suspending())
> + if (per_next_state < PWRDM_POWER_ON ||
> + core_next_state < PWRDM_POWER_ON)
> + if (try_acquire_console_sem())
> + goto console_still_active;
>
> /* PER */
> if (per_next_state < PWRDM_POWER_ON) {
> @@ -514,8 +528,6 @@ out:
> }
>
> #ifdef CONFIG_SUSPEND
> -static suspend_state_t suspend_state;
> -
> static int omap3_pm_prepare(void)
> {
> disable_hlt();
> --
> 1.7.2.1
>
> --
> 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] arm: plat-omap: counter_32k: Fix build error due to IS_ERR
Sourav Poddar writes: > Fix the following build error by including linux/err.h > arch/arm/plat-omap/counter_32k.c: In function 'omap_init_clocksource_32k': > arch/arm/plat-omap/counter_32k.c:167: error: implicit declaration of > function 'IS_ERR' > > The above error is due to the following commit: > subject: arm: plat-omap: counter_32k: use IS_ERR() instead of NULL check > commit: 235fbace0334c846c21e902f330020122fc85955 > > Created on linux-omap-2.6 branch: omap-fixes > > Signed-off-by: Sourav Poddar > Reviewed-by: Charulatha V > Acked-by: Felipe Balbi Acked-by: Kevin Hilman Just noticed this one too. Kevin -- 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
How to change freq of mmc2_clk to 48Mhz for OMAP35xx
Hi, What should I do to change the output frequency of mmc2_clk signal to 48Mhz for the OMAP35xx processor? Right now it is giving an output of 96MHz and the signal output looks more like a sine wave than a square wave clock output signal. Elvis Dowson -- 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: OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled
Tony Lindgren writes: > * Kevin Hilman [101124 16:32]: >> Paul Walmsley writes: > > > >> Acked-by: Kevin Hilman >> >> Very nice. I've been exploring various solutions to this problem as >> well, but this one is much cleaner. Also, I hadn't discovered the 'try' >> version of the console semaphore, so was running into recursive locking. >> >> Anyways, tested on omap35xx: omap3evm (uart1/core console) and beagle >> (uart3/per console) and omap34xx/n900 (uart3/per console) using both >> retention-idle and off-idle. > > Thanks, queuing this as fix for the -rc cycle. FYI.. just found a regression caused by this patch. It prevented suspend from ever happening since the console semaphore is already held during suspend. Just posted a fix for this: Date: Tue, 7 Dec 2010 12:24:13 -0800 Subject: [PATCH] OMAP2+: PM/serial: fix console semaphore acquire during suspend Kevin -- 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: OMAP HSMMC problems with off-mode
On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter wrote: > On 07/12/10 20:21, ext Paul Walmsley wrote: >> >> Madhusudhan, >> >> On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning >> from dynamic off-mode. The MMC LED turns on and stays on, and the process >> hangs, although the rest of the system still seems to run. Looks like >> you're listed as the maintainer for this code. Do you know why this is, >> and what can be done to fix it? > > It is at least because omap_pm_get_dev_context_loss_count() is not > implemented. Tero Kristo was looking at that recently. > Yes. I agree that is the problem. In the .32 kernel I had hooked it to "get_last_off_on_transaction_id" which helped. But that functionality does not exist anymore. So something equivalent to tell the driver when the OFF was hit will make it work. Regards, Madhu >> >> This is using linux-omap master at commit >> a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with >> DSS configured in. My boot and root partitions are on MMC. Following are >> the commands I used to reproduce this problem. >> >> >> regards >> >> - Paul >> >> echo 1> /debug/pm_debug/sleep_while_idle >> echo 1> /debug/pm_debug/enable_off_mode >> echo 5> /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout >> echo 5> /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout >> echo 5> /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout >> >> > > -- 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] OMAP2+: PM/serial: fix console semaphore acquire during suspend
commit 0d8e2d0dad98a693bad88aea6876ac8b94ad95c6 (OMAP2+: PM/serial:
hold console semaphore while OMAP UARTs are disabled) added use of the
console semaphore to protect UARTs from being accessed after disabled
during idle, but this causes problems in suspend.
During suspend, the console semaphore is already held by the time we reach
the OMAP suspend path, so the try_acquire_console_sem() will always fail and
suspend will be aborted.
To fix, introduce a check so the console semaphore is only attempted
during idle, and not during suspend.
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
Applies to Tony's omap-fixes branch.
arch/arm/mach-omap2/pm34xx.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..122ef3c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -50,6 +50,19 @@
#include "sdrc.h"
#include "control.h"
+#ifdef CONFIG_SUSPEND
+static suspend_state_t suspend_state = PM_SUSPEND_ON;
+static inline bool is_suspending(void)
+{
+ return (suspend_state != PM_SUSPEND_ON);
+}
+#else
+static inline bool is_suspending(void)
+{
+ return false;
+}
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0xc4
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
@@ -387,10 +400,11 @@ void omap_sram_idle(void)
}
/* Block console output in case it is on one of the OMAP UARTs */
- if (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)
- if (try_acquire_console_sem())
- goto console_still_active;
+ if (!is_suspending())
+ if (per_next_state < PWRDM_POWER_ON ||
+ core_next_state < PWRDM_POWER_ON)
+ if (try_acquire_console_sem())
+ goto console_still_active;
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
@@ -514,8 +528,6 @@ out:
}
#ifdef CONFIG_SUSPEND
-static suspend_state_t suspend_state;
-
static int omap3_pm_prepare(void)
{
disable_hlt();
--
1.7.2.1
--
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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX", + * or "OMAP4430". Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. Regards, Benoit -- 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 v5 0/3] OMAP2/3: DMA: FIFO drain errata fixes
On Fri, Nov 05, 2010 at 02:29:02PM -0700, Tony Lindgren wrote: > Hi Greg, > > Considering below.. > > * Peter Ujfalusi [101021 02:56]: > > Sorry, I did missed this mail... > > > > On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote: > > > > > Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just > > > queueing these for 2.6.37 for the following reasons: > > > > > > - The 24xx patch is a fix for commit c12abc0 that's was merged over a > > > year ago. We've lived with it for over a year now. What difference does > > > extra few more months make if we have it in 2.6.37 instead of 2.6.36? > > > > > > - The second 34xx fix seems to happen only when disabling DMA on the fly. > > > Again, we've had support for 34xx in the mainline kernel for a few > > > years, and we're not seeing unrecoverable issues with MMC or USB or > > > any other code calling omap_dma_stop(). > > > > > > Sure these fix major issues with the DMA, but are these really critical > > > for 2.6.36? > > > > > > So if you really want me to argue for merging these into 2.6.36, please > > > let > > > me know some oops causing cases or data corruption that happens without > > > these patches. > > > > Well 2.6.36 is released. > > I still would like to see this to be part of the 2.6.36.1 release. We can > > reproduce the DMA error in 2.6.36 with audio. > > > > Tony: can you make sure it is going to part of 2.6.36.1? > > ..are you interested in these two patches for stable kernels? > > The two patches in question are the following mainline commits: > > 3e57f1626b5febe5cc99aa6870377deef3ae03cc > 0e4905c0199d683497833be60a428c784d7575b8 Now queued up, thanks. greg k-h -- 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: OMAP HSMMC problems with off-mode
On 07/12/10 20:21, ext Paul Walmsley wrote: Madhusudhan, On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning from dynamic off-mode. The MMC LED turns on and stays on, and the process hangs, although the rest of the system still seems to run. Looks like you're listed as the maintainer for this code. Do you know why this is, and what can be done to fix it? It is at least because omap_pm_get_dev_context_loss_count() is not implemented. Tero Kristo was looking at that recently. This is using linux-omap master at commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with DSS configured in. My boot and root partitions are on MMC. Following are the commands I used to reproduce this problem. regards - Paul echo 1> /debug/pm_debug/sleep_while_idle echo 1> /debug/pm_debug/enable_off_mode echo 5> /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout echo 5> /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout echo 5> /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout -- 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 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
On Tue, Dec 07, 2010 at 04:50:50PM +, Dave Martin wrote: > I'll follow up shortly with a patch to the generic ARM Kconfig to make > this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally > be configured together. That's a rubbish dependency. You may have an ARCH_OMAP2 platform which is Cortex A9, and you only have Cortex A9 support selected. In that case there's no reason to prevent THUMB2_KERNEL being selected. The right thing to do is to make THUMB2_KERNEL depend on those CPUs which are not to be selected - not by making it depend on some platform configuration option(s) which aren't actually relevent. -- 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/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
On Tue, 7 Dec 2010, Dave Martin wrote: > On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote: > [...] > > Note that converting to C doesn't mean that code which attempts to > > copy function bodies will work: you still need to handle the fact that > > if f() is a C function symbol, then the value of the symbol f is > > actually the function's base address + 1. See my changes in sram.c, > > To clarify, this applies *if* f is a Thumb symbol. To make it generic, a new macro could be used: #define SYM_ADDR(x) ((void *)((long)(x) & ~1L)) Nicolas
Re: [RFC/PATCH v6 03/12] media: Entities, pads and links
On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote: > Ah, now I understand what you mean. Would 'activated' be better than 'active'? Better, yes, though it still sounds a bit like something should be actively (IYSWIM) happening. In the absence of better ideas I could go with this. > Or perhaps just say: the link 'is on' or the link 'is switched on'? > So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). > Actually, I think 'switched on' is a pretty good description of what is going > on > in the hardware. I prefer activated, this makes me think of power. Bear in mind that for most audio the power is a big portion of the control - either the audio is analogue or it looks like it. -- 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: OMAP HSMMC problems with off-mode
Hello Madhusudhan, On Tue, 7 Dec 2010, Chikkature Rajashekar, Madhusudhan wrote: > Last I tested OFF mode was after Adrian's power saving series was merged. I > tested it on Kevin PM branch then and it was functional on my omap3 board. > > I need to check on the latest commit. > > Did you see this problem in suspend/resume path or the cpuidle path? I noticed it on the CPUIdle path. - 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: OMAP HSMMC problems with off-mode
Paul, Last I tested OFF mode was after Adrian's power saving series was merged. I tested it on Kevin PM branch then and it was functional on my omap3 board. I need to check on the latest commit. Did you see this problem in suspend/resume path or the cpuidle path? Regards, Madhu On Tue, Dec 7, 2010 at 12:21 PM, Paul Walmsley wrote: > > Madhusudhan, > > On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning > from dynamic off-mode. The MMC LED turns on and stays on, and the process > hangs, although the rest of the system still seems to run. Looks like > you're listed as the maintainer for this code. Do you know why this is, > and what can be done to fix it? > > This is using linux-omap master at commit > a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with > DSS configured in. My boot and root partitions are on MMC. Following are > the commands I used to reproduce this problem. > > > regards > > - Paul > > echo 1 > /debug/pm_debug/sleep_while_idle > echo 1 > /debug/pm_debug/enable_off_mode > echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout > -- 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
OMAP HSMMC problems with off-mode
Madhusudhan, On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning from dynamic off-mode. The MMC LED turns on and stays on, and the process hangs, although the rest of the system still seems to run. Looks like you're listed as the maintainer for this code. Do you know why this is, and what can be done to fix it? This is using linux-omap master at commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with DSS configured in. My boot and root partitions are on MMC. Following are the commands I used to reproduce this problem. regards - Paul echo 1 > /debug/pm_debug/sleep_while_idle echo 1 > /debug/pm_debug/enable_off_mode echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout -- 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 v6 03/12] media: Entities, pads and links
On Tuesday, December 07, 2010 18:55:05 Mark Brown wrote: > On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote: > > > Personally I think this is perfectly clear. The original confusion came from > > the word 'active', which I understand means 'streaming' in alsa. By adding > > a 'streaming' flag in addition to the active flag I think it will be clear > > that 'active' and 'streaming' are two different things. > > It's not that, it's the fact that active sounds to me like the link > ought to be powered up which isn't the case - it's too verby. Like I > say, I think I'd prefer a more passive name like "connected". Ah, now I understand what you mean. Would 'activated' be better than 'active'? Or perhaps just say: the link 'is on' or the link 'is switched on'? So: ...LINK_SWITCHED_ON (sorry, forgot what the prefix is). Actually, I think 'switched on' is a pretty good description of what is going on in the hardware. Regards, Hans > I guess if nobody else finds it confusing I can live with it. > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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 v6 03/12] media: Entities, pads and links
On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote: > Personally I think this is perfectly clear. The original confusion came from > the word 'active', which I understand means 'streaming' in alsa. By adding > a 'streaming' flag in addition to the active flag I think it will be clear > that 'active' and 'streaming' are two different things. It's not that, it's the fact that active sounds to me like the link ought to be powered up which isn't the case - it's too verby. Like I say, I think I'd prefer a more passive name like "connected". I guess if nobody else finds it confusing I can live with it. -- 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 v6 03/12] media: Entities, pads and links
On Friday, December 03, 2010 15:54:08 Mark Brown wrote: > On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote: > > On Friday 03 December 2010 13:06:18 Hans Verkuil wrote: > > > > > Just to confirm thinks, Mark's proposal is to replace 'connected' by > > > > 'linked' and 'active' by 'connected'. Are we on the same page here ? > > > > Yes, but when I read it back it does not make me happy. 'Connected' and > > > 'linked' basically have the same meaning in English. > > > I unfortunately agree that it's a bit confusing :-( > > It feels like the problem here is that for whatever reason (I'm not sure > what?) you're trying to come up with verbs for links that are currently > disconnected - in ASoC we just say we've got paths that exist and then > we talk about the paths that are connected. Verbing everything makes it > all sound active which is confusing when you're talking about links that > are idle. OK, let's try this again. The media controller has entities, entities have pads, and between pads there are links. Links can be active (data can flow) or inactive (no data can flow). Active links can be idle (no data is flowing) or streaming (data is flowing over the link). Personally I think this is perfectly clear. The original confusion came from the word 'active', which I understand means 'streaming' in alsa. By adding a 'streaming' flag in addition to the active flag I think it will be clear that 'active' and 'streaming' are two different things. Regarding 'active': an alternative could be 'connected'. I think it is not quite as good as 'active' since basically all links are always connected in the usual sense of the word. It is just that a mux decides which one is actually working. However, I won't object to using 'connected' instead of 'active' if others prefer that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
This makes sense, because Thumb-2 code can't execute on anything prior to ARMv7. This will avoid accidentally configuring a broken kernel where the config otherwise would allow multiple architecture versions to coexist in the same kernel. Not adding !CPU_V5 etc., because the chance of anyone trying to put v5 and v7 in the same kernel is low, and I'm not aware of any mach which can do this. These could be added later if it matters. Signed-off-by: Dave Martin --- KernelVersion: 2.6.37-rc4 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f1d9297..bf1f8db 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1311,7 +1311,7 @@ config HZ config THUMB2_KERNEL bool "Compile the kernel in Thumb-2 mode" - depends on CPU_V7 && EXPERIMENTAL + depends on CPU_V7 && !CPU_V6 && EXPERIMENTAL select AEABI select ARM_ASM_UNIFIED help -- 1.7.1 -- 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 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
Hi, On Tue, Dec 7, 2010 at 6:28 AM, Santosh Shilimkar wrote: > Dave, >> -Original Message- >> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- >> boun...@lists.linaro.org] On Behalf Of Dave Martin >> Sent: Monday, December 06, 2010 11:06 PM >> To: linux-arm-ker...@lists.infradead.org >> Cc: Tony Lindgren; Dave Martin; linux-omap@vger.kernel.org; linaro- >> d...@lists.linaro.org >> Subject: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() >> forCONFIG_THUMB2_KERNEL >> >> For the Thumb-2 case, the "wfi" mnemonic is used, since in this >> case the tools will necessarily be new enough to support it. >> >> Signed-off-by: Dave Martin >> --- >> KernelVersion: 2.6.37-rc4 > > The choice of opcode instead of instruction here was not because > of toolchain. The problem was it breaks multi-omap build where > ARMv6 and ARMv7 are build together. > > For this reason I NAK this patch. You can't built a kernel for pre-v7 platforms with CONFIG_THUMB2_KERNEL: the code can't run on those platforms because they don't support Thumb-2. So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 capable (and hence reasonably new) tools. I'll follow up shortly with a patch to the generic ARM Kconfig to make this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally be configured together. Cheers ---Dave -- 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/2] AM35x: musb: fix compilation error
On Tue, Dec 07, 2010 at 07:25:12PM +0530, Gupta, Ajay Kumar wrote: Hi, >> Is AM35x that different ? Can't you just write to MUSB_INTRRX >> MUSB_INTRTX and MUSB_INTRUSB ?? >Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt >Bit in control register INTR_LVL_CLR. I see, thanks for the info :-) Felipe, I have recreated this patch (attached) on top of your patch set and AM35x is working. applied it. Thanks -- 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] Correct definition of register of OMAP4_RM_RSTST and OMAP4_RM_RSTTIME
Hi Paul, On 12/7/2010 5:04 PM, Paul Walmsley wrote: Hello, On Tue, 7 Dec 2010, MING ZHOU wrote: Since we need to reconfigure Reset time for OMAP4, we found the OMAP4 register definition for reset time is wrong according to spec of OMAP4. And we verified this by reading default value of register. We found the offset definition of Reset time and Reset Test register should be switched. After correcting this bug, we verified by changing the value of reset time register, the pulse generated for reset is also changed as expected on scope. Thanks, will queue this for 2.6.38 since it looks like there are no in-tree users in 2.6.37. These defines are not needed anymore, it is legacy stuff done before we generated the whole prm44xx.h. Here are the entries in the prm44xx.h, line 574. /* PRM.DEVICE_PRM register offsets */ #define OMAP4_PRM_RSTCTRL_OFFSET0x #define OMAP4_PRM_RSTST_OFFSET 0x0004 #define OMAP4_PRM_RSTTIME_OFFSET0x0008 We'd better get rid of these old entries in prm.h Regards, Benoit -- 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] MFD: TWL/TPS: fix twl_probe section mismatch warning in mfd/twl-core.c
Hello Samuel, On Tue, 7 Dec 2010, Samuel Ortiz wrote: > On Mon, Dec 06, 2010 at 06:40:38PM -0700, Paul Walmsley wrote: > > > > That's fine with me. Samuel et al, Bryan's already done a patch > > for this stuff: > > > > https://patchwork.kernel.org/patch/367011/ > > > > so we should use that instead, if you're happy with it. Samuel, maybe we > > could get an ack from you on it? > The twl driver is not OMAP specific, so this should be a separate patch thatI > will merge to my mfd tree. > If you really insist in pushing this through Tony's tree, then please add my > Acked-by for the mfd part. I don't insist at all :-) Bryan, maybe split your patch into a mach-omap2 patch and a TWL driver-specific patch, and send the latter for Samuel? - 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] Correct definition of register of OMAP4_RM_RSTST and OMAP4_RM_RSTTIME
Hello, On Tue, 7 Dec 2010, MING ZHOU wrote: > Since we need to reconfigure Reset time for OMAP4, we found the OMAP4 > register definition for reset time is wrong according to spec of > OMAP4. And we verified this by reading default value of register. We > found the offset definition of Reset time and Reset Test register > should be switched. After correcting this bug, we verified by changing > the value of reset time register, the pulse generated for reset is > also changed as expected on scope. Thanks, will queue this for 2.6.38 since it looks like there are no in-tree users in 2.6.37. - 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 1/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
On Tue, Dec 7, 2010 at 2:53 PM, Dave Martin wrote: [...] > Note that converting to C doesn't mean that code which attempts to > copy function bodies will work: you still need to handle the fact that > if f() is a C function symbol, then the value of the symbol f is > actually the function's base address + 1. See my changes in sram.c, To clarify, this applies *if* f is a Thumb symbol. Cheers ---Dave -- 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/3] ARM: omap: Enable low-level omap3 PM code to work withCONFIG_THUMB2_KERNEL
Hi,
On Tue, Dec 7, 2010 at 11:59 AM, Jean Pihet wrote:
> Hi Dave,
>
> On Tue, Dec 7, 2010 at 11:16 AM, Dave Martin wrote:
>> On Tue, Dec 7, 2010 at 6:31 AM, Santosh Shilimkar
>> wrote:
>>> Dave,
-Original Message-
From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
boun...@lists.linaro.org] On Behalf Of Dave Martin
Sent: Monday, December 06, 2010 11:06 PM
To: linux-arm-ker...@lists.infradead.org
Cc: Tony Lindgren; Dave Martin; linux-omap@vger.kernel.org; linaro-
d...@lists.linaro.org
Subject: [PATCH v2 1/3] ARM: omap: Enable low-level omap3 PM code to
>>> work
withCONFIG_THUMB2_KERNEL
>>
>> [...]
>>
>>>
>>> No need to mention but this patch changes lot of things around
>>> power management code. You said " Tested on: omap3 (Beagle xM A2)"
>>>
>>> What did you test ? Is it just boot test ? For sure just boot
>>> test is not enough for this patch and needs to test the PM.
>>
>> That's a fair point--- yes, I've only tested boot / reboot / shutdown so far.
>>
> The ASM idle code is being reworked right now, which means the T2
> support will need to be reworked on top of the patches. Cf. [1] and
> [2].
[...]
On Tue, Dec 7, 2010 at 12:59 PM, Jean Pihet wrote:
[...]
> For your information, the on-going changes are:
> - run (most of the) code from the DDR instead of the internal SRAM.
> - convert the ASM idle code to C-code,
>
> I am working on getting those changes submitted, it should be done this week.
>
> Unfortunately those changes have implications on your changes for T2.
> As far as I understood converting the code to C-code should solve the
> T2 problem as well. What do you think?
>
> In any case I will let you know. Could you test the changes when they
> are available?
[...]
In general, converting the code to C will solve a lot of potential
problems. If you don't copy the code, that also simplifies matters.
Note that converting to C doesn't mean that code which attempts to
copy function bodies will work: you still need to handle the fact that
if f() is a C function symbol, then the value of the symbol f is
actually the function's base address + 1. See my changes in sram.c,
pm34xx.c etc.
If there are still bits of ARM code (such as the resume re-entry
point?) some care will still be needed there.
Anyone maintaining low-level and assembler code may find the following
useful: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
>> If you have any thoughts about how to exercise the power management
>> functionality more completely, I'd be happy to have a go...
> Cf. [3] for more details on how to exercise the PM on the target. This
> wiki page is slightly outdated but the idea is still the same. Note
> that only cpuidle is currently supported correctly on l-o master.
>
> [1] http://marc.info/?l=linux-omap&m=129139584919242&w=2
> [2] http://marc.info/?l=linux-omap&m=129172034809447&w=2
> [3] http://elinux.org/OMAP_Power_Management
Thanks for this info
Humm, which reference tree should I be using? I'm not convinced it
works properly/usefully in the linaro trees ... only OMAP_PM_NOOP is
provided, and when I echo mem >/sys/power/state, the platform does not
crash (at least, it doesn't lock up) but doesn't appear to suspend
properly either. Also, I'm not seeing your debugs contents.
On a separate topic, I have some firmware questions you might be able to answer:
* Does the secure firmware attempt to read the comment field from
SMC instructions? And if so, does it assume the SMC is in ARM code?
* Is the secure firmware able to cope with a Thumb resume re-entry point?
Currently, I've taken the conservative approach and assume that the
answer to both of these questions is "no". But this means that a few
bits of code need to be built as ARM which could otherwise be Thumb.
It would be cleaner to get the amount of ARM code down to an absolute
minimum when building a Thumb kernel.
Some specific comments on your patches:
After the label "finished:" in sleep34xx.S
+ ldr r1, kernel_flush
+ mov lr, pc
+ bx r1
If the code might be built as Thumb-2, this won't work correctly,
because the Thumb bit (bit 0) will not get set properly in lr.
Instead:
+ ldr r1, kernel_flush
+ blx r1
Even if you think this code isn't going to be built for Thumb-2, it's
specific to v7+ platforms, so I recommend you use the above change
anyway: it's more compact and will help avoid maintenance problems
further down the line...
+ str r4, wait_dll_lock_counter
[...]
+ str r4, kick_counter
PC-relative stores are illegal in Thumb-2. Worse, current binutils
will assemble invalid code if you do this in the source and build for
Thumb-2. For details and my fix, search for "PC-relative stores" on
http://lists.arm.linux.org.uk/lurker/message/20101130.133117.a98bf92f.en.html
+ENTRY(get_omap3630_restore_pointer)
+stmfd sp!, {lr} @ save registers on stack
+ adr r0, restore_3630
If restore_
RE: [PATCH 1/2] AM35x: musb: fix compilation error
Hi, > >> Is AM35x that different ? Can't you just write to MUSB_INTRRX > >> MUSB_INTRTX and MUSB_INTRUSB ?? > >Writing to MUSB_INTRRX/TX/USB wouldn't help. We have to clear interrupt > >Bit in control register INTR_LVL_CLR. > > I see, thanks for the info :-) Felipe, I have recreated this patch (attached) on top of your patch set and AM35x is working. Thanks, Ajay > > -- > balbi 0001-musb-am35x-fix-compile-error-due-to-control-apis.patch Description: 0001-musb-am35x-fix-compile-error-due-to-control-apis.patch
Re: [PATCH] OMAP4: Pandaboad: Add omap_reserve functionality
Raghuveer Murthy had written, on 12/07/2010 06:25 AM, the following: This patch adds omap_reserve functionality to board-omap4panda.c. Helps in the reserving boot time memory in SDRAM, used here for framebuffer allocation. Signed-off-by: Russell King Since Russell did not directly contribute to this patch, you should rather give the reference commit ID where Russell patched similar issues and CC Russell here. Also please CC linux-arm ML as well for these fixes to help Tony. Signed-off-by: Raghuveer Murthy --- arch/arm/mach-omap2/board-omap4panda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 1ecd0a6..ad6b5cc 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -392,6 +392,7 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") /* Maintainer: David Anders - Texas Instruments Inc */ .boot_params= 0x8100, .map_io = omap4_panda_map_io, + .reserve= omap_reserve, .init_irq = omap4_panda_init_irq, .init_machine = omap4_panda_init, .timer = &omap_timer, Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] arm: OMAP4430: musb: Enable musb device initialization for OMAP4430
musb device registration during board initialization of OMAP4430SDP
and OMAP4430 PANDA.Enable the musb OTG mode.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|6 ++
arch/arm/mach-omap2/board-omap4panda.c |2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,7 +227,7 @@ static void __init omap_4430sdp_init_irq
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
- .mode = MUSB_PERIPHERAL,
+ .mode = MUSB_OTG,
.power = 100,
};
@@ -522,9 +522,7 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
- if (!cpu_is_omap44xx())
- usb_musb_init(&musb_board_data);
+ usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
if (status) {
Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
+++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
@@ -133,7 +133,7 @@ error1:
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
- .mode = MUSB_PERIPHERAL,
+ .mode = MUSB_OTG,
.power = 100,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: musb: Adding musb support for OMAP4430
OMAP4430 supports UTMI and ULPI types of transceiver interface.
In UTMI mode: The PHY is embedded within OMAP4430. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
musb driver is register for atomic notifications from the transceiver
driver to get the event notifications for connect/disconnect and ID-GND.
Based on these events call the transceiver init/shutdown function to
configure the transceiver to toggle the VBUS valid, session end and ID_GND
signals to musb.
For ID_GND event notifications, toggle the ID_GND signal and then wait for
musb to be configured as "A" device, and then call the transceiver function
to set the VBUS.
using otg_get_last_event function to get the missed transceiver events
if the cable or device is connected before registration(musb driver load).
In OTG mode and musb as a host, When the Micro A connector used, VBUS is turned
on
and session bit set. When the device is connected, enumeration goes through.
When the device disconnected from the other end of the connector(ID is still
grounded),
link will detect the disconnect and end the session. When the device is
connected back,
there are no events generated in the TWL6030-usb, and link is already down.So
the device is
not detected.Removed the session bit disable code which will recognize the
connect of the device..
Signed-off-by: Hema HK
Cc: Felipe Balbi
---
drivers/usb/musb/musb_core.c |5 ++
drivers/usb/musb/musb_core.h |1
drivers/usb/musb/musb_gadget.c |1
drivers/usb/musb/omap2430.c| 88 ++---
4 files changed, 89 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/usb/musb/musb_core.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.c
+++ linux-2.6/drivers/usb/musb/musb_core.c
@@ -2116,6 +2116,11 @@ bad_config:
& MUSB_DEVCTL_BDEVICE
? 'B' : 'A'));
+ /*
+* Host only mode, check whether the device is already
+* connected
+*/
+ otg_get_last_event(musb->xceiv);
} else /* peripheral is enabled */ {
MUSB_DEV_MODE(musb);
musb->xceiv->default_a = 0;
Index: linux-2.6/drivers/usb/musb/musb_core.h
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -411,6 +411,7 @@ struct musb {
struct timer_list otg_timer;
#endif
+ struct notifier_block nb;
/* called with IRQs blocked; ON/nonzero implies starting a session,
* and waiting at least a_wait_vrise_tmout.
Index: linux-2.6/drivers/usb/musb/musb_gadget.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_gadget.c
+++ linux-2.6/drivers/usb/musb/musb_gadget.c
@@ -1809,6 +1809,7 @@ int usb_gadget_probe_driver(struct usb_g
hcd->self.uses_pio_for_control = 1;
}
}
+ otg_get_last_event(musb->xceiv);
}
return retval;
Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c
@@ -57,13 +57,8 @@ static void musb_do_idle(unsigned long _
spin_lock_irqsave(&musb->lock, flags);
- devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
-
switch (musb->xceiv->state) {
case OTG_STATE_A_WAIT_BCON:
- devctl &= ~MUSB_DEVCTL_SESSION;
- musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
-
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE) {
musb->xceiv->state = OTG_STATE_B_IDLE;
@@ -142,20 +137,34 @@ static void omap2430_try_idle(struct mus
static void omap2430_set_vbus(struct musb *musb, int is_on)
{
u8 devctl;
+ long int timeout = 0x;
/* HDRC controls CPEN, but beware current surges during device
* connect. They can trigger transient overcurrent conditions
* that must be ignored.
*/
-
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
if (is_on) {
- musb->is_active = 1;
- musb->xceiv->default_a = 1;
-
[PATCH 5/7] usb: musb: TWL6030: Selecting TWL6030_USB transceiver
Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and adding OMAP4 internal phy code for compilation Signed-off-by: Hema HK Cc: Felipe Balbi Cc: Tony Lindgren --- arch/arm/mach-omap2/Makefile |1 + drivers/usb/musb/Kconfig |1 + 2 files changed, 2 insertions(+) Index: linux-2.6/arch/arm/mach-omap2/Makefile === --- linux-2.6.orig/arch/arm/mach-omap2/Makefile +++ linux-2.6/arch/arm/mach-omap2/Makefile @@ -180,6 +180,7 @@ obj-$(CONFIG_MACH_SBC3530) += board-oma usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o obj-y += $(usbfs-m) $(usbfs-y) obj-y += usb-musb.o +obj-$(CONFIG_TWL6030_USB) += omap_phy_internal.o obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o obj-y += usb-ehci.o Index: linux-2.6/drivers/usb/musb/Kconfig === --- linux-2.6.orig/drivers/usb/musb/Kconfig +++ linux-2.6/drivers/usb/musb/Kconfig @@ -12,6 +12,7 @@ config USB_MUSB_HDRC depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP + select TWL4030_USB if (MACH_OMAP_3430SDP || MACH_OMAP4_PANDA) select USB_OTG_UTILS tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' help -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] mfd: TWL6030: OMAP4: Registering the TWL6030-usb device
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to be used twl630-usb driver.
Signed-off-by: Hema HK
Cc: Samuel Ortiz
Cc: Felipe Balbi
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|9 +-
arch/arm/mach-omap2/board-omap4panda.c |7 +
drivers/mfd/twl-core.c | 44 +
include/linux/i2c/twl.h|6
4 files changed, 59 insertions(+), 7 deletions(-)
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -231,6 +231,13 @@ static struct omap_musb_board_data musb_
.power = 100,
};
+static struct twl4030_usb_data omap4_usbphy_data = {
+ .phy_init = omap4430_phy_init,
+ .phy_exit = omap4430_phy_exit,
+ .phy_power = omap4430_phy_power,
+ .phy_set_clock = omap4430_phy_set_clk,
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -450,6 +457,7 @@ static struct twl4030_platform_data sdp4
.vaux1 = &sdp4430_vaux1,
.vaux2 = &sdp4430_vaux2,
.vaux3 = &sdp4430_vaux3,
+ .usb= &omap4_usbphy_data
};
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
@@ -514,8 +522,6 @@ static void __init omap_4430sdp_init(voi
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
- /* OMAP4 SDP uses internal transceiver so register nop transceiver */
- usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(&musb_board_data);
Index: linux-2.6/drivers/mfd/twl-core.c
===
--- linux-2.6.orig/drivers/mfd/twl-core.c
+++ linux-2.6/drivers/mfd/twl-core.c
@@ -95,7 +95,8 @@
#define twl_has_rtc() false
#endif
-#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE)
+#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE) ||\
+ defined(CONFIG_TWL6030_USB) || defined(CONFIG_TWL6030_USB_MODULE)
#define twl_has_usb() true
#else
#define twl_has_usb() false
@@ -682,6 +683,43 @@ add_children(struct twl4030_platform_dat
usb3v1.dev = child;
}
}
+ if (twl_has_usb() && pdata->usb && twl_class_is_6030()) {
+
+ static struct regulator_consumer_supply usb3v3 = {
+ .supply = "vusb",
+ };
+
+ if (twl_has_regulator()) {
+ /* this is a template that gets copied */
+ struct regulator_init_data usb_fixed = {
+ .constraints.valid_modes_mask =
+ REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .constraints.valid_ops_mask =
+ REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ };
+
+ child = add_regulator_linked(TWL6030_REG_VUSB,
+ &usb_fixed, &usb3v3, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
+ child = add_child(0, "twl6030_usb",
+ pdata->usb, sizeof(*pdata->usb),
+ true,
+ /* irq1 = VBUS_PRES, irq0 = USB ID*/
+ pdata->irq_base + USBOTG_INTR_OFFSET,
+ pdata->irq_base + USB_PRES_INTR_OFFSET);
+
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ /* we need to connect regulators to this transceiver */
+ if (twl_has_regulator() && child)
+ usb3v3.dev = child;
+
+ }
if (twl_has_watchdog()) {
child = add_child(0, "twl4030_wdt", NULL, 0, false, 0, 0);
@@ -815,10 +853,6 @@ add_children(struct twl4030_platform_dat
if (IS_ERR(child))
return PTR_ERR(child);
- child = add_regulator(TWL6030_REG_VUSB, pdata->vusb);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
child = add_regulator(TWL6030_REG_VAUX1_6030, pdata->vaux1);
if (IS_ERR(child))
return PTR_ERR(child);
Index: linux-2.6/
[PATCH 3/7] usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver.
Added the TWL6030-usb transceiver option in the Kconfig Signed-off-by: Hema HK Cc: Felipe Balbi Cc: David Brownell --- drivers/usb/otg/Kconfig | 12 1 file changed, 12 insertions(+) Index: linux-2.6/drivers/usb/otg/Kconfig === --- linux-2.6.orig/drivers/usb/otg/Kconfig +++ linux-2.6/drivers/usb/otg/Kconfig @@ -59,6 +59,18 @@ config TWL4030_USB This transceiver supports high and full speed devices plus, in host mode, low speed. +config TWL6030_USB + tristate "TWL6030 USB Transceiver Driver" + depends on TWL4030_CORE + select USB_OTG_UTILS + help + Enable this to support the USB OTG transceiver on TWL6030 + family chips. This TWL6030 transceiver has the VBUS and ID GND + and OTG SRP events capabilities. For all other transceiver functionality + UTMI PHY is embedded in OMAP4430.The internal PHY configurations APIs + are hooked to this driver through platform_data structure. + The definition of internal PHY APIs are in the mach-omap2 layer. + config NOP_USB_XCEIV tristate "NOP USB Transceiver Driver" select USB_OTG_UTILS -- 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/7] usb: otg: Adding twl6030-usb transceiver driver for
Adding the twl6030-usb transceiver support for OMAP4 musb driver.
OMAP4 supports 2 types of transceiver interface.
1. UTMI: The PHY is embedded within OMAP4. The transceiver functionality
is split between the twl6030 PMIC chip and OMAP4430. The VBUS, ID pin
sensing and OTG SRP generation part is integrated in TWL6030 and UTMI PHY
functionality is embedded within the OMAP4430.
There is no direct interactions between the MUSB controller and TWL6030
chip to communicate the session-valid, session-end and ID-GND events.
It has to be done through a software by setting/resetting bits in
one of the control module register of OMAP4430 which in turn toggles
the appropriate signals to MUSB controller.
The internal transceiver has functional clocks and
powerdown bits to powerdown the PHY for power saving.
Since there is no option available for having 2 transceiver drivers
for one USB controller, internal PHY specific APIs are passed through
plaform_data function pointers to use in the twl6030-usb transceiver
driver.
2. ULPI interface is provided for off-chip transceivers.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
Cc: David Brownell
---
arch/arm/mach-omap2/omap_phy_internal.c | 133
arch/arm/plat-omap/include/plat/usb.h |4
drivers/usb/otg/Makefile|1
drivers/usb/otg/twl6030-usb.c | 514
4 files changed, 652 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- /dev/null
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -0,0 +1,148 @@
+/*
+ * This file configures the internal USB PHY in OMAP4430. Used
+ * with TWL6030 transceiver and MUSB on OMAP4430.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *Author: Hema HK
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* OMAP control module register for UTMI PHY */
+#define CONTROL_DEV_CONF 0x300
+#define PHY_PD 0x1
+
+#define USBOTGHS_CONTROL 0x33c
+#defineAVALID BIT(0)
+#defineBVALID BIT(1)
+#defineVBUSVALID BIT(2)
+#defineSESSEND BIT(3)
+#defineIDDIG BIT(4)
+
+static struct clk *phyclk, *clk48m, *clk32k;
+static void __iomem *ctrl_base;
+
+int omap4430_phy_init(struct device *dev)
+{
+ ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
+ if (!ctrl_base) {
+ dev_err(dev, "control module ioremap failed\n");
+ return -ENOMEM;
+ }
+ /* Power down the phy */
+ __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+ phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
+
+ if (IS_ERR(phyclk)) {
+ dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n");
+ iounmap(ctrl_base);
+ return PTR_ERR(phyclk);
+ }
+
+ clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m");
+ if (IS_ERR(clk48m)) {
+ dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n");
+ clk_put(phyclk);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk48m);
+ }
+
+ clk32k = clk_get(dev, "usb_phy_cm_clk32k");
+ if (IS_ERR(clk32k)) {
+ dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n");
+ clk_put(phyclk);
+ clk_put(clk48m);
+ iounmap(ctrl_base);
+ return PTR_ERR(clk32k);
+ }
+ return 0;
+}
+
+int omap4430_phy_set_clk(struct device *dev, int on)
+{
+ static int state;
+
+ if (on && !state) {
+ /* Enable the phy clocks */
+ clk_enable(phyclk);
+ clk_enable(clk48m);
+ clk_enable(clk32k);
+ state = 1;
+ } else if (state) {
+ /* Disable the phy clocks */
+ clk_disable(phyclk);
+ clk_disable(clk48m);
+ clk_disable(clk32k);
+ state = 0;
+ }
+ return 0;
+}
+
+int omap4430_phy_power(struct
[PATCH 1/7] mfd: TWL6030: USBOTG VBUS event generation on
With TWL6030-usb, VBUS SESS_VLD and SESS_END events are not generated
as expected. When these interrupts are enabled, charger VBUS detection
interrupt does not get generated. So USBOTG has to be dependent on charger
VBUS interrupts.
So added one bit for USBOTG and changed the handler to call the
USBOTG handler whenever there is a charger VBUS interrpt.
VBUS SESS_VLD and SESS_END event generation issue is under debug with
HW team. This fix might not be required once after fixing the issue.
Signed-off-by: Balaji TK
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Samuel Ortiz
---
drivers/mfd/twl6030-irq.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/mfd/twl6030-irq.c
===
--- linux-2.6.orig/drivers/mfd/twl6030-irq.c
+++ linux-2.6/drivers/mfd/twl6030-irq.c
@@ -74,7 +74,7 @@ static int twl6030_interrupt_mapping[24]
USBOTG_INTR_OFFSET, /* Bit 16 ID_WKUP */
USBOTG_INTR_OFFSET, /* Bit 17 VBUS_WKUP */
USBOTG_INTR_OFFSET, /* Bit 18 ID */
- USBOTG_INTR_OFFSET, /* Bit 19 VBUS*/
+ USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
CHARGER_INTR_OFFSET,/* Bit 21 EXT_CHRG*/
CHARGER_INTR_OFFSET,/* Bit 22 INT_CHRG*/
@@ -128,6 +128,13 @@ static int twl6030_irq_thread(void *data
sts.bytes[3] = 0; /* Only 24 bits are valid*/
+ /*
+* Since VBUS status bit is not reliable for VBUS disconnect
+* use CHARGER VBUS detection status bit instead.
+*/
+ if (sts.bytes[2] & 0x10)
+ sts.bytes[2] |= 0x08;
+
for (i = 0; sts.int_sts; sts.int_sts >>= 1, i++) {
local_irq_disable();
if (sts.int_sts & 0x1) {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] usb: otg: TWL6030: OMAP4430: musb & transceiver driver support for OMAP4
This patch series has the support for TWL6030-usb transceiver driver and changes in the musb driver to make it functional with OMAP4430. OMAP4 musb support UTMI and ULPI transceiver interfaces. In UTMI mode, the transceiver functionality is split between the TWL6030 PMIC chip and OMAP4 embedded PHY. The TWL6030 transceiver driver code is under otg folder and internal UTMI PHY specific code changes are defined under mach-omap2 directory and functions are passed through platform_data structure. This patch series is based on V2.6.37-rc4 + [1]+[2]+[3]+[4]. [1] http://www.listware.net/201011/linux-usb/ 65625-patch-resend-v3-usb-musb-do-not-use-dma-for-control-transfers.html [2] http://www.spinics.net/lists/linux-usb/msg37105.html [3] http://permalink.gmane.org/gmane.linux.usb.general/37123 [4] Felipe's musb-reorg patch series. http://gitorious.org/usb/usb/commits/musb-hw Tested musb device and host mode functionality with OMAP4430SDP and OMAP3630 ZOOM3. Cc: Felipe Balbi Cc: Tony Lindgren Cc: David Brownell Cc: Samuel Ortiz --- Hema HK (7): mfd: TWL6030: USBOTG VBUS event generation on charger VBUS events. usb: otg: Adding twl6030-usb transceiver driver for OMAP4430 musb usb: otg: Kconfig: Add Kconfig option for TWL6030 transceiver. mfd: TWL6030: OMAP4: Registering the TWL6030-usb device usb: musb: TWL6030: Selecting TWL6030_USB transceiver for OMAP4 usb: musb: Adding musb support for OMAP4430 arm: OMAP4430: musb: Enable musb device initialization for OMAP4430 arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-4430sdp.c | 15 +- arch/arm/mach-omap2/board-omap4panda.c |9 +- arch/arm/mach-omap2/omap_phy_internal.c | 123 +++ arch/arm/plat-omap/include/plat/usb.h |4 + drivers/mfd/twl-core.c | 44 +++- drivers/mfd/twl6030-irq.c |9 +- drivers/usb/musb/Kconfig|1 + drivers/usb/musb/musb_core.c|5 + drivers/usb/musb/musb_core.h|1 + drivers/usb/musb/musb_gadget.c |1 + drivers/usb/musb/omap2430.c | 85 +- drivers/usb/otg/Kconfig | 11 + drivers/usb/otg/Makefile|1 + drivers/usb/otg/twl6030-usb.c | 527 +++ include/linux/i2c/twl.h |6 + 16 files changed, 824 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files
On Mon, Dec 06, 2010 at 06:25:17PM -0700, Paul Walmsley wrote:
> In preparation for adding OMAP4-specific PRCM accessor/mutator
> functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
> files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
> moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
> OMAP2xxx/3xxx-specific.
Acked-by: Mark Brown
--
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] musb: am35x: fix compile error due to control apis
Hello. On 06-12-2010 20:54, Tony Lindgren wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. I'm not fond of the whole approach. I'm not sure why accesses to the control registers are such a no-no, taking into account that one needs to access such regisyter to clear the interrupt... Because drivers should arch independent and any tinkering of the platform level registers will lead into pains later on that I end up having to deal with. To me it seem you just init to separate out the transceiver, right? We also have to install a hook to clear the MUSB level interrupt via the control register -- that's a thing that makes me dubious about not allowing drivers to access the control registers. Tony WBR, Sergei -- 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
