[PATCH 8/8] omapfb: Blizzard: constify register address tables
From: Tommi Rantala
Constify register address tables
Cc: Tomi Valkeinen
Cc: Imre Deak
Signed-off-by: Tommi Rantala
Signed-off-by: Tony Lindgren
---
drivers/video/omap/blizzard.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c
index ce28be6..70dadf9 100644
--- a/drivers/video/omap/blizzard.c
+++ b/drivers/video/omap/blizzard.c
@@ -93,7 +93,7 @@ struct blizzard_reg_list {
};
/* These need to be saved / restored separately from the rest. */
-static struct blizzard_reg_list blizzard_pll_regs[] = {
+static const struct blizzard_reg_list blizzard_pll_regs[] = {
{
.start = 0x04, /* Don't save PLL ctrl (0x0C) */
.end= 0x0a,
@@ -104,7 +104,7 @@ static struct blizzard_reg_list blizzard_pll_regs[] = {
},
};
-static struct blizzard_reg_list blizzard_gen_regs[] = {
+static const struct blizzard_reg_list blizzard_gen_regs[] = {
{
.start = 0x18, /* SDRAM control */
.end= 0x20,
@@ -1372,7 +1372,7 @@ static void blizzard_get_caps(int plane, struct
omapfb_caps *caps)
(1 << OMAPFB_COLOR_YUV420);
}
-static void _save_regs(struct blizzard_reg_list *list, int cnt)
+static void _save_regs(const struct blizzard_reg_list *list, int cnt)
{
int i;
@@ -1383,7 +1383,7 @@ static void _save_regs(struct blizzard_reg_list *list,
int cnt)
}
}
-static void _restore_regs(struct blizzard_reg_list *list, int cnt)
+static void _restore_regs(const struct blizzard_reg_list *list, int cnt)
{
int i;
--
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/8] omapfb: Blizzard: fix pointer to be const
From: Tommi Rantala
Fixes a compiler warning:
warning: assignment discards qualifiers from pointer target type
Cc: Tomi Valkeinen
Cc: Imre Deak
Signed-off-by: Tommi Rantala
Signed-off-by: Tony Lindgren
---
drivers/video/omap/blizzard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c
index d5e5955..ce28be6 100644
--- a/drivers/video/omap/blizzard.c
+++ b/drivers/video/omap/blizzard.c
@@ -191,7 +191,7 @@ struct blizzard_struct {
struct omapfb_device*fbdev;
struct lcd_ctrl_extif *extif;
- struct lcd_ctrl *int_ctrl;
+ const struct lcd_ctrl *int_ctrl;
void(*power_up)(struct device *dev);
void(*power_down)(struct device *dev);
--
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/8] omapfb: Condition mutex acquisition
From: Sergio Aguirre
This fixes a bug introduced by this commit ID:
commit 537a1bf059fa312355696fa6db80726e655e7f17
Author: Krzysztof Helt
Date: Tue Jun 30 11:41:29 2009 -0700
fbdev: add mutex for fb_mmap locking
In which a mutex was added when changing smem_start and smem_len fields,
so the mutex inside the fb_mmap() call is actually used.
The problem was that set_fb_fix, which modifies the above 2 fields,
was called before and after registering the framebuffer,
which when used before registration, lead to a failed attempt to
use an uninitialized mutex.
Solution: Don't use mutex before framebuffer registration.
Signed-off-by: Sergio Aguirre
Acked-by: Tomi Valkeinen
Acked-by: Imre Deak
Signed-off-by: Tony Lindgren
---
drivers/video/omap/omapfb_main.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..0d0c8c8 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -393,7 +393,7 @@ static void omapfb_sync(struct fb_info *fbi)
* Set fb_info.fix fields and also updates fbdev.
* When calling this fb_info.var must be set up already.
*/
-static void set_fb_fix(struct fb_info *fbi)
+static void set_fb_fix(struct fb_info *fbi, int from_init)
{
struct fb_fix_screeninfo *fix = &fbi->fix;
struct fb_var_screeninfo *var = &fbi->var;
@@ -403,10 +403,16 @@ static void set_fb_fix(struct fb_info *fbi)
rg = &plane->fbdev->mem_desc.region[plane->idx];
fbi->screen_base= rg->vaddr;
- mutex_lock(&fbi->mm_lock);
- fix->smem_start = rg->paddr;
- fix->smem_len = rg->size;
- mutex_unlock(&fbi->mm_lock);
+
+ if (!from_init) {
+ mutex_lock(&fbi->mm_lock);
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ mutex_unlock(&fbi->mm_lock);
+ } else {
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ }
fix->type = FB_TYPE_PACKED_PIXELS;
bpp = var->bits_per_pixel;
@@ -704,7 +710,7 @@ static int omapfb_set_par(struct fb_info *fbi)
int r = 0;
omapfb_rqueue_lock(fbdev);
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
r = ctrl_change_mode(fbi);
omapfb_rqueue_unlock(fbdev);
@@ -904,7 +910,7 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct
omapfb_mem_info *mi)
if (old_size != size) {
if (size) {
memcpy(&fbi->var, new_var, sizeof(fbi->var));
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
} else {
/*
* Set these explicitly to indicate that the
@@ -1504,7 +1510,7 @@ static int fbinfo_init(struct omapfb_device *fbdev,
struct fb_info *info)
var->bits_per_pixel = fbdev->panel->bpp;
set_fb_var(info, var);
- set_fb_fix(info);
+ set_fb_fix(info, 1);
r = fb_alloc_cmap(&info->cmap, 16, 0);
if (r != 0)
--
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/8] omap: iovmm: Fix incorrect spelling
From: Hiroshi DOYU
Fix incorrect spelling
Signed-off-by: Hiroshi DOYU
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 57f7122..0e5573d 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -47,7 +47,7 @@
* 'va': mpu virtual address
*
* 'c':contiguous memory area
- * 'd':dicontiguous memory area
+ * 'd':discontiguous memory area
* 'a':anonymous memory allocation
* '()': optional feature
*
@@ -398,7 +398,7 @@ static inline void sgtable_drain_vmalloc(struct sg_table
*sgt)
{
/*
* Actually this is not necessary at all, just exists for
-* consistency of the code readibility.
+* consistency of the code readability.
*/
BUG_ON(!sgt);
}
@@ -434,7 +434,7 @@ static inline void sgtable_drain_kmalloc(struct sg_table
*sgt)
{
/*
* Actually this is not necessary at all, just exists for
-* consistency of the code readibility
+* consistency of the code readability
*/
BUG_ON(!sgt);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] omap: iovmm: Add missing mutex_unlock
From: Daniel Walker I was using Coccinelle with the mutex_unlock semantic patch, and it unconvered this problem. It appears to be a valid missing unlock issue. This change should correct it by moving the unlock below the label. This patch is against the mainline kernel. Cc: Julia Lawall Cc: Hiroshi DOYU Signed-off-by: Daniel Walker Signed-off-by: Kevin Hilman Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/iovmm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 0e5573d..dc3fac3 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -363,8 +363,9 @@ void *da_to_va(struct iommu *obj, u32 da) goto out; } va = area->va; - mutex_unlock(&obj->mmap_lock); out: + mutex_unlock(&obj->mmap_lock); + return va; } EXPORT_SYMBOL_GPL(da_to_va); -- 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: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
On Thu, Sep 24, 2009 at 03:57:13PM +0530, Govindraj.R wrote: > From: Govindraj R > > This patch adds support for OMAP3430-HIGH SPEED UART Controller. > > Signed-off-by:Govindraj R > Reviewed-by: Alan Cox > Reviewed-by: Tony Lindgren > --- > +config SERIAL_OMAP > + bool "OMAP serial port support" > + depends on ARM && ARCH_OMAP > + select SERIAL_CORE > + help > + If you have a machine based on an Texas Instruments OMAP CPU you > + can enable its onboard serial ports by enabling this option. If it's OMAP3 hardware then should the "depends on" be ARCH_OMAP3 || ARCH_OMAP4, rather than allowing it for OMAP1 + 2 as well? J. -- Revd. Jonathan McDowell, ULC | If they can't take a jokefuck 'em. -- 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/8] omap: SRAM: flush the right address after memcpy in omap_sram_push
From: ye janboe the original flush operation is to flush the function address which is copied from. But we do not change the function code and it is not necessary to flush it. Signed-off-by: janboe Acked-by: Paul Walmsley --- arch/arm/plat-omap/sram.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 925f647..75d1f26 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -270,7 +270,8 @@ void * omap_sram_push(void * start, unsigned long size) omap_sram_ceil -= size; omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *)); memcpy((void *)omap_sram_ceil, start, size); - flush_icache_range((unsigned long)start, (unsigned long)(start + size)); + flush_icache_range((unsigned long)omap_sram_ceil, + (unsigned long)(omap_sram_ceil + size)); return (void *)omap_sram_ceil; } -- 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/8] omap: Lock DPLL5 at boot
From: Rajendra Nayak
Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and
USBTLL f-clock are the only users of this DPLL, and 120MHz is
is the only recommended rate for these clocks.
With this patch, the 60 MHz ULPI clock is generated correctly.
Tested on an OMAP3430 SDP.
Signed-off-by: Rajendra Nayak
Signed-off-by: Anand Gadiyar
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock34xx.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index fafcd32..489556e 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -338,6 +338,13 @@ static struct omap_clk omap34xx_clks[] = {
*/
#define SDRC_MPURATE_LOOPS 96
+/*
+ * DPLL5_FREQ_FOR_USBHOST: USBHOST and USBTLL are the only clocks
+ * that are sourced by DPLL5, and both of these require this clock
+ * to be at 120 MHz for proper operation.
+ */
+#define DPLL5_FREQ_FOR_USBHOST 12000
+
/**
* omap3430es2_clk_ssi_find_idlest - return CM_IDLEST info for SSI
* @clk: struct clk * being enabled
@@ -1056,6 +1063,28 @@ void omap2_clk_prepare_for_reboot(void)
#endif
}
+static void omap3_clk_lock_dpll5(void)
+{
+ struct clk *dpll5_clk;
+ struct clk *dpll5_m2_clk;
+
+ dpll5_clk = clk_get(NULL, "dpll5_ck");
+ clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST);
+ clk_enable(dpll5_clk);
+
+ /* Enable autoidle to allow it to enter low power bypass */
+ omap3_dpll_allow_idle(dpll5_clk);
+
+ /* Program dpll5_m2_clk divider for no division */
+ dpll5_m2_clk = clk_get(NULL, "dpll5_m2_ck");
+ clk_enable(dpll5_m2_clk);
+ clk_set_rate(dpll5_m2_clk, DPLL5_FREQ_FOR_USBHOST);
+
+ clk_disable(dpll5_m2_clk);
+ clk_disable(dpll5_clk);
+ return;
+}
+
/* REVISIT: Move this init stuff out into clock.c */
/*
@@ -1148,6 +1177,12 @@ int __init omap2_clk_init(void)
*/
clk_enable_init_clocks();
+ /*
+* Lock DPLL5 and put it in autoidle.
+*/
+ if (omap_rev() >= OMAP3430_REV_ES2_0)
+ omap3_clk_lock_dpll5();
+
/* Avoid sleeping during omap2_clk_prepare_for_reboot() */
/* REVISIT: not yet ready for 343x */
#if 0
--
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/8] omap: Fix incorrect 730 vs 850 detection
Commit cd92204924fafbd5c7241dfd12ca3176d542e0c5 added support for omap850. However, the patch accidentally removed the wrong ifdef: # define cpu_is_omap730() 1 # endif #endif +#else +# if defined(CONFIG_ARCH_OMAP850) +# undef cpu_is_omap850 +# define cpu_is_omap850() 1 +# endif +#endif ... void omap2_check_revision(void); #endif/* defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) */ - -#endif Instead of removing removing the #endif at the end of the file, the #endif before #else should have been removed. But we cannot have multiple #else statements as pointed out by Alistair Buxton . So the fix is to: - remove the non-multi-omap special handling, as we need to detect between omap730 and omap850 anyways. - add the missing #endif back to the end of the file Reported-by: Sanjeev Premi Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/mach/cpu.h | 37 - 1 files changed, 14 insertions(+), 23 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 11e73d9..f129efb 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -303,32 +303,21 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 -#if defined(MULTI_OMAP1) -# if defined(CONFIG_ARCH_OMAP730) -# undef cpu_is_omap730 -# define cpu_is_omap730() is_omap730() -# endif -# if defined(CONFIG_ARCH_OMAP850) -# undef cpu_is_omap850 -# define cpu_is_omap850() is_omap850() -# endif -#else -# if defined(CONFIG_ARCH_OMAP730) -# undef cpu_is_omap730 -# define cpu_is_omap730() 1 -# endif -#endif -#else -# if defined(CONFIG_ARCH_OMAP850) -# undef cpu_is_omap850 -# define cpu_is_omap850() 1 -# endif -#endif - /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish - * between 330 vs. 1510 and 1611B/5912 vs. 1710. + * between 730 vs 850, 330 vs. 1510 and 1611B/5912 vs. 1710. */ + +#if defined(CONFIG_ARCH_OMAP730) +# undef cpu_is_omap730 +# define cpu_is_omap730() is_omap730() +#endif + +#if defined(CONFIG_ARCH_OMAP850) +# undef cpu_is_omap850 +# define cpu_is_omap850() is_omap850() +#endif + #if defined(CONFIG_ARCH_OMAP15XX) # undef cpu_is_omap310 # undef cpu_is_omap1510 @@ -433,3 +422,5 @@ IS_OMAP_TYPE(3430, 0x3430) int omap_chip_is(struct omap_chip_id oci); void omap2_check_revision(void); + +#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 0/8] Omap fixes for 2.6.32-rc2
Hi all, Here are some more fixes for review. Regards, Tony --- Daniel Walker (1): omap: iovmm: Add missing mutex_unlock Hiroshi DOYU (1): omap: iovmm: Fix incorrect spelling Rajendra Nayak (1): omap: Lock DPLL5 at boot Sergio Aguirre (1): omapfb: Condition mutex acquisition Tommi Rantala (2): omapfb: Blizzard: constify register address tables omapfb: Blizzard: fix pointer to be const Tony Lindgren (1): omap: Fix incorrect 730 vs 850 detection ye janboe (1): omap: SRAM: flush the right address after memcpy in omap_sram_push arch/arm/mach-omap2/clock34xx.c | 35 +++ arch/arm/plat-omap/include/mach/cpu.h | 37 - arch/arm/plat-omap/iovmm.c|9 arch/arm/plat-omap/sram.c |3 ++- drivers/video/omap/blizzard.c | 10 - drivers/video/omap/omapfb_main.c | 22 6 files changed, 75 insertions(+), 41 deletions(-) -- Signature -- 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
[OMAP3] ALSA driver 'suspend/resume' handlers
Tony,
Can you check below patch? If it is OK, please add this to omap-fixes
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Wednesday, September 30, 2009 11:38 AM
To: Jarkko Nikula
Cc: hari n; Pandita, Vikram; linux-omap@vger.kernel.org
Subject: RE: [OMAP3] ALSA driver 'suspend/resume' handlers
> -Original Message-
> From: Jarkko Nikula [mailto:jhnik...@gmail.com]
> Sent: Wednesday, September 30, 2009 11:10 AM
> To: Shilimkar, Santosh
> Cc: hari n; Pandita, Vikram; linux-omap@vger.kernel.org
> Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers
>
> On Tue, 29 Sep 2009 21:28:45 +0530
> "Shilimkar, Santosh" wrote:
>
> > > Having said that, there is also bug in the DMA driver which doesn't
> > > disable the channel in linking cases. Since we use always hardware
> > > synchronized method, hardware will take care of draining the buffer so
> no
> > > loss of data.
> > >
> > > So option B should be ok and USB case also would work as mentioned
> above.
> >
> > Which option finally we converged on this issue? Shall we fix in the DMA
> driver or you want to do this in ALSA?
> >
> For me it looks that at least the omap_stop_dma should be fixed to stop
> ongoing transfer always when it's called. As the name suggest :-)
Agree !!
Have a look at below patch and let me know if it's ok.
>From 6042ce380c36907b0740e208f243f00ca370d09e Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Wed, 30 Sep 2009 11:26:24 +0530
Subject: [PATCH] ARM: OMAP: SDMA: Stop channel in omap_stop_dma() API for
linking as well.
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Venkatraman S
CC: Hari n
CC: Jarkko Nikula
---
arch/arm/plat-omap/dma.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..633c123 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -975,6 +975,11 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l &= ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -1000,10 +1005,6 @@ void omap_stop_dma(int lch)
if (cpu_class_is_omap1())
dma_write(0, CICR(lch));
- l = dma_read(CCR(lch));
- l &= ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags &= ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
1.5.4.7
--
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
[APPLIED] [PATCH] omapfb: Blizzard: constify register address tables
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 83628644b611a6aa7854b11c3f2596980e1acc00 PatchWorks http://patchwork.kernel.org/patch/49044/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=83628644b611a6aa7854b11c3f2596980e1acc00 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] omapfb: Blizzard: fix pointer to be const
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 8fa60d5614215fcf0a9e7dccee76c1445bf79f38 PatchWorks http://patchwork.kernel.org/patch/49040/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8fa60d5614215fcf0a9e7dccee76c1445bf79f38 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] arm: omap: iovmm: add missing mutex_unlock
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): d3b34e8cb9c654902b5e486fbf27849dea48eeaf PatchWorks http://patchwork.kernel.org/patch/50274/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=d3b34e8cb9c654902b5e486fbf27849dea48eeaf -- 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] SDMA: Fixing bug in omap_dma_set_global_params()
* Venkatraman S [090923 01:25]: > On Wed, Sep 23, 2009 at 12:49 PM, Anuj Aggarwal wrote: > > Argument tparams was not being used to program > > global register GCR.HI_THREAD_RESERVED. This patch fixes the same. > > > > Signed-off-by: Anuj Aggarwal > > --- > > arch/arm/plat-omap/dma.c | 13 +++-- > > 1 files changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c > > index bf08634..7a7b6df 100644 > > --- a/arch/arm/plat-omap/dma.c > > +++ b/arch/arm/plat-omap/dma.c > > @@ -829,10 +829,10 @@ EXPORT_SYMBOL(omap_free_dma); > > * > > * @param arb_rate > > * @param max_fifo_depth > > - * @param tparams - Number of thereads to reserve : DMA_THREAD_RESERVE_NORM > > - * DMA_THREAD_RESERVE_ONET > > - * DMA_THREAD_RESERVE_TWOT > > - * > > DMA_THREAD_RESERVE_THREET > > + * @param tparams - Number of threads to reserve : DMA_THREAD_RESERVE_NORM > > + * DMA_THREAD_RESERVE_ONET > > + * DMA_THREAD_RESERVE_TWOT > > + * DMA_THREAD_RESERVE_THREET > > */ > > void > > omap_dma_set_global_params(int arb_rate, int max_fifo_depth, int tparams) > > @@ -847,8 +847,9 @@ omap_dma_set_global_params(int arb_rate, int > > max_fifo_depth, int tparams) > > if (arb_rate == 0) > > arb_rate = 1; > > > > - reg = (arb_rate & 0xff) << 16; > > - reg |= (0xff & max_fifo_depth); > > + reg = 0xff & max_fifo_depth; > > + reg |= (0x3 & tparams) << 12; > > + reg |= (arb_rate & 0xff) << 16; > > > > dma_write(reg, GCR); > > } > > max_fifo_depth should not be set to zero. Perhaps it deserves a check > similar to arb_rate ? Any news on updating this patch to also check the max_fifo_depth? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap_hsmmc: Add missing probe handler hook
* Roger Quadros [091002 05:27]:
> Quadros Roger (EXT-Teleca/Helsinki) wrote:
>> The missing probe handler hook will never probe the driver. Add it back.
>> Fixes broken MMC on OMAP.
>>
>> We use platform_driver_probe() API since omap_hsmmc is not a hot-pluggable
>> device.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mmc/host/omap_hsmmc.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 4487cc0..0aecaae 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -2013,7 +2013,7 @@ static struct platform_driver omap_hsmmc_driver = {
>> static int __init omap_hsmmc_init(void)
>> {
>> /* Register the MMC driver */
>> -return platform_driver_register(&omap_hsmmc_driver);
>> +return platform_driver_probe(&omap_hsmmc_driver, omap_hsmmc_probe);
>> }
>> static void __exit omap_hsmmc_cleanup(void)
>
> Tony,
>
> Since you've already applied my earlier patch (v1), you may used the
> attached version instead. The attached patch will apply on current head
> with commit id
>
> 30e0c4a059d83886690381222e14f35540c7f017
Thanks, will update in omap-fixes-testing.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH 2/2] omap iovmm: fix incorrect spelling
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 7dfe2bbffc9d6884d70b7bd5b197bfb44cf51472 PatchWorks http://patchwork.kernel.org/patch/51306/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7dfe2bbffc9d6884d70b7bd5b197bfb44cf51472 -- 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: Any one is still using omap-kernel on N810???
Kalle Valo wrote at 2009-09-20 12:37 -0500: > "Stefano Panella" writes: > > but I am still having problems with the internal MMC card... > > Sorry, I know nothing about mmc and I currently don't have time to study > it. But if you find a solution, please post it here. I'm sure others are > also interested. I have had problems with internal MMC also. I have not had time to work with my N810 recently, but am interested in progress. signature.asc Description: Digital signature
[PATCH 5/5] OMAP3: PM: Enable GPIO module-level wakeups
Currently, only GPIOs in the wakeup domain (GPIOs in bank 0) are enabled as wakups. This patch also enables GPIOs in the PER powerdomain (banks 2-6) to be used as possible wakeup sources. In addition, this patch ensures that all GPIO wakeups can wakeup the MPU using the PM_MPUGRPSEL_ registers. NOTE: this doesn't enable the individual GPIOs as wakeups, this simply enables the per-bank wakeups at the powerdomain level. This problem was discovered by Mike Chan when preventing the CORE powerdomain from going into retention/off. When CORE was allowed to hit retention, GPIO wakeups via IO pad were working fine, but when CORE remained on, GPIO module-level wakeups were not working properly. To test, prevent CORE from going inactive/retention/off, thus preventing the IO chain from being armed: # echo 3 > /debug/pm_debug/core_pwrdm/suspend This ensures that GPIO wakeups happen via module-level wakeups and not via IO pad. Tested on 3430SDP using the touchscreen GPIO (gpio 2, in WKUP) Tested on Zoom2 using the QUART interrup GPIO (gpio 102, in PER) Also, c.f. OMAP PM wiki for troubleshooting GPIO wakeup issues: http://elinux.org/OMAP_Power_Management Reported-by: Mike Chan Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/pm34xx.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index cf6ea9f..378c2f6 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -639,6 +639,16 @@ static void __init prcm_setup_regs(void) prm_write_mod_reg(OMAP3430_IO_EN | OMAP3430_WKUP_EN, OCP_MOD, OMAP3_PRM_IRQENABLE_MPU_OFFSET); + /* Enable GPIO wakeups in PER */ + prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 | + OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | + OMAP3430_EN_GPIO6, OMAP3430_PER_MOD, PM_WKEN); + /* and allow them to wake up MPU */ + prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 | + OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 | + OMAP3430_GRPSEL_GPIO6, + OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); + /* Don't attach IVA interrupts */ prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL); prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1); -- 1.6.4.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 4/5] OMAP3: PM: USBHOST: clear wakeup events on both hosts
From: Vikram Pandita
USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
and only a single bit in the WKST register to indicate a wakeup event.
Because of the single WKST bit, we cannot know whether a wakeup event
was on HOST1 or HOST2, so enable both fclocks before clearing the
wakeup event to ensure both hosts can properly clear the event.
Signed-off-by: Vikram Pandita
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d9440a1..cf6ea9f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -63,7 +63,7 @@ static struct powerdomain *mpu_pwrdm;
*/
static int prcm_clear_mod_irqs(s16 module, u8 regs)
{
- u32 wkst, fclk, iclk;
+ u32 wkst, fclk, iclk, clken;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
u16 fclk_off = (regs == 3) ? OMAP3430ES2_CM_FCLKEN3 : CM_FCLKEN1;
u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
@@ -77,8 +77,15 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
iclk = cm_read_mod_reg(module, iclk_off);
fclk = cm_read_mod_reg(module, fclk_off);
while (wkst) {
- cm_set_mod_reg_bits(wkst, module, iclk_off);
- cm_set_mod_reg_bits(wkst, module, fclk_off);
+ clken = wkst;
+ cm_set_mod_reg_bits(clken, module, iclk_off);
+ /*
+* For USBHOST, we don't know whether HOST1 or
+* HOST2 woke us up, so enable both f-clocks
+*/
+ if (module == OMAP3430ES2_USBHOST_MOD)
+ clken |= 1 << OMAP3430ES2_EN_USBHOST2_SHIFT;
+ cm_set_mod_reg_bits(clken, module, fclk_off);
prm_write_mod_reg(wkst, module, wkst_off);
wkst = prm_read_mod_reg(module, wkst_off);
c++;
--
1.6.4.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 3/5] OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts
From: Paul Walmsley
Clearing wakeup sources is now only done when the PRM indicates a
wakeup source interrupt. Since we don't handle any other types of
PRCM interrupts right now, warn if we get any other type of PRCM
interrupt. Either code needs to be added to the PRCM interrupt
handler to react to these, or these other interrupts should be masked
off at init.
Updated after Jon Hunter's PRCM IRQ rework by Kevin Hilman.
Signed-off-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 46 +
1 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0e7bd8e..d9440a1 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -61,7 +61,7 @@ static struct powerdomain *mpu_pwrdm;
* that any peripheral wake-up events occurring while attempting to
* clear the PM_WKST_x are detected and cleared.
*/
-static void prcm_clear_mod_irqs(s16 module, u8 regs)
+static int prcm_clear_mod_irqs(s16 module, u8 regs)
{
u32 wkst, fclk, iclk;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
@@ -69,6 +69,7 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
u16 grpsel_off = (regs == 3) ?
OMAP3430ES2_PM_MPUGRPSEL3 : OMAP3430_PM_MPUGRPSEL;
+ int c = 0;
wkst = prm_read_mod_reg(module, wkst_off);
wkst &= prm_read_mod_reg(module, grpsel_off);
@@ -80,10 +81,28 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
cm_set_mod_reg_bits(wkst, module, fclk_off);
prm_write_mod_reg(wkst, module, wkst_off);
wkst = prm_read_mod_reg(module, wkst_off);
+ c++;
}
cm_write_mod_reg(iclk, module, iclk_off);
cm_write_mod_reg(fclk, module, fclk_off);
}
+
+ return c;
+}
+
+static int _prcm_int_handle_wakeup(void)
+{
+ int c;
+
+ c = prcm_clear_mod_irqs(WKUP_MOD, 1);
+ c += prcm_clear_mod_irqs(CORE_MOD, 1);
+ c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
+ if (omap_rev() > OMAP3430_REV_ES1_0) {
+ c += prcm_clear_mod_irqs(CORE_MOD, 3);
+ c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
+ }
+
+ return c;
}
/*
@@ -106,18 +125,27 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
{
u32 irqstatus_mpu;
+ int c = 0;
do {
- prcm_clear_mod_irqs(WKUP_MOD, 1);
- prcm_clear_mod_irqs(CORE_MOD, 1);
- prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
- if (omap_rev() > OMAP3430_REV_ES1_0) {
- prcm_clear_mod_irqs(CORE_MOD, 3);
- prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
- }
-
irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+
+ if (irqstatus_mpu & (OMAP3430_WKUP_ST | OMAP3430_IO_ST)) {
+ c = _prcm_int_handle_wakeup();
+
+ /*
+* Is the MPU PRCM interrupt handler racing with the
+* IVA2 PRCM interrupt handler ?
+*/
+ WARN(c == 0, "prcm: WARNING: PRCM indicated MPU wakeup "
+"but no wakeup sources are marked\n");
+ } else {
+ /* XXX we need to expand our PRCM interrupt handler */
+ WARN(1, "prcm: WARNING: PRCM interrupt received, but "
+"no code to handle it (%08x)\n", irqstatus_mpu);
+ }
+
prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
--
1.6.4.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 2/5] OMAP3: PM: PRCM interrupt: check MPUGRPSEL register
From: Paul Walmsley
PM_WKST register contents should be ANDed with the contents of the
MPUGRPSEL registers. Otherwise the MPU PRCM interrupt handler could
wind up clearing wakeup events meant for the IVA PRCM interrupt
handler. A future revision to this code should be to read a cached
version of MPUGRPSEL from the powerdomain code, since PRM reads are
relatively slow.
Updated after Jon Hunter's PRCM IRQ change by Kevin Hilman
Signed-off-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1e7aae2..0e7bd8e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -67,8 +67,11 @@ static void prcm_clear_mod_irqs(s16 module, u8 regs)
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
u16 fclk_off = (regs == 3) ? OMAP3430ES2_CM_FCLKEN3 : CM_FCLKEN1;
u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
+ u16 grpsel_off = (regs == 3) ?
+ OMAP3430ES2_PM_MPUGRPSEL3 : OMAP3430_PM_MPUGRPSEL;
wkst = prm_read_mod_reg(module, wkst_off);
+ wkst &= prm_read_mod_reg(module, grpsel_off);
if (wkst) {
iclk = cm_read_mod_reg(module, iclk_off);
fclk = cm_read_mod_reg(module, fclk_off);
--
1.6.4.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 1/5] OMAP3: PM: Prevent hang in prcm_interrupt_handler
From: Jon Hunter
There are two scenarios where a race condition could result in a hang
in the prcm_interrupt handler. These are:
1). Waiting for PRM_IRQSTATUS_MPU register to clear.
Bit 0 of the PRM_IRQSTATUS_MPU register indicates that a wake-up event
is pending for the MPU. This bit can only be cleared if the all the
wake-up events latched in the various PM_WKST_x registers have been
cleared. If a wake-up event occurred during the processing of the prcm
interrupt handler, after the corresponding PM_WKST_x register was
checked but before the PRM_IRQSTATUS_MPU was cleared, then the CPU
would be stuck forever waiting for bit 0 in PRM_IRQSTATUS_MPU to be
cleared.
2). Waiting for the PM_WKST_x register to clear.
Some power domains have more than one wake-up source. The PM_WKST_x
registers indicate the source of a wake-up event and need to be cleared
after a wake-up event occurs. When the PM_WKST_x registers are read and
before they are cleared, it is possible that another wake-up event
could occur causing another bit to be set in one of the PM_WKST_x
registers. If this did occur after reading a PM_WKST_x register then
the CPU would miss this event and get stuck forever in a loop waiting
for that PM_WKST_x register to clear.
This patch address the above race conditions that would result in a
hang.
Signed-off-by: Jon Hunter
Reviewed-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 143 ++
1 files changed, 60 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ff5a6c..1e7aae2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -51,97 +51,74 @@ static void (*_omap_sram_idle)(u32 *addr, int save_state);
static struct powerdomain *mpu_pwrdm;
-/* PRCM Interrupt Handler for wakeups */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
+/*
+ * PRCM Interrupt Handler Helper Function
+ *
+ * The purpose of this function is to clear any wake-up events latched
+ * in the PRCM PM_WKST_x registers. It is possible that a wake-up event
+ * may occur whilst attempting to clear a PM_WKST_x register and thus
+ * set another bit in this register. A while loop is used to ensure
+ * that any peripheral wake-up events occurring while attempting to
+ * clear the PM_WKST_x are detected and cleared.
+ */
+static void prcm_clear_mod_irqs(s16 module, u8 regs)
{
- u32 wkst, irqstatus_mpu;
- u32 fclk, iclk;
+ u32 wkst, fclk, iclk;
+ u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
+ u16 fclk_off = (regs == 3) ? OMAP3430ES2_CM_FCLKEN3 : CM_FCLKEN1;
+ u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
- /* WKUP */
- wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
+ wkst = prm_read_mod_reg(module, wkst_off);
if (wkst) {
- iclk = cm_read_mod_reg(WKUP_MOD, CM_ICLKEN);
- fclk = cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
- cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_ICLKEN);
- cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_FCLKEN);
- prm_write_mod_reg(wkst, WKUP_MOD, PM_WKST);
- while (prm_read_mod_reg(WKUP_MOD, PM_WKST))
- cpu_relax();
- cm_write_mod_reg(iclk, WKUP_MOD, CM_ICLKEN);
- cm_write_mod_reg(fclk, WKUP_MOD, CM_FCLKEN);
- }
-
- /* CORE */
- wkst = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (wkst) {
- iclk = cm_read_mod_reg(CORE_MOD, CM_ICLKEN1);
- fclk = cm_read_mod_reg(CORE_MOD, CM_FCLKEN1);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_ICLKEN1);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_FCLKEN1);
- prm_write_mod_reg(wkst, CORE_MOD, PM_WKST1);
- while (prm_read_mod_reg(CORE_MOD, PM_WKST1))
- cpu_relax();
- cm_write_mod_reg(iclk, CORE_MOD, CM_ICLKEN1);
- cm_write_mod_reg(fclk, CORE_MOD, CM_FCLKEN1);
- }
- wkst = prm_read_mod_reg(CORE_MOD, OMAP3430ES2_PM_WKST3);
- if (wkst) {
- iclk = cm_read_mod_reg(CORE_MOD, CM_ICLKEN3);
- fclk = cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_ICLKEN3);
- cm_set_mod_reg_bits(wkst, CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- prm_write_mod_reg(wkst, CORE_MOD, OMAP3430ES2_PM_WKST3);
- while (prm_read_mod_reg(CORE_MOD, OMAP3430ES2_PM_WKST3))
- cpu_relax();
- cm_write_mod_reg(iclk, CORE_MOD, CM_ICLKEN3);
- cm_write_mod_reg(fclk, CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- }
-
- /* PER */
- wkst = prm_read_mod_reg(OMAP3430_PER_MOD, PM_WKST);
- if (wkst) {
- iclk = cm_read_mod_reg(OMAP3430_PER_MOD, CM_ICLKEN);
- fclk = cm_read_mod_reg(OMAP3430_PER_MOD, C
[PATCH 0/5] OMAP PM fixes for 2.6.32
These fixes are primarily for PRCM interrupt handler bugs and GPIO wakeup support. Jon Hunter (1): OMAP3: PM: Prevent hang in prcm_interrupt_handler Kevin Hilman (1): OMAP3: PM: Enable GPIO module-level wakeups Paul Walmsley (2): OMAP3: PM: PRCM interrupt: check MPUGRPSEL register OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts Vikram Pandita (1): OMAP3: PM: USBHOST: clear wakeup events on both hosts arch/arm/mach-omap2/pm34xx.c | 187 -- 1 files changed, 106 insertions(+), 81 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] OMAP3: RX51: support sleep indicator LEDs
On Fri, Oct 02, 2009 at 08:35:55AM -0700, Kevin Hilman wrote: > The sleep indicator LEDs can be enabled/disabled by toggling GPIO162. > Request this GPIO in RX51 board init, disable by default and expose > GPIO162 to userspace so LEDs can be toggled from userspace: Wouldn't this be better done using the LED class subsystem? > To enable: > > # echo 1 > /sys/class/gpio/gpio162/value > > To disable: > > # echo 0 > /sys/class/gpio/gpio162/value > > Signed-off-by: Kevin Hilman > --- J. -- 101 things you can't have too much of : 16 - Time. -- 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: RX51: support sleep indicator LEDs
Jonathan McDowell writes: > On Fri, Oct 02, 2009 at 08:35:55AM -0700, Kevin Hilman wrote: >> The sleep indicator LEDs can be enabled/disabled by toggling GPIO162. >> Request this GPIO in RX51 board init, disable by default and expose >> GPIO162 to userspace so LEDs can be toggled from userspace: > > Wouldn't this be better done using the LED class subsystem? No, these are HW controlled LEDs which blink based on whether the OMAP is hitting retention or OFF mode etc. The software has no control over the blinking of LEDs themselves. The GPIO simply enables them. Kevin >> To enable: >> >> # echo 1 > /sys/class/gpio/gpio162/value >> >> To disable: >> >> # echo 0 > /sys/class/gpio/gpio162/value >> >> Signed-off-by: Kevin Hilman >> --- > > J. > > -- > 101 things you can't have too much of : 16 - Time. -- 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] OMAP3: RX51: support sleep indicator LEDs
The sleep indicator LEDs can be enabled/disabled by toggling GPIO162.
Request this GPIO in RX51 board init, disable by default and expose
GPIO162 to userspace so LEDs can be toggled from userspace:
To enable:
# echo 1 > /sys/class/gpio/gpio162/value
To disable:
# echo 0 > /sys/class/gpio/gpio162/value
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/board-rx51.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index f9196c3..6ad44d8 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -31,6 +31,8 @@
#include
#include
+#define RX51_GPIO_SLEEP_IND 162
+
static struct omap_lcd_config rx51_lcd_config = {
.ctrl_name = "internal",
};
@@ -74,6 +76,11 @@ static void __init rx51_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_cfg_reg(H16_34XX_SDRC_CKE0);
omap_cfg_reg(H17_34XX_SDRC_CKE1);
+
+ if (!(gpio_request(RX51_GPIO_SLEEP_IND, "SLEEP_IND"))) {
+ gpio_direction_output(RX51_GPIO_SLEEP_IND, 0);
+ gpio_export(RX51_GPIO_SLEEP_IND, 1);
+ }
}
static void __init rx51_map_io(void)
--
1.6.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/2] OMAP3:PM:SR: SmartReflex Refactor Rev2.0
Nishanth Menon writes:
> Refactor the smart reflex implementation.
Unless there are major objections, I'd like to put Nishanth's SR
rework/refactor into the PM branch for broader testing and review.
This will likely happen early next week.
Kevin
> Original implementation summary:
> Kalle Jokiniemi (1):
> OMAP3: PM: SmartReflex driver integration
>
> Phil Carmody (2):
> OMAP3: PM: Don't do unnecessary searches in omap_sr_vdd*_autocomp_store
> OMAP3: PM: Early exit on invalid parameters
>
> Rajendra Nayak (10):
> OMAP3: SR: Fix init voltage on OPP change
> OMAP3: SR: Update VDD1/2 voltages at boot
> OMAP3: SR: Use sysclk for SR CLKLENGTH calc
> OMAP3: SR: Reset voltage level on SR disable
> OMAP3: SR: Replace printk's with pr_* calls
> OMAP3: SR: Remove redundant defines
> OMAP3: SR: Replace (0x1 << n) with BIT(n)
> OMAP3: SR: Fix SR driver to check for omap-pm return values
> OMAP3: PM: Put optimal SMPS stabilization delay
> OMAP3: SR: Wait for VP idle before a VP disable
>
> Roger Quadros (4):
> OMAP3: PM: Fix Smartreflex when used with PM_NOOP layer
> OMAP3: PM: Make Smartreflex driver independent of SRF
> OMAP3: PM: Do not Enable SmartReflex if OPP tables not defined
> OMAP3: PM: Smartreflex: Fix VDD2 OPP determining logic
>
> Teerth Reddy (1):
> OMAP3: SR: Replace SR_PASS/FAIL,SR_TRUE/FALSE
>
> This patch introduces the following changes in addition to refactoring
> the implementation:
> a) changes the DVFS transition sequences from:
> freq, voltage(SR+vp) and viceversa
> TO:
> disable_vp,SR; freq, voltage(SR+vp) and viceversa; enable_vp,SR
> [NOTE: sequence change for disable path - was sr_dis,vp_dis]
> This change prevents spikes and unexpected voltage changes
> as a result of SR being left enabled at wrong times
> b) Major rewrite of smartreflex.c to do the following:
>
> 1) Support VCbypass style of voltage configuration as optional
>introduce and support forceupdate default as recommended by
>OMAP3430 TRM.
> 2) Centralize operations to allow for simpler and predictable code
>flows
> 3) Modification to SR configured values to be inline with
>silicon characterization results
> 4) cleanup of header
> 5) Introduce a few omap_pmic weak functions which can be overridden
> by platforms implementing PMICs which are different from TWL4030
> derivatives
>
> c) Fix ERRCONFIG access to prevent unplanned cleanup of interrupt
> status registers - this is done using a interrupt status mask
> d) Test nvalues reduced to few lines of code with preconfigured values
> as well as added multiple levels of warning to keep user informed
> e) Use a singular mutex lock at smartreflex level to isolate access b/w
> dvfs access/cpu_idle or userspace control
> f) Setup h/w timeout based on cpu sysclk and not hardcoded values
>
> Tested on:
> SDP3430 with test N values and with ES3.1 silicon
>
> TODO:
> a) Handle scenarios for multiple OMAP variants with differing
>SR capabilities (e.g. varying OPP levels - e.g. 3630, 4430 etc..)
> b) Handling OMAP variants with different tuning values
> c) Handling different SR capable PMIC with different tuning values
> d) A proper handling of locking mechanism b/w dvfs and userspace access of
>sr[x]_vddautocomp
> e) A more robust error handling
> f) using SR on larger number of boards and any tuning parameters
>which may be needed additionally (HS/FS I2C4 ops etc..)
> g) Wider testing and and bug fixes
>
> This also incorporates some of the ideas from discussions with Guilhem
>
> Signed-off-by: Nishanth Menon
> Cc: Rajendra Nayak
> Cc: Roger Quadros
> Cc: Kalle Jokiniemi
> Cc: Teerth Reddy
> Cc: Kevin Hilman
> Cc: Paul Walmsley
> Cc: Högander Jouni
> Cc: Imberton Guilhem
> Cc: Mike Chan
> ---
> arch/arm/mach-omap2/resource34xx.c |8 +-
> arch/arm/mach-omap2/smartreflex.c | 1346
>
> arch/arm/mach-omap2/smartreflex.h | 249 +++
> arch/arm/plat-omap/Kconfig | 18 +-
> 4 files changed, 1617 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/mach-omap2/smartreflex.c
> create mode 100644 arch/arm/mach-omap2/smartreflex.h
>
> diff --git a/arch/arm/mach-omap2/resource34xx.c
> b/arch/arm/mach-omap2/resource34xx.c
> index 1693e9b..6710c86 100644
> --- a/arch/arm/mach-omap2/resource34xx.c
> +++ b/arch/arm/mach-omap2/resource34xx.c
> @@ -287,17 +287,23 @@ static int program_opp(int res, struct omap_opp *opp,
> int target_level,
> else
> raise = 0;
>
> +#ifdef CONFIG_OMAP_SMARTREFLEX
> + sr_vp_disable_both(t_opp, c_opp);
> +#endif
> for (i = 0; i < 2; i++) {
> if (i == raise)
> ret = program_opp_freq(res, target_level,
> current_level);
> #ifdef CONFIG_OMAP_SMARTREFLEX
> else
> - sr_voltagescale_v
Re: [PATCH] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.
Tomi Valkeinen writes: > On Thu, 2009-10-01 at 18:19 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen writes: > >> > So is there an API to change that value in resource34xx.h dynamically, >> > depending on what DSS block is in use? Or am I still missing something >> > here? =) >> >> You're right, we currently do not have a way to dynamically update >> this table and we should for completeness. > > Ok. This was what I was after in the first place, but didn't know how to > form the question properly =). > >> Excuse my ignorance of the DSS/DSI/etc., but if a DSI periperal is use >> that requires a continual DSI clock then shouldn't the driver always >> keep the DSI clock enabled (iow, it should never call clk_disable()). >> If a clock is left enabled, even if OFF-mode is targetted for that >> powerdomain, it will not reach OFF because the clockdomain is active. > > Well, this is quite theoretical, and I agree that let's just forget > about this and worry it if such a case ever emerges. But here's what I > was thinking: > > OMAP's DSI block can be clocked by OMAP's normal clocks (DPLL4, if I > recall right), which are handled by clk_enable/disable. But the clock > signal that goes over DSI bus to the peripheral is generated by the DSI > PLL, which is a DSS internal PLL not handled by clk_enable/disable. DSI > PLL usually gets its reference clock from sysclock. > > For example, we have these displays that have their own framebuffer, and > they independently update the actual panel from their internal > framebuffer, while OMAP can be totally sleeping. Currently these > displays generate their own clock for this internal updating. > > There's an option in the OMAP DSI block to set the DSI clock output to > always on (versus DSI clock output enabled automatically when there's > data to transfer over DSI bus). And the reasoning for this option is > that some peripherals may require continuous clock to operate. So we > could have a display that uses DSI clock for staying alive, doing some > internal work like refreshing the panel. OK, I understand the need to keep these clocks going in some cases. Based on how some of the other HW modules work, I would assume that if DSI is active (generating clocks), it would never allow and idle transition so it wouldn't hit off mode. I guess we'd need to dig into the DSS/DSI docs to see if that's true. But the basic model for going into RET or OFF is that the PRCM uses an idle protocol to ask each module if it can idle. Here's a simplified summary: First, PRCM sends and idle request. If the module is idle, it responsds with an idle ack and the PRCM is then free to disable its clocks etc. But, if the module doesn't ack, clocks will not be cut and the module will stay active and prevent full-chip RET/OFF. So, following this model, I assume that the DSS would never idle ack if one of its sub-modules, in this case DSI, is active. That would need to be verified in the docs. >> In the DSS git, the master branch seems to be based at 2.6.31-rc5. Do >> you have an updated version against 2.6.32-rc1 or omap/master? > > Which tree are you referring to? My gitorious tree contains the latest > version that I've been pushing to mainstream. > > git://gitorious.org/linux-omap-dss2/linux.git (master branch) > > It's based on the mainstream tree, but I think it should apply to l-o > easily. I can also make l-o based branch if the conflicts are bad. Hmm, the git tree I was looking at was from bat.org. I'll update to this one and have a look. 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 0/2] twl4030 power support for 3430SDP
On 09 Oct 01, Kevin Hilman wrote: > Amit Kucheria writes: > > > On 09 Oct 01, Kevin Hilman wrote: > >> I've been carrying these in the PM branch, but now that twl4030 power > >> support is in mainline, these can be queued for 2.6.33. > >> > >> Kevin Hilman (1): > >> OMAP3: PM: 3430SDP: add initial twl4030 power scripts > >> > >> Rajendra Nayak (1): > >> OMAP3: PM: 3430SDP: Update twl4030 power scripts and device groups > >> > >> arch/arm/mach-omap2/board-3430sdp.c | 93 > >> ++- > >> 1 files changed, 91 insertions(+), 2 deletions(-) > >> > > > > Hi Kevin, > > > > Do you want to wait until I push patches that modify the way the scripts are > > loaded in memory? (they now allow overlapping scripts to work around space > > constraints) > > > > Also we now have very simplified scripts that use broadcast messages. These > > might still need to be tweaked for the various boards though. It works on > > the > > RX51. > > Well, I don't *want* to wait because that means I would have to rework > these patches. :) > > But it sounds waiting is the right thing. How close are you to having > the new scripting stuff ready? Should we put it into the PM branch in > the meantime so it can get some testing on other boards than RX51? > > Kevin Kevin, I take back my objections to these patches. On studying the current state of the scripts it looks like the feature allowing overlapping scripts to work around space constraints might no longer be necessary after the conversion of the scripts to use broadcast messages instead of the singular ones. I'll push the optimised scripts shortly. Acked-by: Amit Kucheria -- - Amit Kucheria, Kernel Developer, Verdurent - -- 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/2] twl4030 power support for 3430SDP
Amit Kucheria writes: > On 09 Oct 01, Kevin Hilman wrote: >> Amit Kucheria writes: >> >> > On 09 Oct 01, Kevin Hilman wrote: >> >> I've been carrying these in the PM branch, but now that twl4030 power >> >> support is in mainline, these can be queued for 2.6.33. >> >> >> >> Kevin Hilman (1): >> >> OMAP3: PM: 3430SDP: add initial twl4030 power scripts >> >> >> >> Rajendra Nayak (1): >> >> OMAP3: PM: 3430SDP: Update twl4030 power scripts and device groups >> >> >> >> arch/arm/mach-omap2/board-3430sdp.c | 93 >> >> ++- >> >> 1 files changed, 91 insertions(+), 2 deletions(-) >> >> >> > >> > Hi Kevin, >> > >> > Do you want to wait until I push patches that modify the way the scripts >> > are >> > loaded in memory? (they now allow overlapping scripts to work around space >> > constraints) >> > >> > Also we now have very simplified scripts that use broadcast messages. These >> > might still need to be tweaked for the various boards though. It works on >> > the >> > RX51. >> >> Well, I don't *want* to wait because that means I would have to rework >> these patches. :) >> >> But it sounds waiting is the right thing. How close are you to having >> the new scripting stuff ready? Should we put it into the PM branch in >> the meantime so it can get some testing on other boards than RX51? > > I haven't started looking at it yet. It will have to wait until w42 though. > > I guess you can push your patches to the PM branch and revert them at a later > time when I have the changes ready? This series is already in the PM branch, and has been for a while. I've been waiting for the twl4030 power code to hit mainline before submitting them. If you think you'll get the new script stuff done in the next few weeks, I'll wait. 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] OMAP: I2C: Add mpu wake up latency constraint in i2c
On Fri, 2009-10-02 at 16:11 +0300, Jokiniemi Kalle wrote:
> While waiting for completion of the i2c transfer, the
> MPU could hit OFF mode and cause several msecs of
> delay that made i2c transfers fail more often. The
> extra delays and subsequent re-trys cause i2c clocks
> to be active more often. This has also an negative
> effect on power consumption.
>
> Added a constraint that allows MPU to wake up in few
> hundred usecs, which is roughly the average i2c wait
> period.
>
> The constraint function is passed as platform data from
> plat-omap/i2c.c. Currently there is implementation for
> omap3 constraint. Future omap platforms should implement
> their own functions, and pass them instead.
So this is the new version of setting mpu wakeup constraints in i2c
driver. Only build tested.
Kevin, could you run some tests on beagle or some other. I could not get
my zImage to work on RX-51 (tried rx51_defconfig and omap3_pm_defconfig
builds).
Applies on top of pm-branch.
- Kalle
>
> Signed-off-by: Kalle Jokiniemi
> ---
> arch/arm/plat-omap/i2c.c | 54 +++-
> drivers/i2c/busses/i2c-omap.c | 19 +++---
> include/linux/i2c-omap.h |9 +++
> 3 files changed, 66 insertions(+), 16 deletions(-)
> create mode 100644 include/linux/i2c-omap.h
>
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index 8b84839..4ab7a92 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -26,8 +26,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
>
> #define OMAP_I2C_SIZE0x3f
> #define OMAP1_I2C_BASE 0xfffb3800
> @@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
> }, \
> }
>
> -static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
> +static struct omap_i2c_bus_platform_data
> i2c_pdata[ARRAY_SIZE(i2c_resources)];
> static struct platform_device omap_i2c_devices[] = {
> - I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
> + I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
> #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
> - I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
> + I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
> #endif
> #if defined(CONFIG_ARCH_OMAP34XX)
> - I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
> + I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
> #endif
> };
>
> @@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
>
> #define OMAP_I2C_CMDLINE_SETUP (BIT(31))
>
> +/**
> + * omap3_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
> + * @dev: i2c bus device pointer
> + * @set: set or clear constraints
> + *
> + * When waiting for completion of a i2c transfer, we need to set a wake up
> + * latency constraint for the MPU. This is to ensure quick enough wakeup from
> + * idle, when transfer completes. For OMAP3 platform.
> + */
> +#ifdef CONFIG_ARCH_OMAP34XX
> +static void omap3_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
> +{
> + omap_pm_set_max_mpu_wakeup_lat(dev, set ? 500 : -1);
> +}
> +#endif
> +
> +static void __init omap_set_i2c_constraint_func(
> + struct omap_i2c_bus_platform_data *pd)
> +{
> + if (cpu_is_omap34xx())
> + pd->set_mpu_wkup_lat = omap3_i2c_set_wfc_mpu_wkup_lat;
> + else
> + pd->set_mpu_wkup_lat = NULL;
> +}
> +
> static void __init omap_i2c_mux_pins(int bus)
> {
> int scl, sda;
> @@ -180,8 +207,8 @@ static int __init omap_i2c_bus_setup(char *str)
> get_options(str, 3, ints);
> if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
> return 0;
> - i2c_rate[ints[1] - 1] = ints[2];
> - i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
> + i2c_pdata[ints[1] - 1].clkrate = ints[2];
> + i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
>
> return 1;
> }
> @@ -195,9 +222,10 @@ static int __init omap_register_i2c_bus_cmdline(void)
> {
> int i, err = 0;
>
> - for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
> - if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
> - i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
> + for (i = 0; i < ARRAY_SIZE(i2c_pdata); i++)
> + if (i2c_pdata[i].clkrate & OMAP_I2C_CMDLINE_SETUP) {
> + i2c_pdata[i].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
> + omap_set_i2c_constraint_func(&i2c_pdata[i]);
> err = omap_i2c_add_bus(i + 1);
> if (err)
> goto out;
> @@ -231,9 +259,11 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
> return err;
> }
>
> - if (!i2c_rate[bus_id - 1])
> - i2c_rate[bus_id - 1] = clkrate;
> - i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
> + if (
[PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Added a constraint that allows MPU to wake up in few
hundred usecs, which is roughly the average i2c wait
period.
The constraint function is passed as platform data from
plat-omap/i2c.c. Currently there is implementation for
omap3 constraint. Future omap platforms should implement
their own functions, and pass them instead.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/plat-omap/i2c.c | 54 +++-
drivers/i2c/busses/i2c-omap.c | 19 +++---
include/linux/i2c-omap.h |9 +++
3 files changed, 66 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 8b84839..4ab7a92 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,8 +26,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
#endif
};
@@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+/**
+ * omap3_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev: i2c bus device pointer
+ * @set: set or clear constraints
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup from
+ * idle, when transfer completes. For OMAP3 platform.
+ */
+#ifdef CONFIG_ARCH_OMAP34XX
+static void omap3_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, set ? 500 : -1);
+}
+#endif
+
+static void __init omap_set_i2c_constraint_func(
+ struct omap_i2c_bus_platform_data *pd)
+{
+ if (cpu_is_omap34xx())
+ pd->set_mpu_wkup_lat = omap3_i2c_set_wfc_mpu_wkup_lat;
+ else
+ pd->set_mpu_wkup_lat = NULL;
+}
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -180,8 +207,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -195,9 +222,10 @@ static int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
- for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
- if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
- i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
+ for (i = 0; i < ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate & OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
+ omap_set_i2c_constraint_func(&i2c_pdata[i]);
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -231,9 +259,11 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- if (!i2c_rate[bus_id - 1])
- i2c_rate[bus_id - 1] = clkrate;
- i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
+ if (!i2c_pdata[bus_id - 1].clkrate)
+ i2c_pdata[bus_id - 1].clkrate = clkrate;
+
+ omap_set_i2c_constraint_func(&i2c_pdata[bus_id - 1]);
+ i2c_pdata[bus_id - 1].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
return omap_i2c_add_bus(bus_id);
}
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 75bf3ad..168623f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
/* I2C controller rev
Re: [PATCH v2] omap_hsmmc: Add missing probe handler hook
Quadros Roger (EXT-Teleca/Helsinki) wrote:
The missing probe handler hook will never probe the driver. Add it back.
Fixes broken MMC on OMAP.
We use platform_driver_probe() API since omap_hsmmc is not a hot-pluggable
device.
Signed-off-by: Roger Quadros
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4487cc0..0aecaae 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2013,7 +2013,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_register(&omap_hsmmc_driver);
+ return platform_driver_probe(&omap_hsmmc_driver, omap_hsmmc_probe);
}
static void __exit omap_hsmmc_cleanup(void)
Tony,
Since you've already applied my earlier patch (v1), you may used the attached
version instead. The attached patch will apply on current head with commit id
30e0c4a059d83886690381222e14f35540c7f017
cheers,
-roger
0001-omap_hsmmc-Use-platform_driver_probe-instead-of-p.patch.gz
Description: GNU Zip compressed data
[PATCH v2] omap_hsmmc: Add missing probe handler hook
The missing probe handler hook will never probe the driver. Add it back.
Fixes broken MMC on OMAP.
We use platform_driver_probe() API since omap_hsmmc is not a hot-pluggable
device.
Signed-off-by: Roger Quadros
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4487cc0..0aecaae 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2013,7 +2013,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_register(&omap_hsmmc_driver);
+ return platform_driver_probe(&omap_hsmmc_driver, omap_hsmmc_probe);
}
static void __exit omap_hsmmc_cleanup(void)
--
1.6.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] omap_hsmmc: Add missing probe handler hook to platform driver data
ext Rok Markovič wrote:
This is not the correct way to do it. There was some conflict during merge in
init function. Correct patch should look like this:
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2013,7 +2013,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_register(&omap_hsmmc_driver);
+ return platform_driver_probe(&omap_hsmmc_driver, omap_hsmmc_probe);
}
static void __exit omap_hsmmc_cleanup(void)
Rok
Oh yes. Since omap_hsmmc is not a hot-pluggable device.
Will send a v2.
Thanks Rok, for pointing this out.
Dne četrtek 1. oktobra 2009 ob 16:39:13 ste napisali:
The missing probe handler hook will never probe the driver. Add it back.
Fixes broken MMC on OMAP.
Signed-off-by: Roger Quadros
---
drivers/mmc/host/omap_hsmmc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4487cc0..26abe1e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2001,6 +2001,7 @@ clk_en_err:
#endif
static struct platform_driver omap_hsmmc_driver = {
+ .probe = omap_hsmmc_probe,
.remove = omap_hsmmc_remove,
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] OMAP: I2C: Add mpu wake up latency constraint in i2c
On Thu, 2009-10-01 at 14:41 +0300, Aaro Koskinen wrote: > Hello, > > Kalle Jokiniemi wrote: > > On Wed, 2009-09-30 at 19:36 +0300, Kevin Hilman wrote: > >> Seems like the latency value should also be (optionally) passed in > >> pdata so this can be experimented with per-platform. > > > > Well, it kind of is already, since we pass the function that sets the > > latency from platform code. And that function has the latency > > hard-coded. > > Paul Walmsley suggested earlier that the latency value should be > calculated from bus specific parameters: > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12358.html Yes, this is a good idea in theory, but the reality of wake-up latencies kind-a kill this one. Wake-up from even C1 (MPU INA, CORE ON) takes ~130us on fastest OPP. And when you add 70us of sleep transition into that, you get 200us at minimum. So what it would require to actually get latencies that Paul calculated, is a new C-state that bypasses the idle loop completely. This would essentially keep cpu in busy loop while waiting for interrupt (or i2c completion in this case). In pm-sense, it seems unwise. For us, the 500us constraint seems to work quite nicely. It removes the problems we had with i2c transfers timing out with off mode, and restores average transfer times (from clk_enable to clk_disable) to few hundred us (that were observed with retention). But it's open software, people are free to experiment :) - Kalle > > A. -- 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] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.
On Thu, 2009-10-01 at 18:19 +0200, ext Kevin Hilman wrote: > Tomi Valkeinen writes: > > So is there an API to change that value in resource34xx.h dynamically, > > depending on what DSS block is in use? Or am I still missing something > > here? =) > > You're right, we currently do not have a way to dynamically update > this table and we should for completeness. Ok. This was what I was after in the first place, but didn't know how to form the question properly =). > Excuse my ignorance of the DSS/DSI/etc., but if a DSI periperal is use > that requires a continual DSI clock then shouldn't the driver always > keep the DSI clock enabled (iow, it should never call clk_disable()). > If a clock is left enabled, even if OFF-mode is targetted for that > powerdomain, it will not reach OFF because the clockdomain is active. Well, this is quite theoretical, and I agree that let's just forget about this and worry it if such a case ever emerges. But here's what I was thinking: OMAP's DSI block can be clocked by OMAP's normal clocks (DPLL4, if I recall right), which are handled by clk_enable/disable. But the clock signal that goes over DSI bus to the peripheral is generated by the DSI PLL, which is a DSS internal PLL not handled by clk_enable/disable. DSI PLL usually gets its reference clock from sysclock. For example, we have these displays that have their own framebuffer, and they independently update the actual panel from their internal framebuffer, while OMAP can be totally sleeping. Currently these displays generate their own clock for this internal updating. There's an option in the OMAP DSI block to set the DSI clock output to always on (versus DSI clock output enabled automatically when there's data to transfer over DSI bus). And the reasoning for this option is that some peripherals may require continuous clock to operate. So we could have a display that uses DSI clock for staying alive, doing some internal work like refreshing the panel. > In the DSS git, the master branch seems to be based at 2.6.31-rc5. Do > you have an updated version against 2.6.32-rc1 or omap/master? Which tree are you referring to? My gitorious tree contains the latest version that I've been pushing to mainstream. git://gitorious.org/linux-omap-dss2/linux.git (master branch) It's based on the mainstream tree, but I think it should apply to l-o easily. I can also make l-o based branch if the conflicts are bad. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap iovmm: fix incorrect spelling
From: Hiroshi DOYU
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index d40f7c8..b1278ea 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -47,7 +47,7 @@
* 'va': mpu virtual address
*
* 'c':contiguous memory area
- * 'd':dicontiguous memory area
+ * 'd':discontiguous memory area
* 'a':anonymous memory allocation
* '()': optional feature
*
@@ -397,7 +397,7 @@ static inline void sgtable_drain_vmalloc(struct sg_table
*sgt)
{
/*
* Actually this is not necessary at all, just exists for
-* consistency of the code readibility.
+* consistency of the code readability.
*/
BUG_ON(!sgt);
}
@@ -431,7 +431,7 @@ static inline void sgtable_drain_kmalloc(struct sg_table
*sgt)
{
/*
* Actually this is not necessary at all, just exists for
-* consistency of the code readibility
+* consistency of the code readability
*/
BUG_ON(!sgt);
}
--
1.6.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 1/2] omap iovmm: remove cache flush operation
From: Hiroshi DOYU Cache flush operation is handled in the upper client layer and iovmm modules doesn't have to care about it. This patch will improve some performance with current camera isp driver. Signed-off-by: Hiroshi DOYU --- arch/arm/plat-omap/iovmm.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 57f7122..d40f7c8 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -391,7 +391,6 @@ static void sgtable_fill_vmalloc(struct sg_table *sgt, void *_va) } va_end = _va + PAGE_SIZE * i; - flush_cache_vmap((unsigned long)_va, (unsigned long)va_end); } static inline void sgtable_drain_vmalloc(struct sg_table *sgt) @@ -426,8 +425,6 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len) len -= bytes; } BUG_ON(len); - - clean_dcache_area(va, len); } static inline void sgtable_drain_kmalloc(struct sg_table *sgt) -- 1.6.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
