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 santosh.shilim...@ti.com 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 santosh.shilim...@ti.com
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 santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
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
RE: [RFC][PATCH] omapfb: Condition mutex acquisition
On Tue, 2009-09-29 at 20:26 +0200, ext Hiremath, Vaibhav wrote: Tomi, Don't you think we should also make use of mm_lock in new OMAP2 Fbdev driver, to be more specific and safer side? Hmm yes, I think we should. One more thing to the TODO list =) Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] omapfb: Condition mutex acquisition
On Wed, 2009-09-30 at 02:53 +0200, ext Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@nokia.com [090929 07:54]: On Tue, 2009-09-29 at 16:34 +0200, ext Aguirre Rodriguez, Sergio Alberto wrote: From: Tomi Valkeinen [tomi.valkei...@nokia.com] Sent: Tuesday, September 29, 2009 9:22 AM On Tue, 2009-09-29 at 16:14 +0200, ext Aguirre Rodriguez, Sergio Alberto wrote: From: Sergio Aguirre saagui...@ti.com Acquiring mutex before framebuffer registration doesn't make sense, As there's no danger of external access to the memory related fields. What problem does this patch solve? It makes the code more complex. Tomi, Thanks for your time. The problem was that, during platform driver registration, this sequence was executed: - omapfb_probe - omapfb_do_probe - planes_init - fbinfo_init - set_fb_fix ... - register_framebuffer And then, inside that function, an attempt of acquiring a mutex failed, because it wasn't initialized before trying it: mutex_lock(fbi-mm_lock); It is actually initialized later in omapfb_do_probe in register_framebuffer call. So, how is the best to solve this then? Oh, I wasn't implying that there's something wrong with the fix, I just didn't know what it was fixing =). Looks like a valid fix to me. Tomi Imre, do you want me to add this to the omap-fixes queue, or are you planning to send other fixes too? If you want me to add it, please reply with your ack. I'll added it into omap-fixes-testing branch for now so we can get the omaps booted. I don't know if Imre wants to handle this (probably not =), but I would rather concentrate on DSS2 patches. I have enough of them already, and my progress in upstreaming them seems to be... slow... =). So if you can take any minor old-omapfb patches to omap-fixes queue, it'd be great. Acked-by: Tomi Valkeinen tomi.valkei...@nokia.com Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] OMAP: DSS2: Intro
Hi, Andrew, do you have time to check out the DSS2 driver? Or suggestions how should I proceed. I rebased DSS2 on top of today's linux-tree, and there were no conflicts, so the posted patches should apply. But the rebased tree is also available in master branch at git://gitorious.org/linux-omap-dss2/linux.git Tomi On Thu, 2009-09-24 at 13:56 +0200, Valkeinen Tomi (Nokia-D/Helsinki) wrote: This patch set implement new display subsystem driver (DSS2) and omapfb driver for OMAP2/3. The patches have been reviewed on linux-omap and linux-fbdev-devel mailing lists. The patches can also be found from http://gitorious.org/linux-omap-dss2/linux The patches include DSS documentation patch that includes more instructions for module parameters, sysfs files etc. The patches enable DSS2 for OMAP3430 SDP board and support for other boards can be sent after the DSS2 has been merged. DSS2 is used in various boards, for example Nokia N900, Beagle Board and Overo. I don't currently have any OMAP2 board to test DSS2, but it has worked on OMAP2 and the possible fixes needed should be minimal. OMAP1 is not supported, and so the old DSS needs to be used on OMAP1 boards. DSS2 is partly based on the old omapfb driver by Imre Deak, and Imre has also contributed to DSS2 quite a bit. Ville Syrjälä has been contributing to scaling and tv-out work. Also some contributions have been made by Hardik Shah, Vaibhav Hiremath, and perhaps some others that I have forgotten =). --- Changes in v4: - Rebased on latest linux tree - Add maintainers Changes in v3: - Rebased on mainstream linux - Remove Beagle and Overo board changes Changes in v2: - Split the commits more to make them smaller - Print error if fclk is too low for scaling - Indent SDP, Beagle, Overo board files - DSI: return -EIO instead of -1 - VRFB: Move to drivers/video/omap2/ - VRAM: Move to drivers/video/omap2/ - VRFB: use omap2_sms_write_*() functions instead of omap_writel - SDI: Remove custom pinmuxing. Will be added later properly. - VENC: indentation changes - Add Taal DSI panel driver --- [PATCH 01/19] OMAP2: Add funcs for writing SMS_ROT_* registers [PATCH 02/19] OMAP: OMAPFB: split omapfb.h [PATCH 03/19] OMAP: OMAPFB: add omapdss device [PATCH 04/19] OMAP: Add VRAM manager [PATCH 05/19] OMAP: Add support for VRFB rotation engine [PATCH 06/19] OMAP: DSS2: Documentation for DSS2 [PATCH 07/19] OMAP: DSS2: Display Subsystem Driver core [PATCH 08/19] OMAP: DSS2: Add more core files [PATCH 09/19] OMAP: DSS2: DISPC [PATCH 10/19] OMAP: DSS2: DPI driver [PATCH 11/19] OMAP: DSS2: Video encoder driver [PATCH 12/19] OMAP: DSS2: RFBI driver [PATCH 13/19] OMAP: DSS2: SDI driver [PATCH 14/19] OMAP: DSS2: DSI driver [PATCH 15/19] OMAP: DSS2: omapfb driver [PATCH 16/19] OMAP: DSS2: Add DPI panel drivers [PATCH 17/19] OMAP: DSS2: Taal DSI command mode panel driver [PATCH 18/19] OMAP: SDP: Enable DSS2 for OMAP3 SDP board [PATCH 19/19] MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer --- Documentation/arm/OMAP/DSS | 317 ++ MAINTAINERS| 17 + arch/arm/configs/omap_3430sdp_defconfig| 29 +- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap2/board-3430sdp.c| 167 +- arch/arm/mach-omap2/clock24xx.c|8 +- arch/arm/mach-omap2/clock34xx.c| 14 +- arch/arm/mach-omap2/io.c |4 +- arch/arm/mach-omap2/sdrc.c | 16 + arch/arm/plat-omap/fb.c| 41 +- arch/arm/plat-omap/include/mach/display.h | 540 +++ arch/arm/plat-omap/include/mach/omapfb.h | 398 --- arch/arm/plat-omap/include/mach/sdrc.h |9 +- arch/arm/plat-omap/include/mach/vram.h | 63 + arch/arm/plat-omap/include/mach/vrfb.h | 46 + arch/arm/plat-omap/sram.c |8 + drivers/video/Kconfig |1 + drivers/video/Makefile |1 + drivers/video/omap/Kconfig |5 +- drivers/video/omap/blizzard.c |2 +- drivers/video/omap/dispc.c | 21 +- drivers/video/omap/hwa742.c|2 +- drivers/video/omap/lcd_2430sdp.c |3 +- drivers/video/omap/lcd_ams_delta.c |3 +- drivers/video/omap/lcd_apollon.c |3 +- drivers/video/omap/lcd_h3.c|2 +- drivers/video/omap/lcd_h4.c|2 +- drivers/video/omap/lcd_inn1510.c |2 +- drivers/video/omap/lcd_inn1610.c |2 +- drivers/video/omap/lcd_ldp.c |3 +- drivers/video/omap/lcd_mipid.c |
Re: [alsa-devel] [PATCHv2 5/7] ASoC: TWL6030: Add support for low-power mode
On Tue, Sep 29, 2009 at 10:02:49PM -0500, Lopez Cruz, Misael wrote: I think I got confused with what to do in set_sysclk and set_pll. In my current approach: - set_sysclk takes care of setting corresponding clk source: lppll or hppll. But it also disables the pll not in use (i.e. if lppll is set, then disable hppll) - set_pll takes care of setting pll div for lppll (which is meant to receive 32k clk) and configure hppll for any of the supported freq_in (12, 19.2, 26, 38.4 MHz). Because only after this point I know the value of sysclk, the constraints are set here. Is it fine? For lppll the sysclk is set to requested freq_out (if div value is in the valid range) and for hppll it's always 19.2 and it's the only clk rate support by that pll. Hrm. Is it actually worth having manual configuration of the PLL (beyond selection of the PLL to use), or could the driver figure out the required output frequency for lppll? Either way is fine from an ASoC point of view, it's just that if the driver can figure the configuration out for itself that makes it a little easier to use. In any case... In contrast, in wm8988 the sysclk and contraints are set directly in set_sysclk. Note that they're actually passed to ALSA when the substreams are opened - all that wm8988 is doing in set_sysclk() is recording the constraints that it will use next time that happens. Up until the point where you tell ALSA about the constraints you can do pretty much whatever you like so long as it makes sense, so what you say above is probably fine. For the wm8988 there's no PLL so once the input clock is known there's nothing more to do for 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] omapfb: Condition mutex acquisition
Hi, On Wed, Sep 30, 2009 at 02:53:10AM +0200, ext Tony Lindgren wrote: [...] Tomi Imre, do you want me to add this to the omap-fixes queue, or are you planning to send other fixes too? If you want me to add it, please reply with your ack. I'll added it into omap-fixes-testing branch for now so we can get the omaps booted. Acked-by: Imre Deak imre.d...@nokia.com There are no other patches for the DSS1 driver, so it'd be good if you could just apply it to omap-fixes. --Imre -- 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] omapfb: Condition mutex acquisition
From: Sergio Aguirre saagui...@ti.com
This fixes a bug introduced by this commit ID:
commit 537a1bf059fa312355696fa6db80726e655e7f17
Author: Krzysztof Helt krzysztof...@wp.pl
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 saagui...@ti.com
Acked-by: Tomi Valkeinen tomi.valkei...@nokia.com
Acked-by: Imre Deak imre.d...@nokia.com
---
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)
--
1.6.0.4
0001-omapfb-Condition-mutex-acquisition.patch
Description: 0001-omapfb-Condition-mutex-acquisition.patch
RE: [PATCH] omap: Fix incorrect 730 vs 850 detection, v2 (Re: Patch missing in 2.6.32-rc1)
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, September 30, 2009 6:02 AM To: Alistair Buxton Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: [PATCH] omap: Fix incorrect 730 vs 850 detection, v2 (Re: Patch missing in 2.6.32-rc1) * Alistair Buxton a.j.bux...@gmail.com [090929 16:52]: 2009/9/29 Tony Lindgren t...@atomide.com: * Premi, Sanjeev pr...@ti.com [090929 04:34]: Hi Tony, Can you push this patch to 2.6.32-rc1? 7a8d53a0: arch: arm: omap: terminate ifndef I was unable to refresh my patches against this baseline. OR, is it okay if I re-submit against the 'master'. Sorry, I was meaning to look where the mismatch really came from but forgot. Looks like adding omap850 support added an #else without removing the #endif above it, and also removed another #endif in commit ae302f40061235f6bc58ae9ba02aa849d60223b5. The #else immediately after the removed #endif needs to go as well, because the block that the #endif(s) belongs to already has an #else. That means the bug not only caused everything after the extra #endif to have no multiple inclusion protection (causing the redefinitions), but the extra #else also caused cpu_is_omap850() to be true only when cpu.h was included twice. Ah, right! So we're back to http://patchwork.kernel.org/patch/42292/ and we also need to add back the missing #endif to the end of file file. Here's an updated version of 42292, hopefully this will do the trick. [sp] Tested working fine for me. 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] input: fix rx51 board keymap
The original driver was written with the KEY() macro defined as (col, row)
instead of (row, col) as defined by the matrix keypad infrastructure. So the
keymap was defined accordingly.
Since the driver that was merged upstream uses the matrix keypad
infrastructure, modify the keymap accordingly.
While we are at it, fix the comments in twl4030.h and define PERSISTENT_KEY as
(r,c) instead of (c, r)
Tested on a RX51 (N900) device.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Cc: Tony Lindgren t...@atomide.com
Cc: Lauri Leukkunen lauri.leukku...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 78 +-
include/linux/i2c/twl4030.h |6 +-
2 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b45ad31..c1af532 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -38,49 +38,49 @@
static int board_keymap[] = {
KEY(0, 0, KEY_Q),
- KEY(0, 1, KEY_W),
- KEY(0, 2, KEY_E),
- KEY(0, 3, KEY_R),
- KEY(0, 4, KEY_T),
- KEY(0, 5, KEY_Y),
- KEY(0, 6, KEY_U),
- KEY(0, 7, KEY_I),
- KEY(1, 0, KEY_O),
+ KEY(0, 1, KEY_O),
+ KEY(0, 2, KEY_P),
+ KEY(0, 3, KEY_COMMA),
+ KEY(0, 4, KEY_BACKSPACE),
+ KEY(0, 6, KEY_A),
+ KEY(0, 7, KEY_S),
+ KEY(1, 0, KEY_W),
KEY(1, 1, KEY_D),
- KEY(1, 2, KEY_DOT),
- KEY(1, 3, KEY_V),
- KEY(1, 4, KEY_DOWN),
- KEY(2, 0, KEY_P),
- KEY(2, 1, KEY_F),
+ KEY(1, 2, KEY_F),
+ KEY(1, 3, KEY_G),
+ KEY(1, 4, KEY_H),
+ KEY(1, 5, KEY_J),
+ KEY(1, 6, KEY_K),
+ KEY(1, 7, KEY_L),
+ KEY(2, 0, KEY_E),
+ KEY(2, 1, KEY_DOT),
KEY(2, 2, KEY_UP),
- KEY(2, 3, KEY_B),
- KEY(2, 4, KEY_RIGHT),
- KEY(3, 0, KEY_COMMA),
- KEY(3, 1, KEY_G),
- KEY(3, 2, KEY_ENTER),
+ KEY(2, 3, KEY_ENTER),
+ KEY(2, 5, KEY_Z),
+ KEY(2, 6, KEY_X),
+ KEY(2, 7, KEY_C),
+ KEY(3, 0, KEY_R),
+ KEY(3, 1, KEY_V),
+ KEY(3, 2, KEY_B),
KEY(3, 3, KEY_N),
- KEY(4, 0, KEY_BACKSPACE),
- KEY(4, 1, KEY_H),
- KEY(4, 3, KEY_M),
+ KEY(3, 4, KEY_M),
+ KEY(3, 5, KEY_SPACE),
+ KEY(3, 6, KEY_SPACE),
+ KEY(3, 7, KEY_LEFT),
+ KEY(4, 0, KEY_T),
+ KEY(4, 1, KEY_DOWN),
+ KEY(4, 2, KEY_RIGHT),
KEY(4, 4, KEY_LEFTCTRL),
- KEY(5, 1, KEY_J),
- KEY(5, 2, KEY_Z),
- KEY(5, 3, KEY_SPACE),
- KEY(5, 4, KEY_LEFTSHIFT),
- KEY(6, 0, KEY_A),
- KEY(6, 1, KEY_K),
- KEY(6, 2, KEY_X),
- KEY(6, 3, KEY_SPACE),
- KEY(6, 4, KEY_FN),
- KEY(7, 0, KEY_S),
- KEY(7, 1, KEY_L),
- KEY(7, 2, KEY_C),
- KEY(7, 3, KEY_LEFT),
- KEY(0xff, 0, KEY_F6),
- KEY(0xff, 1, KEY_F7),
- KEY(0xff, 2, KEY_F8),
- KEY(0xff, 4, KEY_F9),
- KEY(0xff, 5, KEY_F10),
+ KEY(4, 5, KEY_RIGHTALT),
+ KEY(4, 6, KEY_LEFTSHIFT),
+ KEY(5, 0, KEY_Y),
+ KEY(6, 0, KEY_U),
+ KEY(7, 0, KEY_I),
+ KEY(7, 1, KEY_F7),
+ KEY(7, 2, KEY_F8),
+ KEY(0xff, 2, KEY_F9),
+ KEY(0xff, 4, KEY_F10),
+ KEY(0xff, 5, KEY_F11),
};
static struct matrix_keymap_data board_map_data = {
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 2d02dfd..508824e 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -349,11 +349,11 @@ struct twl4030_madc_platform_data {
int irq_line;
};
-/* Boards have uniqe mappings of {col, row} -- keycode.
- * Column and row are 4 bits, but range only from 0..7.
+/* Boards have uniqe mappings of {row, col} -- keycode.
+ * Column and row are 8 bits each, but range only from 0..7.
* a PERSISTENT_KEY is always on and never reported.
*/
-#define PERSISTENT_KEY(c, r) KEY((c), (r), KEY_RESERVED)
+#define PERSISTENT_KEY(r, c) KEY((r), (c), KEY_RESERVED)
struct twl4030_keypad_data {
const struct matrix_keymap_data *keymap_data;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] omapfb: Condition mutex acquisition
Imre Deak wrote: Hi, On Wed, Sep 30, 2009 at 02:53:10AM +0200, ext Tony Lindgren wrote: [...] Tomi Imre, do you want me to add this to the omap-fixes queue, or are you planning to send other fixes too? If you want me to add it, please reply with your ack. I'll added it into omap-fixes-testing branch for now so we can get the omaps booted. Acked-by: Imre Deak imre.d...@nokia.com There are no other patches for the DSS1 driver, so it'd be good if you could just apply it to omap-fixes. Tony, Please take v2 of patch instead, has a richer description of the problem. Thanks in advance, Sergio --Imre -- 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] OMAP3: Common mechanism to identify cpu revision
Sanjeev Premi pr...@ti.com writes:
There are multiple mechanisms to identify the cpu revisions.
Most common is use of omap_rev(). This, however, does a
absolute comparison of omap_revision - which includes
CPU id, CPU rev and CPU class. This comparison fails for
OMAP35x processors.
This patch defines generic functions that use only the
CPU rev bits in omap_revision to identify the revision
information.
Usage will change from (for example):
if (omap_rev() OMAP3430_REV_ES2_0)
to:
if (cpu_is_omap34xx() omap_rev_gt_2_0())
Specific check for cpu_is_xxx() will not be needed for
files specific to silicon e.g. pm34xx.c, clock34xx.c, etc.
Signed-off-by: Sanjeev Premi pr...@ti.com
Looks mostly good, some minor comments/questions below...
---
arch/arm/mach-omap2/clock34xx.c |4 +-
arch/arm/mach-omap2/control.c |6 ++--
arch/arm/mach-omap2/pm34xx.c | 17 +-
arch/arm/plat-omap/include/mach/cpu.h | 55
+
4 files changed, 69 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index e0df0ce..074c593 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -815,7 +815,7 @@ static int omap3_dpll4_set_rate(struct clk *clk, unsigned
long rate)
* on 3430ES1 prevents us from changing DPLL multipliers or dividers
* on DPLL4.
*/
- if (omap_rev() == OMAP3430_REV_ES1_0) {
+ if (omap_rev_is_1_0()) {
printk(KERN_ERR clock: DPLL4 cannot change rate due to
silicon 'Limitation 2.5' on 3430ES1.\n);
return -EINVAL;
@@ -1157,7 +1157,7 @@ int __init omap2_clk_init(void)
* Update this if there are further clock changes between ES2
* and production parts
*/
- if (omap_rev() == OMAP3430_REV_ES1_0) {
+ if (omap_rev_is_1_0()) {
/* No 3430ES1-only rates exist, so no RATE_IN_3430ES1 */
cpu_clkflg |= CK_3430ES1;
} else {
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index c9407c0..089e714 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,8 +209,8 @@ void omap3_save_scratchpad_contents(void)
/* Populate the Scratchpad contents */
scratchpad_contents.boot_config_ptr = 0x0;
- if (omap_rev() != OMAP3430_REV_ES3_0
- omap_rev() != OMAP3430_REV_ES3_1)
+ if (cpu_is_omap34xx()
+ !omap_rev_is_3_0() !omap_rev_is_3_1())
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
else
@@ -271,7 +271,7 @@ void omap3_save_scratchpad_contents(void)
* of AUTO_CNT = 1 prior to any transition to OFF mode.
*/
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
- (omap_rev() = OMAP3430_REV_ES3_0))
+ cpu_is_omap34xx() omap_rev_ge_3_0())
I don't think the cpu_is_... is needed here because of the OMAP3
specific function.
sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER)
~(SDRC_POWER_AUTOCOUNT_MASK|
SDRC_POWER_CLKCTRL_MASK)) |
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c1d58a7..7a1eb95 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/usb/musb.h
+#include mach/cpu.h
#include mach/sram.h
#include mach/prcm.h
#include mach/clockdomain.h
@@ -108,7 +109,7 @@ static void omap3_enable_io_chain(void)
{
int timeout = 0;
- if (omap_rev() = OMAP3430_REV_ES3_1) {
+ if (omap_rev_ge_3_1()) {
prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
/* Do a readback to assure write has been done */
prm_read_mod_reg(WKUP_MOD, PM_WKEN);
@@ -129,7 +130,7 @@ static void omap3_enable_io_chain(void)
static void omap3_disable_io_chain(void)
{
- if (omap_rev() = OMAP3430_REV_ES3_1)
+ if (omap_rev_ge_3_1())
prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
}
@@ -248,7 +249,7 @@ static int _prcm_int_handle_wakeup(void)
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) {
+ if (omap_rev_gt_1_0()) {
c += prcm_clear_mod_irqs(CORE_MOD, 3);
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
@@ -432,7 +433,7 @@ void omap_sram_idle(void)
* of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
* Hence store/restore the SDRC_POWER register here.
*/
- if
Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
Tony Lindgren t...@atomide.com writes: Hi all, I've updated our linux-omap tree to v2.6.32-rc1. I've also added a branch omap-2.6.31 for the old code. This time I also nuked the remaining omap legacy code we still had lurking around :) The commits at the end of this mail describe what I did first as commits, then I merged everything to be the same as the mainline v2.6.32-rc1. So currently the linux-omap master branch is: v2.6.32-rc1 + omap-fixes + ehci + cbus The new model is that I'll be resetting the linux-omap master branch to mainline at each -rc, then merge in our various upstream queues back in again. Please note that Remove omap extra version in Makefile commit means that you now need to set the ARCH and CROSS_COMPILE for your compiler. FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in the build dir under include/generated/kernel.[arch,cross_compile], so if you build using ARCH and CROSS_COMPILE once, it should remember them until doing a clean build. 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: Watchdog dump
John Sarman johnsar...@gmail.com writes: I got a watchdog dump and it said cut here so I did and I am pasting to get help It would help to post the kernel version, SoC and board you're using. Based on the dm9000 driver, I'm guessing this is a DaVinci DM355 and you meant to post this to the DaVinci list: davinci-linux-open-sou...@linux.davincidsp.com This looks like the GPIO IRQ problem we had on dm355 awhile back and has been fixed in davinci git for some time. Kevin eth0: link down Sending DHCP requests .. eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1 .. [ cut here ] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x18c/0x29c() NETDEV WATCHDOG: eth0 (dm9000): transmit queue 0 timed out Modules linked in: Backtrace: [c002d784] (dump_backtrace+0x0/0x114) from [c02d0058] (dump_stack+0x18/0x1c) r7:c03b3e10 r6:c0256344 r5:c038ad99 r4:00f6 [c02d0040] (dump_stack+0x0/0x1c) from [c003e000] (warn_slowpath_common+0x50) [c003dfb0] (warn_slowpath_common+0x0/0x68) from [c003e064] (warn_slowpath_f) r7:0024 r6:c04043a0 r5:c48d7400 r4: [c003e034] (warn_slowpath_fmt+0x0/0x38) from [c0256344] (dev_watchdog+0x18c) r3:c48d7400 r2:c038adb1 [c02561b8] (dev_watchdog+0x0/0x29c) from [c0048304] (run_timer_softirq+0x1b) [c0048148] (run_timer_softirq+0x0/0x280) from [c00435ac] (__do_softirq+0x98) [c0043514] (__do_softirq+0x0/0x12c) from [c0043690] (irq_exit+0x50/0xa4) [c0043640] (irq_exit+0x0/0xa4) from [c0029074] (_text+0x74/0x8c) [c0029000] (_text+0x0/0x8c) from [c0029aac] (__irq_svc+0x4c/0x90) Exception stack(0xc03b3f50 to 0xc03b3f98) 3f40: 0005317f 0005217f 6013 3f60: c03b2000 c03de420 c0023e14 c03b6358 80022334 41069265 80022300 c03b3fa4 3f80: 60d3 c03b3f98 c002a9b0 c002a9bc 6013 r5:fec48000 r4: [c002a988] (default_idle+0x0/0x38) from [c002af08] (cpu_idle+0x78/0xe4) [c002ae90] (cpu_idle+0x0/0xe4) from [c02cecf4] (rest_init+0x70/0x84) r5:c03de420 r4:c03f2af8 [c02cec84] (rest_init+0x0/0x84) from [c0008998] (start_kernel+0x268/0x2c0) [c0008730] (start_kernel+0x0/0x2c0) from [80008034] (0x80008034) r5:c03de4c4 r4:00053175 ---[ end trace 5b6c3710ca2a460a ]--- ., OK IP-Config: Got DHCP answer from 192.168.2.1, my address is 192.168.2.155 IP-Config: Complete: device=eth0, addr=192.168.2.155, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.155, domain=, nis-domain=(none), bootserver=192.168.2.1, rootserver=192.168.2.1, rootpath= kjournald starting. Commit interval 5 seconds The kernel continued to boot and all is well but just curious if there is something that I can do to pet the dog or whatever to prevent this from outputting. Thanks in Advance John Sarman -- 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 1/2] twl4030: Do not dereference null pointer in error path
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/mfd/twl4030-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..8cf0a02 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl-client = i2c_new_dummy(client-adapter,
twl-address);
if (!twl-client) {
- dev_err(twl-client-dev,
+ dev_err(client-dev,
can't attach client %d\n, i);
status = -ENOMEM;
goto fail;
--
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 2/2] twl4030: Enable low-power mode to 32KHz oscillator
Allows TWL's 32KHz oscillator to go in low-power mode when
main battery voltage is running low.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/mfd/twl4030-core.c |9 +++--
include/linux/i2c/twl4030.h |5 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 8cf0a02..5596bb4 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -177,6 +177,7 @@
#define HFCLK_FREQ_26_MHZ (2 0)
#define HFCLK_FREQ_38p4_MHZ(3 0)
#define HIGH_PERF_SQ (1 3)
+#define CK32K_LOWPWR_EN(1 7)
/* chip-specific feature flags, for i2c_device_id.driver_data */
@@ -678,7 +679,8 @@ static inline int __init unprotect_pm_master(void)
return e;
}
-static void clocks_init(struct device *dev)
+static void clocks_init(struct device *dev,
+ struct twl4030_clock_init_data *clock)
{
int e = 0;
struct clk *osc;
@@ -725,6 +727,9 @@ static void clocks_init(struct device *dev)
}
ctrl |= HIGH_PERF_SQ;
+ if (clock clock-ck32k_lowpwr_enable)
+ ctrl |= CK32K_LOWPWR_EN;
+
e |= unprotect_pm_master();
/* effect-MADC+USB ck en */
e |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, ctrl, R_CFG_BOOT);
@@ -805,7 +810,7 @@ twl4030_probe(struct i2c_client *client, const struct
i2c_device_id *id)
inuse = true;
/* setup clock framework */
- clocks_init(client-dev);
+ clocks_init(client-dev, pdata-clock);
/* load power event scripts */
if (twl_has_power() pdata-power)
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 2d02dfd..612d0b7 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -312,6 +312,10 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes);
/*--*/
+struct twl4030_clock_init_data {
+ int ck32k_lowpwr_enable;
+};
+
struct twl4030_bci_platform_data {
int *battery_tmp_tbl;
unsigned int tblsize;
@@ -403,6 +407,7 @@ extern void twl4030_power_init(struct twl4030_power_data
*triton2_scripts);
struct twl4030_platform_data {
unsignedirq_base, irq_end;
+ struct twl4030_clock_init_data *clock;
struct twl4030_bci_platform_data*bci;
struct twl4030_gpio_platform_data *gpio;
struct twl4030_madc_platform_data *madc;
--
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] twl4030: Fix boot with twl4030 usb transceiver enabled
The usb regulator supplies (usb1v5, usb1v8 usb3v1) must be available
before adding the twl4030_usb child, else twl4030_usb_ldo_init() will
always fail thus causing boot lock-up.
This patch fixes boot on OMAP systems using the twl4030 usb transceiver.
CONFIG_TWL4030_USB=y
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
drivers/mfd/twl4030-core.c | 112 ++--
1 files changed, 46 insertions(+), 66 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..dcd27be 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -480,7 +480,6 @@ static int
add_children(struct twl4030_platform_data *pdata, unsigned long features)
{
struct device *child;
- struct device *usb_transceiver = NULL;
if (twl_has_bci() pdata-bci !(features TPS_SUBSET)) {
child = add_child(3, twl4030_bci,
@@ -532,16 +531,61 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
}
if (twl_has_usb() pdata-usb) {
+
+ static struct regulator_consumer_supply usb1v5 = {
+ .supply = usb1v5,
+ };
+ static struct regulator_consumer_supply usb1v8 = {
+ .supply = usb1v8,
+ };
+ static struct regulator_consumer_supply usb3v1 = {
+ .supply = usb3v1,
+ };
+
+ /* First add the regulators so that they can be used by transceiver */
+ 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(TWL4030_REG_VUSB1V5,
+ usb_fixed, usb1v5, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator_linked(TWL4030_REG_VUSB1V8,
+ usb_fixed, usb1v8, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator_linked(TWL4030_REG_VUSB3V1,
+ usb_fixed, usb3v1, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ }
+
child = add_child(0, twl4030_usb,
pdata-usb, sizeof(*pdata-usb),
true,
/* irq0 = USB_PRES, irq1 = USB */
pdata-irq_base + 8 + 2, pdata-irq_base + 4);
+
if (IS_ERR(child))
return PTR_ERR(child);
/* we need to connect regulators to this transceiver */
- usb_transceiver = child;
+ if (twl_has_regulator() child) {
+ usb1v5.dev = child;
+ usb1v8.dev = child;
+ usb3v1.dev = child;
+ }
}
if (twl_has_watchdog()) {
@@ -557,70 +601,6 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
return PTR_ERR(child);
}
- if (twl_has_regulator()) {
- /*
- child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1);
- if (IS_ERR(child))
- return PTR_ERR(child);
- */
-
- child = add_regulator(TWL4030_REG_VMMC1, pdata-vmmc1);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VDAC, pdata-vdac);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator((features TWL4030_VAUX2)
- ? TWL4030_REG_VAUX2_4030
- : TWL4030_REG_VAUX2,
- pdata-vaux2);
- if (IS_ERR(child))
- return PTR_ERR(child);
- }
-
- if (twl_has_regulator() usb_transceiver) {
- static struct regulator_consumer_supply usb1v5 = {
- .supply = usb1v5,
- };
- static struct regulator_consumer_supply usb1v8 = {
- .supply = usb1v8,
-
Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
ext Tony Lindgren wrote: * Felipe Contreras felipe.contre...@gmail.com [090929 10:24]: On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren t...@atomide.com wrote: Hi all, I've updated our linux-omap tree to v2.6.32-rc1. I've also added a branch omap-2.6.31 for the old code. This time I also nuked the remaining omap legacy code we still had lurking around :) The commits at the end of this mail describe what I did first as commits, then I merged everything to be the same as the mainline v2.6.32-rc1. So currently the linux-omap master branch is: v2.6.32-rc1 + omap-fixes + ehci + cbus The new model is that I'll be resetting the linux-omap master branch to mainline at each -rc, then merge in our various upstream queues back in again. Excellent! I was wondering why this wasn't being done. I certainly hope linus' 2.6.32 will work on omap right away. Yeah, let's hope Tomi gets in the DSS2 code too. Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and other people report similar issues: http://www.spinics.net/lists/linux-omap/msg17968.html Have you got 2.6.32-rc1 (+fixes) to boot? Hmm, looks like it's musb again. This is what I get on my overo after applying the DEBUG_LL hack from omap-debug branch: i've just sent a fix for this musb problem. patch is labelled twl4030: Fix boot with twl4030 usb transceiver enabled cheers, -roger 3musb_hdrc musb_hdrc: musb_init_controller failed with status -19 1Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 1[] *pgd= Internal error: Oops: 5 [#1] dModules linked in: CPU: 0Not tainted (2.6.32-rc2-05967-gd350540-dirty #892) PC is at musb_free+0x68/0xb8 LR is at musb_free+0x34/0xb8 pc : [c028a160]lr : [c028a12c]psr: a013 sp : c781fe50 ip : 0064 fp : r10: r9 : r8 : c0557bc0 r7 : c7811000 r6 : c78110e8 r5 : c78110e8 r4 : r3 : r2 : 0001 r1 : c04c95b6 r0 : ffed Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc781e2f0) Stack: (0xc781fe50 to 0xc782) fe40: ffed c78110e8 c001e8f8 fe60: c781fea4 c7804180 c7804184 c0533dc8 c0533dd0 005c d80ab000 fe80: c0533dac c7811190 c781fedc c0114ad8 c7806850 c0546248 c06d74e0 fea0: c03cd5c8 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00 fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0 fee0: c78b8d80 c781ff00 c78b8de0 c787a210 0001 c01157b4 ff00: c787a210 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0 ff20: c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04 ff40: c055df04 c7873600 c0557bc0 c020fce0 c020fc80 c055df04 c020f420 ff60: c7802d08 c787b240 c0026dd4 0080 c055df04 c020ed38 c03f14f4 c03f14f4 ff80: c782 c0026dd4 c055def0 c055df04 c020ffb0 ffa0: c0026dd4 c055def0 c001dca0 c0210f70 c0026dd4 ffc0: c001dca0 c002d2b4 0031 0192 c0026dd4 ffe0: c0008578 c002ee10 817fdf10 00bbff00 [c028a160] (musb_free+0x68/0xb8) from [c001e8f8] (musb_probe+0xab8/0xbb4) [c001e8f8] (musb_probe+0xab8/0xbb4) from [c0210b7c] (platform_drv_probe+0x1) [c0210b7c] (platform_drv_probe+0x18/0x1c) from [c020fbd4] (driver_probe_dev) [c020fbd4] (driver_probe_device+0xa0/0x14c) from [c020fce0] (__driver_attac) [c020fce0] (__driver_attach+0x60/0x84) from [c020f420] (bus_for_each_dev+0x) [c020f420] (bus_for_each_dev+0x44/0x74) from [c020ed38] (bus_add_driver+0xf) [c020ed38] (bus_add_driver+0xf4/0x278) from [c020ffb0] (driver_register+0xa) [c020ffb0] (driver_register+0xa8/0x130) from [c0210f70] (platform_driver_pr) [c0210f70] (platform_driver_probe+0x10/0x88) from [c002d2b4] (do_one_initca) [c002d2b4] (do_one_initcall+0x5c/0x1b4) from [c0008578] (kernel_init+0x90/0) [c0008578] (kernel_init+0x90/0x10c) from [c002ee10] (kernel_thread_exit+0x0) Code: e1a01005 ebf80722 e595309c e3a04000 (e593) 4---[ end trace 1b75b31a2719ed1c ]--- 0Kernel panic - not syncing: Attempted to kill init! After disabling musb, it boots further but can't mount
Re: [PATCH 1/1] OMAP: I2C: Add mpu wake up latency constraint in i2c
Kalle Jokiniemi kalle.jokini...@digia.com writes:
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 and applied only on OMAP34XX devices.
Seems like the latency value should also be (optionally) passed in
pdata so this can be experimented with per-platform.
Other than that looks ok to me.
Do we have an official OMAP I2C maintainer who should signoff on this?
Kevin
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
arch/arm/plat-omap/i2c.c | 49
+++--
drivers/i2c/busses/i2c-omap.c | 17 +++---
include/linux/i2c-omap.h |9 +++
3 files changed, 59 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..d43d0ad 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,8 +26,10 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
+#include linux/i2c-omap.h
#include mach/irqs.h
#include mach/mux.h
+#include mach/omap-pm.h
#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,25 @@ static const int omap34xx_pins[][2] = {};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+/**
+ * omap_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.
+ */
+#ifdef CONFIG_ARCH_OMAP34XX
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, set ? 500 : -1);
+}
+#else
+static inline void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
+{; }
+#endif
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -180,8 +201,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 +216,11 @@ 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;
+ i2c_pdata[i].set_mpu_wkup_lat =
+ omap_i2c_set_wfc_mpu_wkup_lat;
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -231,9 +254,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;
+
+ i2c_pdata[bus_id - 1].set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
+ 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
Re: [PATCH] omap: resource: Fix race in register_resource()
Mike Chan m...@android.com writes:
Checking if the resource is already registered and adding to the list
must be atomic or bad things can happen.
Signed-off-by: Mike Chan m...@android.com
Thanks, this one applies. Pushing to PM branch and pm-2.6.29.
Kevin
---
arch/arm/plat-omap/resource.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 111020a..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -255,6 +255,7 @@ int resource_refresh(void)
*/
int resource_register(struct shared_resource *resp)
{
+ int ret = 0;
if (!resp)
return -EINVAL;
@@ -262,12 +263,13 @@ int resource_register(struct shared_resource *resp)
return -EINVAL;
/* Verify that the resource is not already registered */
- if (resource_lookup(resp-name))
- return -EEXIST;
+ down(res_mutex);
+ if (_resource_lookup(resp-name))
+ ret = -EEXIST;
+ goto out;
INIT_LIST_HEAD(resp-users_list);
- down(res_mutex);
/* Add the resource to the resource list */
list_add(resp-node, res_list);
@@ -275,10 +277,11 @@ int resource_register(struct shared_resource *resp)
if (resp-ops-init)
resp-ops-init(resp);
- up(res_mutex);
pr_debug(resource: registered %s\n, resp-name);
- return 0;
+out:
+ up(res_mutex);
+ return ret;
}
EXPORT_SYMBOL(resource_register);
--
1.5.4.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] OMAP3:PM: reject disabled OPP
Nishanth Menon n...@ti.com writes:
when the omap_opp structures are disabled by setting the
frequency as 0 as below (as an example)
{0, VDD2_OPP1, 0x1E},
program_opp attempts to set voltage even after frequency
setting fails. we can instead return if we see invalid
values for either frequency or voltage
Signed-off-by: Nishanth Menon n...@ti.com
Looks good, pushing to PM branch.
Kevin
---
arch/arm/mach-omap2/resource34xx.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 1693e9b..491e1dc 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -282,6 +282,11 @@ static int program_opp(int res, struct omap_opp *opp,
int target_level,
t_opp = ID_VDD(res) | ID_OPP_NO(opp[target_level].opp_id);
c_opp = ID_VDD(res) | ID_OPP_NO(opp[current_level].opp_id);
#endif
+
+ /* Sanity check of the OPP params before attempting to set */
+ if (!opp[target_level].rate || !opp[target_level].vsel)
+ return -EINVAL;
+
if (target_level current_level)
raise = 1;
else
--
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] OMAP3: Lock DPLL5 at boot
Thanks for the changes, I will queue this in a for-next branch for .33. Is this for .33 or .32? I think it might be a little late for .32. If there is some crash or instability that this fixes, we could queue it up for .32-fixes ? Well, without this, there's no way the child clocks can be enabled correctly. OK. So is it the case that USBHOST/USBTLL/USIM won't work without this fix? Yup. Not sure about USIM - will check. If so then we'll queue it for .32-fixes. Since .32 is already at -rc9, I think it is too late for .32. Would be nice. Thanks! Paul, Is this patch already queued up somewhere, or are you waiting for a clarification from me on the USIM? (I haven't had a chance to look yet, since this is not in the regular TRM) - Anand-- 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: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
2009/9/30 Roger Quadros ext-roger.quad...@nokia.com: ext Tony Lindgren wrote: * Felipe Contreras felipe.contre...@gmail.com [090929 10:24]: On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren t...@atomide.com wrote: Hi all, I've updated our linux-omap tree to v2.6.32-rc1. I've also added a branch omap-2.6.31 for the old code. This time I also nuked the remaining omap legacy code we still had lurking around :) The commits at the end of this mail describe what I did first as commits, then I merged everything to be the same as the mainline v2.6.32-rc1. So currently the linux-omap master branch is: v2.6.32-rc1 + omap-fixes + ehci + cbus The new model is that I'll be resetting the linux-omap master branch to mainline at each -rc, then merge in our various upstream queues back in again. Excellent! I was wondering why this wasn't being done. I certainly hope linus' 2.6.32 will work on omap right away. Yeah, let's hope Tomi gets in the DSS2 code too. Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and other people report similar issues: http://www.spinics.net/lists/linux-omap/msg17968.html Have you got 2.6.32-rc1 (+fixes) to boot? Hmm, looks like it's musb again. This is what I get on my overo after applying the DEBUG_LL hack from omap-debug branch: i've just sent a fix for this musb problem. patch is labelled twl4030: Fix boot with twl4030 usb transceiver enabled I can't quite locate it in linux-usb archives (or anywhere within google's reach). Could you sand it here or provide a link? Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
other people report similar issues:
http://www.spinics.net/lists/linux-omap/msg17968.html
Have you got 2.6.32-rc1 (+fixes) to boot?
Hmm, looks like it's musb again. This is what I get on my
overo after applying the DEBUG_LL hack from omap-debug branch:
i've just sent a fix for this musb problem. patch is labelled twl4030: Fix
boot with twl4030 usb transceiver enabled
I can't quite locate it in linux-usb archives (or anywhere within
google's reach). Could you sand it here or provide a link?
Here you go. Patchwork rocks!
http://patchwork.kernel.org/patch/50721/
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
* Kevin Hilman khil...@deeprootsystems.com [090930 07:07]: Tony Lindgren t...@atomide.com writes: Hi all, I've updated our linux-omap tree to v2.6.32-rc1. I've also added a branch omap-2.6.31 for the old code. This time I also nuked the remaining omap legacy code we still had lurking around :) The commits at the end of this mail describe what I did first as commits, then I merged everything to be the same as the mainline v2.6.32-rc1. So currently the linux-omap master branch is: v2.6.32-rc1 + omap-fixes + ehci + cbus The new model is that I'll be resetting the linux-omap master branch to mainline at each -rc, then merge in our various upstream queues back in again. Please note that Remove omap extra version in Makefile commit means that you now need to set the ARCH and CROSS_COMPILE for your compiler. FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in the build dir under include/generated/kernel.[arch,cross_compile], so if you build using ARCH and CROSS_COMPILE once, it should remember them until doing a clean build. Nice, sounds like we removed that hack just at the right moment then! 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] twl4030: Fix boot with twl4030 usb transceiver enabled
* Roger Quadros ext-roger.quad...@nokia.com [090930 08:48]:
The usb regulator supplies (usb1v5, usb1v8 usb3v1) must be available
before adding the twl4030_usb child, else twl4030_usb_ldo_init() will
always fail thus causing boot lock-up.
This patch fixes boot on OMAP systems using the twl4030 usb transceiver.
CONFIG_TWL4030_USB=y
This fix should go to Samuel for integration:
$ grep -a4 drivers/mfd MAINTAINERS
MULTIFUNCTION DEVICES (MFD)
M: Samuel Ortiz sa...@linux.intel.com
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
S: Supported
F: drivers/mfd/
...
Regards,
Tony
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
drivers/mfd/twl4030-core.c | 112
++--
1 files changed, 46 insertions(+), 66 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..dcd27be 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -480,7 +480,6 @@ static int
add_children(struct twl4030_platform_data *pdata, unsigned long features)
{
struct device *child;
- struct device *usb_transceiver = NULL;
if (twl_has_bci() pdata-bci !(features TPS_SUBSET)) {
child = add_child(3, twl4030_bci,
@@ -532,16 +531,61 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
}
if (twl_has_usb() pdata-usb) {
+
+ static struct regulator_consumer_supply usb1v5 = {
+ .supply = usb1v5,
+ };
+ static struct regulator_consumer_supply usb1v8 = {
+ .supply = usb1v8,
+ };
+ static struct regulator_consumer_supply usb3v1 = {
+ .supply = usb3v1,
+ };
+
+ /* First add the regulators so that they can be used by transceiver */
+ 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(TWL4030_REG_VUSB1V5,
+ usb_fixed, usb1v5, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator_linked(TWL4030_REG_VUSB1V8,
+ usb_fixed, usb1v8, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator_linked(TWL4030_REG_VUSB3V1,
+ usb_fixed, usb3v1, 1);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ }
+
child = add_child(0, twl4030_usb,
pdata-usb, sizeof(*pdata-usb),
true,
/* irq0 = USB_PRES, irq1 = USB */
pdata-irq_base + 8 + 2, pdata-irq_base + 4);
+
if (IS_ERR(child))
return PTR_ERR(child);
/* we need to connect regulators to this transceiver */
- usb_transceiver = child;
+ if (twl_has_regulator() child) {
+ usb1v5.dev = child;
+ usb1v8.dev = child;
+ usb3v1.dev = child;
+ }
}
if (twl_has_watchdog()) {
@@ -557,70 +601,6 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
return PTR_ERR(child);
}
- if (twl_has_regulator()) {
- /*
- child = add_regulator(TWL4030_REG_VPLL1, pdata-vpll1);
- if (IS_ERR(child))
- return PTR_ERR(child);
- */
-
- child = add_regulator(TWL4030_REG_VMMC1, pdata-vmmc1);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL4030_REG_VDAC, pdata-vdac);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator((features TWL4030_VAUX2)
- ? TWL4030_REG_VAUX2_4030
- : TWL4030_REG_VAUX2,
- pdata-vaux2);
- if (IS_ERR(child))
- return
Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
* Gadiyar, Anand gadi...@ti.com [090930 10:05]: Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and other people report similar issues: http://www.spinics.net/lists/linux-omap/msg17968.html Have you got 2.6.32-rc1 (+fixes) to boot? Hmm, looks like it's musb again. This is what I get on my overo after applying the DEBUG_LL hack from omap-debug branch: i've just sent a fix for this musb problem. patch is labelled twl4030: Fix boot with twl4030 usb transceiver enabled I can't quite locate it in linux-usb archives (or anywhere within google's reach). Could you sand it here or provide a link? Here you go. Patchwork rocks! http://patchwork.kernel.org/patch/50721/ Great, thanks. Roger, please send your fix to Samuel for merging. Meanwhile, I'll apply it into fixes-testing while waiting for it to get to mainline via Samuel. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Warnings: pm branch
On Wed, Aug 12, 2009 at 7:38 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Hemanth V heman...@ti.com writes:
- Original Message -
From: Kevin Hilman khil...@deeprootsystems.com
/* enter the state and update stats */
@@ -91,6 +93,12 @@ static void cpuidle_idle_call(void)
/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor-reflect)
cpuidle_curr_governor-reflect(dev);
+
+ return;
+
... I think you want to drop this return. If it returns here, it
will still not enable IRQs. I think it should just fall through
to the enable and return.
Since omap3_enter_idle returns with interrupts enabled, I had
added this return. We could remove it also for safety purposes.
OK. I think you should post to linux-pm for comment, and possibly
raise this as a question.
You can add:
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Hemanth,
I've reworked/simplified this patch slightly (see below) and will send
to linux-pm shortly.
Kevin
This one is against PM branch:
commit 808854375b94017ba996a467a082a38730fff434
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Wed Sep 30 09:57:40 2009 -0700
CPUidle: always return with interrupts enabled
In the case where cpuidle_idle_call() returns before changing state
due to a need_resched(), it was returning with IRQs disabled.
This patche ensures IRQs are (re)enabled before returning.
Reported-by: Hemanth V heman...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 8504a21..910c49d 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -75,8 +75,11 @@ static void cpuidle_idle_call(void)
#endif
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
- if (need_resched())
+ if (need_resched()) {
+ local_irq_enable();
return;
+ }
+
target_state = dev-states[next_state];
/* enter the state and update stats */
--
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 v2] omapfb: Condition mutex acquisition
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes-testing Initial commit ID (Likely to change): e91f6e0df91a89a52fe822762af6d08c9eb8ddc4 PatchWorks http://patchwork.kernel.org/patch/50686/ 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=e91f6e0df91a89a52fe822762af6d08c9eb8ddc4 -- 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] twl4030: Fix boot with twl4030 usb transceiver enabled
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes-testing Initial commit ID (Likely to change): 160bb884083cc4e3afa1b8d0fdc82f0720eb3f0a PatchWorks http://patchwork.kernel.org/patch/50721/ 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=160bb884083cc4e3afa1b8d0fdc82f0720eb3f0a -- 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: ehci: remove DPLL5 programming
omap3: ehci: remove DPLL5 programming
DPLL5 programming should be taken care of by the clock framework.
The driver should not need to worry about programming this
explicitly.
Also, the DPLL5 m and n values used were valid only for a
specific value of the system clock. So they would not work
correctly for other input frequencies anyway.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
Needs http://patchwork.kernel.org/patch/46216/ to
ensure the DPLL is locked correctly.
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index f2771cf..7efc2f5 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -225,8 +225,6 @@ static void omap_usb_utmi_init(struct ehci_hcd_omap *omap,
u8 tll_channel_mask)
/*-*/
-#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h
-
/* omap_start_ehc
* - Start the TI USBHOST controller
*/
@@ -239,29 +237,6 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
dev_dbg(omap-dev, starting TI EHCI USB Controller\n);
- /* Start DPLL5 Programming:
-* Clock Framework is not doing this now:
-* This will be done in clock framework later
-*/
- /* Enable DPLL 5 : Based on Input of 13Mhz*/
- cm_write_mod_reg((12 OMAP3430ES2_PERIPH2_DPLL_DIV_SHIFT)|
- (120 OMAP3430ES2_PERIPH2_DPLL_MULT_SHIFT),
- PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
-
- cm_write_mod_reg(1 OMAP3430ES2_DIV_120M_SHIFT,
- PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
-
- cm_write_mod_reg((7 OMAP3430ES2_PERIPH2_DPLL_FREQSEL_SHIFT) |
- (7 OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT),
- PLL_MOD, OMAP3430ES2_CM_CLKEN2);
-
- while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2)
- OMAP3430ES2_ST_PERIPH2_CLK_MASK))
- dev_dbg(omap-dev, idlest2 = 0x%x\n,
- cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
- /* End DPLL5 programming */
-
-
/* Enable Clocks for USBHOST */
omap-usbhost_ick = clk_get(omap-dev, usbhost_ick);
if (IS_ERR(omap-usbhost_ick)) {
--
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: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
Hi,
* Shilimkar, Santosh santosh.shilim...@ti.com [090929 03:54]:
snip
Thanks for fixing the OMAP4 compilation issues. We need below patch to make
the kernel boot on OMAP4430 on the latest LO master.
No problem. In the future, let's make sure the omap4 patches are merged
into l-o master branch for testing. This time the first three patches
in the omap-fixes branch were build breakage caused by the omap4 patches
directly or indirectly..
Also, please everybody check that your patches don't break the build
for other the omaps, and also boot test on some other omaps if someting
looks risky.
Few comments below.
From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().
The opps probably should be oops above :)
Additionally the patch removed the merge issue for the UART4.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/io.c|2 ++
arch/arm/mach-omap2/serial.c| 10 --
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
static void __init omap_4430sdp_init_irq(void)
{
+ omap_board_config = sdp4430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap2_init_common_hw(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_board_config = sdp4430_config;
- omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
+#endif
omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
Can't we fix the extra uart instead of removing it? We just added it!
It's still there in omap4, right?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]PM: Initialization of SDRC params for DVFS on Zoom2
Teerth, ping.
On Wed, Sep 9, 2009 at 5:12 AM, Jean Pihet jpi...@mvista.com wrote:
On Wednesday 09 September 2009 00:17:42 Kevin Hilman wrote:
Reddy, Teerth tee...@ti.com writes:
This patch initializes the SDRC params for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom2.c
+++ linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
@@ -23,6 +23,7 @@
#include mmc-twl4030.h
#include omap3-opp.h
+#include sdram-micron-mt46h32m32lf-6.h
static struct omap_uart_config zoom2_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -36,8 +37,9 @@ static void __init omap_zoom2_init_irq(v
{
omap_board_config = zoom2_config;
omap_board_config_size = ARRAY_SIZE(zoom2_config);
- omap2_init_common_hw(NULL, NULL, omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
+ omap3_mpu_rate_table, omap3_dsp_rate_table,
+ omap3_l3_rate_table);
Not having looked at the Zoom2 schematics, are you sure this is only
using a single chip select? The other boards using the same part
(beagle, overo) are interfacing to this part using both CSes.
Have you tested DVFS on Zoom2 using the full 256Mb?
Good point!
DVFS works fine using the two chip selects:
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
One remark though: since the memory chips are popped on top of the OMAP chip
the schematics are not showing the chip selects connections. In any case
U-Boot is configuring the SDRC module to use the 2 chip selects, so I think
this change is needed.
We need confirmation. Anyone from TI knows?
Regards,
Jean
Kevin
omap_init_irq();
omap_gpio_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
--
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: [RFC] OMAP3 : PM : Handle variable length OPP tables
Premi, Sanjeev pr...@ti.com writes:
Hi all,
There is no generic function to translate an OPP to FREQ and vice versa.
Came across the problem while trying to submit a follow-up to earlier
patch for change in mpurate via bootargs.
The function get_opp in resource34xx.c, but it is always called with an
explicit addition of MAX_VDDn_OPP e.g.
opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk-rate);
opp = get_opp(l3_opps + MAX_VDD2_OPP, clk-rate);
This is 'addition' is required as there is no encapsulation of the
MIN and MAX VDDs associated to the table.
The patch below fixes this issue; buy creating a 'table' object with
necessary information. It can also help in getting rid of the
empty {0, 0, 0} at index 0 of each OPP table.
At the moment, it does not break any functionality in resource34xx.c;
migration to this encapsulation can be taken as next step.
This code is bare 'git-diff' for early comments. Formal patch to follow...
Looks ok. Please send updated patch against current PM branch.
Thanks,
Kevin
Best regards,
Sanjeev
diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
b/arch/arm/plat-omap/include/mach/omap-pm.h
index 583e540..2357784 100644
--- a/arch/arm/plat-omap/include/mach/omap-pm.h
+++ b/arch/arm/plat-omap/include/mach/omap-pm.h
@@ -33,6 +33,20 @@ struct omap_opp {
u16 vsel;
};
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
+
extern struct omap_opp *mpu_opps;
extern struct omap_opp *dsp_opps;
extern struct omap_opp *l3_opps;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..c90b1af 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -33,6 +33,7 @@
#include mach/powerdomain.h
#include mach/resource.h
#include mach/omap34xx.h
+#include mach/omap-pm.h
#include prm-regbits-34xx.h
#include pm.h
@@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
return error;
}
late_initcall(omap_pm_init);
+
+/*
+ * Get frequency corresponding to an OPP
+ */
+int opp_to_freq(unsigned int* freq, struct omap_opp_table* table, u8 opp)
+{
+int i, found=0;
+
+if (table table-opps) {
+for (i=table-min; table-opps[i].opp_id = table-max; i++)
+if (table-opps[i].opp_id == opp) {
+found = 1;
+break;
+}
+
+if (found) {
+*freq = table-opps[i].rate;
+return 1;
+}
+}
+
+return 0;
+}
+
+/*
+ * Get OPP corresponding to a frequency
+ */
+int freq_to_opp(u8* opp, struct omap_opp_table* table, unsigned long freq)
+{
+int i, found=0;
+
+if (table table-opps) {
+for (i=table-min; table-opps[i].opp_id = table-max; i++)
+if (table-opps[i].rate == freq) {
+found = 1;
+break;
+}
+
+if (found) {
+*opp = table-opps[i].opp_id;
+return 1;
+}
+}
+
+return 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
--
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] OMAP3 : PM : Handle variable length OPP tables
On Wed, Sep 30, 2009 at 11:10 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Premi, Sanjeev pr...@ti.com writes:
Hi all,
There is no generic function to translate an OPP to FREQ and vice versa.
Came across the problem while trying to submit a follow-up to earlier
patch for change in mpurate via bootargs.
The function get_opp in resource34xx.c, but it is always called with an
explicit addition of MAX_VDDn_OPP e.g.
opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk-rate);
opp = get_opp(l3_opps + MAX_VDD2_OPP, clk-rate);
This is 'addition' is required as there is no encapsulation of the
MIN and MAX VDDs associated to the table.
The patch below fixes this issue; buy creating a 'table' object with
necessary information. It can also help in getting rid of the
empty {0, 0, 0} at index 0 of each OPP table.
At the moment, it does not break any functionality in resource34xx.c;
migration to this encapsulation can be taken as next step.
This code is bare 'git-diff' for early comments. Formal patch to follow...
Looks ok. Please send updated patch against current PM branch.
oops, please ignore. I see you already posted a patch. Will comment there.
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] OMAP3 : PM : Functions to get freq from opp and vice-versa
Sanjeev Premi pr...@ti.com writes:
There is no generic function to get OPP corresponding to frequency
and vice versa.
Function get_opp() - in resource34xx.c - is included only when
CONFIG_OMAP_PM_SRF is enabled. Moreover, it is always called with
an explicit addition of MAX_VDDn_OPP e.g.
opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk-rate);
opp = get_opp(l3_opps + MAX_VDD2_OPP, clk-rate);
This is 'addition' is required as there is no encapsulation of
MIN and MAX VDDs associated to the table.
This patch fixes the issue by creating a 'table' object that
encapsulates the MIN and MAX values and the existing rate table.
Signed-off-by: Sanjeev Premi pr...@ti.com
Looks ok, minor comment below...
[...]
diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
b/arch/arm/plat-omap/include/mach/omap-pm.h
index 583e540..cf910ef 100644
--- a/arch/arm/plat-omap/include/mach/omap-pm.h
+++ b/arch/arm/plat-omap/include/mach/omap-pm.h
@@ -33,6 +33,20 @@ struct omap_opp {
u16 vsel;
};
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
+
extern struct omap_opp *mpu_opps;
extern struct omap_opp *dsp_opps;
extern struct omap_opp *l3_opps;
@@ -49,6 +63,17 @@ extern struct omap_opp *l3_opps;
#define OCP_INITIATOR_AGENT 2
/**
+ *
+ */
Either add a useful comment or remove the comment block (preferably the latter)
+int opp_to_freq(unsigned long* freq, const struct omap_opp_table* table, u8
opp);
+
+/**
+ *
+ */
ditto
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] OMAP3: PM: Enable GPIO module-level wakeups
On Thu, Sep 10, 2009 at 8:53 AM, Kevin Hilman khil...@deeprootsystems.com wrote: 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_pwrdm 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 mikec...@google.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Pushing to PM branch and queeing for 2.6.32 fixes. Kevin --- 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 3d62b06..8166118 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -918,6 +918,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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] omap3: ehci: remove chargepump hack
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: ehci Initial commit ID (Likely to change): 8aab384eab253c463f3eafae1c19bc44f744cdca PatchWorks http://patchwork.kernel.org/patch/49837/ 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=8aab384eab253c463f3eafae1c19bc44f744cdca -- 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 Fri, Sep 25, 2009 at 2:19 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Thu, 2009-09-24 at 17:52 +0200, ext Kevin Hilman wrote: Tomi Valkeinen wrote: If it is not like that, and the driver initialization is included, how does the PM layer know how long it takes for the DSS driver to reconfigure the DSS hardware from OFF mode? Currently it doesn't, but if you were measure it, we can use those numbers in the decision making process. Ok, now I see. However, I'm not sure if that will work. The problem is that the wakeup latency depends on many things. When using DPI/RFBI the wakeup is very fast. With SDI it's probably a bit slower and with DSI even slower. The varying latencies are not an issues. When in the different modes, just register a different latency requirement. And at least with DSI PLL, the wakeup time depends on the frequencies used (according to TRM), and in some cases it can be optimized, in some cases not. So I don't think there's one single value that fits all. A single value isn't necessary. Also, I still think it would be better if the driver was also able to prevent OFF mode explicitely. Defining the max-wakeup-lat with a magic number sounds a bit prone to breaking up. I disagree. What is important is that the driver communicates *why* it needs to prevent OFF mode (can't handle the latency etc.) and decision making up to the PM core. The drivers should not embed policy in them. But perhaps, as you said, when drivers work properly they don't have to care about OFF mode as such, but only about the wakeup latency, and thus the max-wakeup-lat is enough. I'm just not quite sure about that, as OFF mode may have side effects as the module is totally powered off, while with RET the side effects should be minimal. I don't have any concrete example about the side effects, but one particular thing I'm thinking about is DSI PLL. If DSS is in RET, I believe DSI PLL works normally. But if the DSS is reset via OFF mode, I believe DSI PLL is also reset. But I'm not sure if DSI PLL is ever needed while DSS would be off, so this may be theoretical =). Tomi This problem is not unique to DSS, and the other drivers are handling this. Therefore, I'm inclined to merge this patch to that it's clear that DSS support for OFF mode is broken and needs to be fixed. As a *temporary*, debug solution, I might accept a hack where DSS2 disables OFF mode explicitly, but this will not go upstream. 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] OMAP3: Lock DPLL5 at boot
* Gadiyar, Anand gadi...@ti.com [090930 09:59]: Thanks for the changes, I will queue this in a for-next branch for .33. Is this for .33 or .32? I think it might be a little late for .32. If there is some crash or instability that this fixes, we could queue it up for .32-fixes ? Well, without this, there's no way the child clocks can be enabled correctly. OK. So is it the case that USBHOST/USBTLL/USIM won't work without this fix? Yup. Not sure about USIM - will check. If so then we'll queue it for .32-fixes. Since .32 is already at -rc9, I think it is too late for .32. Would be nice. Thanks! Paul, Is this patch already queued up somewhere, or are you waiting for a clarification from me on the USIM? (I haven't had a chance to look yet, since this is not in the regular TRM) I'll add this to omap-fixes-testing while we're waiting to put his fixes queue together. This way we can get rid of the remaining nasty stuff in the ehci branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] omap3: ehci: remove DPLL5 programming
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: ehci Initial commit ID (Likely to change): aafbdf52d20fec172379c50af334165815af6eff PatchWorks http://patchwork.kernel.org/patch/50730/ 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=aafbdf52d20fec172379c50af334165815af6eff -- 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: PM: Fix compile time warning and errors
Sanjeev Premi pr...@ti.com writes:
Made a mistake of enabling PM_DEBUG without DEBUG_FS. This leads to
compile time warnings and errors.
arch/arm/mach-omap2/pm-debug.c:56: warning: 'pm_dbg_init'
declared 'static' but never defined
arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
arch/arm/mach-omap2/pm34xx.c:442: undefined reference to
'pm_dbg_regset_save'
arch/arm/mach-omap2/built-in.o: In function `configure_vc':
arch/arm/mach-omap2/pm34xx.c:1221: undefined reference to
'pm_dbg_regset_init'
Another alternate is to link these Kconfig options; but didn't seem
intuitive.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/pm-debug.c |2 ++
arch/arm/mach-omap2/pm34xx.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 1b4c160..175d461 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -53,7 +53,9 @@ int omap2_pm_debug;
regs[reg_count].name = #reg; \
regs[reg_count++].val = __raw_readl(OMAP2_IO_ADDRESS(0x480fe000 +
(off)))
+#ifdef CONFIG_DEBUG_FS
static int __init pm_dbg_init(void);
+#endif
Move this into the other #ifdef CONFIG_DEBUG_FS later in the same file.
void omap2_pm_dump(int mode, int resume, unsigned int us)
{
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7a1eb95..e3da0ab 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -438,8 +438,10 @@ void omap_sram_idle(void)
core_next_state == PWRDM_POWER_OFF)
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
+#ifdef CONFIG_DEBUG_FS
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+#endif
I don't like the #ifdefs here...
/*
* omap3_arm_context is the location where ARM registers
@@ -1218,7 +1220,9 @@ static void __init configure_vc(void)
prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTSETUP2_OFFSET);
+#ifdef CONFIG_DEBUG_FS
pm_dbg_regset_init(1);
+#endif
or here.
how about just adding dummy functions in pm-debug.c like this (on top
of your patch), then these #ifdefs can go away.
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 175d461..99855aa 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -578,4 +578,6 @@ arch_initcall(pm_dbg_init);
#else
void pm_dbg_update_time(struct powerdomain *pwrdm, int prev) {}
+int pm_dbg_regset_save(int reg_set) { return 0; }
+int pm_dbg_regset_init(int reg_set) { return 0; }
#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] OMAP: PM: Export functions from OMAP NOOP PM interface
Ameya Palande ameya.pala...@nokia.com writes:
Without this patch, a driver which uses these symbols will break when user
selects NOOP PM interface.
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Thanks, applying to PM branch.
Kevin
---
arch/arm/plat-omap/omap-pm-noop.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 3b075de..10463a4 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -157,6 +157,7 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void)
return NULL;
}
+EXPORT_SYMBOL(omap_pm_dsp_get_opp_table);
void omap_pm_dsp_set_min_opp(u8 opp_id)
{
@@ -181,7 +182,7 @@ void omap_pm_dsp_set_min_opp(u8 opp_id)
*
*/
}
-
+EXPORT_SYMBOL(omap_pm_dsp_set_min_opp);
u8 omap_pm_dsp_get_opp(void)
{
@@ -197,6 +198,7 @@ u8 omap_pm_dsp_get_opp(void)
return 0;
}
+EXPORT_SYMBOL(omap_pm_dsp_get_opp);
u8 omap_pm_vdd1_get_opp(void)
{
@@ -208,6 +210,7 @@ u8 omap_pm_vdd1_get_opp(void)
return 0;
}
+EXPORT_SYMBOL(omap_pm_vdd1_get_opp);
u8 omap_pm_vdd2_get_opp(void)
{
@@ -219,6 +222,7 @@ u8 omap_pm_vdd2_get_opp(void)
return 0;
}
+EXPORT_SYMBOL(omap_pm_vdd2_get_opp);
/*
* CPUFreq-originated constraint
@@ -259,6 +263,7 @@ void omap_pm_cpu_set_freq(unsigned long f)
* CDP should just be able to set the VDD1 OPP clock rate here.
*/
}
+EXPORT_SYMBOL(omap_pm_cpu_set_freq);
unsigned long omap_pm_cpu_get_freq(void)
{
@@ -270,6 +275,7 @@ unsigned long omap_pm_cpu_get_freq(void)
return 0;
}
+EXPORT_SYMBOL(omap_pm_cpu_get_freq);
/*
* Device context loss tracking
--
1.6.2.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
--
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] input: fix rx51 board keymap
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes-testing Initial commit ID (Likely to change): 0e7258642f113e8d637f454ab96816194f3ef996 PatchWorks http://patchwork.kernel.org/patch/50697/ 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=0e7258642f113e8d637f454ab96816194f3ef996 -- 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] Support OMAP3 VC adaptation with different Power IC
sawsd wang sawsdw...@gmail.com writes:
From c1aba8ba7af3ddd16346d95795bda71e65baa4d0 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 06:48:52 +0800
Subject: [PATCH] Support OMAP3 VC adaptation with different Power IC
Current OMAP SmartReflex driver only supports TI Triton
Power IC, add a callback to make it possible to use
different PowerIC and use different settings to
configure OMAP3 Voltage Controller for DVFS
Board file can setup a new function to have different settings
on SR to configure their Power IC for voltage scaling
Signed-off-by: Chunqiu Wang cqw...@motorola.com
Are there any plans to update this patch to fix line-wrapping and
patch apply issues?
If not, I will drop it from my incoming queue.
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 13 +
arch/arm/mach-omap2/smartreflex.h |4
arch/arm/plat-omap/Kconfig|2 +-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9d462e3..bacf602 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -52,6 +52,8 @@ struct omap_sr {
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
+static omap3_voltagescale_vcbypass_t omap3_volscale_vcbypass_fun;
+
static inline void sr_write_reg(struct omap_sr *sr, unsigned offset, u32
value)
{
__raw_writel(value, SR_REGADDR(offset));
@@ -767,6 +769,11 @@ void disable_smartreflex(int srid)
}
}
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t fun)
+{
+ omap3_volscale_vcbypass_fun = fun;
+}
+
/* Voltage Scaling using SR VCBYPASS */
int sr_voltagescale_vcbypass(u32 target_opp, u32 current_opp,
u8 target_vsel, u8 current_vsel)
@@ -779,6 +786,10 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
+ if (omap3_volscale_vcbypass_fun)
+ return omap3_volscale_vcbypass_fun(target_opp, current_opp,
+ target_vsel, current_vsel);
+
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
current_opp_no = get_opp_no(current_opp);
@@ -940,6 +951,7 @@ static int __init omap3_sr_init(void)
return -ENODEV;
}
+#ifdef CONFIG_TWL4030_CORE
/* Enable SR on T2 */
ret = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
@@ -947,6 +959,7 @@ static int __init omap3_sr_init(void)
RdReg |= DCDC_GLOBAL_CFG_ENABLE_SRFLX;
ret |= twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, RdReg,
R_DCDC_GLOBAL_CFG);
+#endif
if (cpu_is_omap34xx()) {
sr1.clk = clk_get(NULL, sr1_fck);
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 2a0e823..c4aca9d 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -248,9 +248,13 @@ void disable_smartreflex(int srid);
int sr_voltagescale_vcbypass(u32 t_opp, u32 c_opp, u8 t_vsel, u8 c_vsel);
void sr_start_vddautocomap(int srid, u32 target_opp_no);
int sr_stop_vddautocomap(int srid);
+typedef int (*omap3_voltagescale_vcbypass_t)(u32 t_opp, u32 c_opp,
+ u8 t_vsel, u8 c_vsel);
+void omap3_voltagescale_vcbypass_setup(omap3_voltagescale_vcbypass_t fun);
#else
static inline void enable_smartreflex(int srid) {}
static inline void disable_smartreflex(int srid) {}
+#define omap3_voltagescale_vcbypass_setup(fun) do {} while (0);
#endif
#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index c8ba1e2..8d2c607 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -68,7 +68,7 @@ config OMAP_DEBUG_CLOCKDOMAIN
config OMAP_SMARTREFLEX
bool SmartReflex support
- depends on ARCH_OMAP34XX TWL4030_CORE PM
+ depends on ARCH_OMAP34XX PM
help
Say Y if you want to enable SmartReflex.
--
1.5.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
--
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 2/2] OMAP3: Implement separate function to send bypass command through VC
sawsd wang sawsdw...@gmail.com writes:
From 803cbdcd8df3d6f931089979c2dbad8942512cb4 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 24 Jun 2009 07:57:17 +0800
Subject: [PATCH] OMAP3: Implement separate function to send bypass
command through VC
Some system may need use OMAP VC to configure their Power IC,
so make the common code to send bypass command using SR VC
Signed-off-by: Chunqiu Wang cqw...@motorola.com
Are there any plans to update this patch to fix line-wrapping and
patch apply issues?
If not, I will drop it from my incoming queue.
Kevin
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 36 ++
arch/arm/mach-omap2/smartreflex.c | 59 +++-
3 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ddc9453..fa118cd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -44,6 +44,7 @@ extern int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state);
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
extern void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc);
+extern int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd);
#ifdef CONFIG_CPU_IDLE
int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7a4a525..85b0944 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -1135,6 +1136,41 @@ err2:
return ret;
}
+/* Program Power IC via OMAP3 voltage controller bypass interface */
+int omap3_vc_bypass_cmd(u8 slave_addr, u8 reg_addr, u8 cmd)
+{
+ u32 vc_bypass_value;
+ u32 loop_cnt = 0, retries_cnt = 0;
+
+ vc_bypass_value = (cmd OMAP3430_DATA_SHIFT) |
+ (reg_addr OMAP3430_REGADDR_SHIFT) |
+ (slave_addr OMAP3430_SLAVEADDR_SHIFT);
+
+ prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
+ loop_cnt++;
+ if (retries_cnt 10) {
+ printk(KERN_ERRLoop count exceeded in check SR I2C
+ write\n);
+ return 1;
+ }
+ if (loop_cnt 50) {
+ retries_cnt++;
+ loop_cnt = 0;
+ udelay(10);
+ }
+ vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+ }
+
+ return 0;
+}
+
static void __init configure_vc(void)
{
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index bacf602..2158b5c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -35,6 +35,7 @@
#include prm.h
#include smartreflex.h
#include prm-regbits-34xx.h
+#include pm.h
struct omap_sr {
int srid;
@@ -449,8 +450,6 @@ static int sr_reset_voltage(int srid)
{
u32 target_opp_no, vsel = 0;
u32 reg_addr = 0;
- u32 loop_cnt = 0, retries_cnt = 0;
- u32 vc_bypass_value;
u32 t2_smps_steps = 0;
u32 t2_smps_delay = 0;
u32 prm_vp1_voltage, prm_vp2_voltage;
@@ -479,31 +478,8 @@ static int sr_reset_voltage(int srid)
t2_smps_steps = abs(vsel - prm_vp2_voltage);
}
- vc_bypass_value = (vsel OMAP3430_DATA_SHIFT) |
- (reg_addr OMAP3430_REGADDR_SHIFT) |
- (R_SRI2C_SLAVE_ADDR OMAP3430_SLAVEADDR_SHIFT);
-
- prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
- OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
-
- while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
- loop_cnt++;
- if (retries_cnt 10) {
- pr_info(Loop count exceeded in check SR I2C
- write\n);
- return 1;
- }
- if (loop_cnt 50) {
- retries_cnt++;
- loop_cnt = 0;
- udelay(10);
- }
- vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
-
Re: [PATCH] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
On Mon, Aug 3, 2009 at 3:11 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Ben Dooks wrote:
On Tue, Jul 21, 2009 at 04:09:03PM -0700, Kevin Hilman wrote:
From: Rajendra Nayak rna...@ti.com
Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.
Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)
Also, The OMAP3430 TRM states:
During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
result in unpredictable behavior.
Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
should this be applied as a bugfix, or kept for next merge window?
next merge window is fine.
Ben,
It doesn't look like this made it in during the 2.6.32 merge window.
Can you queue it for the -rc series?
Kevin
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Hu Tao ta...@motorola.com
Cc: Xiaolong Chen a21...@motorola.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
This patch has been tested extensively as part of the OMAP 'PM branch'
drivers/i2c/busses/i2c-omap.c | 64
++--
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
b/drivers/i2c/busses/i2c-omap.c
index ad8d201..bb8ae50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -178,6 +178,12 @@ struct omap_i2c_dev {
unsigned b_hw:1; /* bad h/w fixes */
unsigned idle:1;
u16 iestate; /* Saved interrupt
register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
+ u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -230,9 +236,18 @@ static void omap_i2c_unidle(struct omap_i2c_dev
*dev)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG,
dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG,
dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
dev-syscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
OMAP_I2C_CON_EN);
+ }
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -258,7 +273,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
SYSC_AUTOIDLE_MASK);
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
- u32 v;
-
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev-syscstate);
/*
* Enabling all wakup sources to stop I2C freezing
on
* WFI instruction.
Re: [PATCH] omap: resource: Fix race in register_resource()
Mike Chan m...@android.com writes:
Checking if the resource is already registered and adding to the list
must be atomic or bad things can happen.
Signed-off-by: Mike Chan m...@android.com
---
arch/arm/plat-omap/resource.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 111020a..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -255,6 +255,7 @@ int resource_refresh(void)
*/
int resource_register(struct shared_resource *resp)
{
+ int ret = 0;
if (!resp)
return -EINVAL;
@@ -262,12 +263,13 @@ int resource_register(struct shared_resource *resp)
return -EINVAL;
/* Verify that the resource is not already registered */
- if (resource_lookup(resp-name))
- return -EEXIST;
+ down(res_mutex);
+ if (_resource_lookup(resp-name))
+ ret = -EEXIST;
+ goto out;
Ahem, you're rebased version has a little problem. Missing {} block
mans this goto is always executed and no resources are ever added.
I'll fix this up manually before applying, but some more testing next
time would be helpful
Thanks,
Kevin
INIT_LIST_HEAD(resp-users_list);
- down(res_mutex);
/* Add the resource to the resource list */
list_add(resp-node, res_list);
@@ -275,10 +277,11 @@ int resource_register(struct shared_resource *resp)
if (resp-ops-init)
resp-ops-init(resp);
- up(res_mutex);
pr_debug(resource: registered %s\n, resp-name);
- return 0;
+out:
+ up(res_mutex);
+ return ret;
}
EXPORT_SYMBOL(resource_register);
--
1.5.4.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] omap: resource: Fix race in register_resource()
On Wed, Sep 30, 2009 at 4:49 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Mike Chan m...@android.com writes:
Checking if the resource is already registered and adding to the list
must be atomic or bad things can happen.
Signed-off-by: Mike Chan m...@android.com
---
arch/arm/plat-omap/resource.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 111020a..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -255,6 +255,7 @@ int resource_refresh(void)
*/
int resource_register(struct shared_resource *resp)
{
+ int ret = 0;
if (!resp)
return -EINVAL;
@@ -262,12 +263,13 @@ int resource_register(struct shared_resource *resp)
return -EINVAL;
/* Verify that the resource is not already registered */
- if (resource_lookup(resp-name))
- return -EEXIST;
+ down(res_mutex);
+ if (_resource_lookup(resp-name))
+ ret = -EEXIST;
+ goto out;
Ahem, you're rebased version has a little problem. Missing {} block
mans this goto is always executed and no resources are ever added.
I'll fix this up manually before applying, but some more testing next
time would be helpful
Opps, sorry about that :/ and thanks for cleaning it up.
-- Mike
Thanks,
Kevin
INIT_LIST_HEAD(resp-users_list);
- down(res_mutex);
/* Add the resource to the resource list */
list_add(resp-node, res_list);
@@ -275,10 +277,11 @@ int resource_register(struct shared_resource *resp)
if (resp-ops-init)
resp-ops-init(resp);
- up(res_mutex);
pr_debug(resource: registered %s\n, resp-name);
- return 0;
+out:
+ up(res_mutex);
+ return ret;
}
EXPORT_SYMBOL(resource_register);
--
1.5.4.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: linux-omap git tree updated to v2.6.32-rc1, important changes, please read
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, September 30, 2009 11:25 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org
Subject: Re: linux-omap git tree updated to v2.6.32-rc1, important changes,
please read
Hi,
* Shilimkar, Santosh santosh.shilim...@ti.com [090929 03:54]:
snip
Thanks for fixing the OMAP4 compilation issues. We need below patch to
make the kernel boot on OMAP4430 on the latest LO master.
No problem. In the future, let's make sure the omap4 patches are merged
into l-o master branch for testing. This time the first three patches
in the omap-fixes branch were build breakage caused by the omap4 patches
directly or indirectly..
Agree!!
Also, please everybody check that your patches don't break the build
for other the omaps, and also boot test on some other omaps if someting
looks risky.
Few comments below.
From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430
board
This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().
The opps probably should be oops above :)
YEP :)
Additionally the patch removed the merge issue for the UART4.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/io.c|2 ++
arch/arm/mach-omap2/serial.c| 10 --
3 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
static void __init omap_4430sdp_init_irq(void)
{
+ omap_board_config = sdp4430_config;
+ omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap2_init_common_hw(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_board_config = sdp4430_config;
- omap_board_config_size = ARRAY_SIZE(sdp4430_config);
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct
omap_sdrc_params *sdrc_cs0,
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
+#endif
omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
omap_hwmod_late_init();
omap_pm_if_init();
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port
serial_platform_data2[] = {
.regshift = 2,
.uartclk= OMAP24XX_BASE_BAUD * 16,
}, {
-#ifdef CONFIG_ARCH_OMAP4
- .membase= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
-#endif
.flags = 0
}
};
Can't we fix the extra uart instead of removing it? We just added it!
It's still there in omap4, right?
This is already fixed. Above piece is not necessary since there is a separate
instance for UART4 (serial_platform_data3[])
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
