[RFC v2][PATCH 0/7] OMAP: DSS2: Overlay Manager LCD2 support in DISPC
From: Semwal, Sumit sumit.sem...@ti.com This patch series which incorporates changes in DSS2 to enable omap_dss_device instances to use the new Overlay Manager LCD2 in DISPC. On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This channel's video port is a source port for RFBI, DSI2 and DPI. The Primary channel's video port is connected to RFBI and DSI1. There is a set of regsiters for LCD2 channel similar to the existing LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on. In order to decide which LCD Overlay Manager to configure(LCD/LCD2), there is a need for the omap_dss_device instances to tell the interface drivers(DSI, DPI, RFBI etc) which LCD channel they want to connect to, so that the corresponding registers get configured. Therefore, a new enum omap_channel member is introduced to omap_dss_device. This design was made keeping in mind the possible addition of more Overlay Managers in future OMAPs, this code is also backward compatible with OMAP3 as omap_dss_device instances in OMAP3 will stick only with OMAP_DSS_CHANNEL_LCD. Sumit Semwal (6): OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h OMAP: DSS2: Add new Overlay Manager OMAP: DSS2: Modify dss_recheck_connections OMAP: DSS2: Incorporate Secondary LCD Channel DISPC Registers OMAP: DSS2: Secondary LCD Channel DISPC IRQs OMAP: DSS2: Interface driver changes for Secondary LCD Channel Mayuresh Janorkar (1) OMAP: DSS2: Context Save and Restore of DISPC registers for Secondary LCD arch/arm/plat-omap/include/plat/display.h |7 + drivers/video/omap2/dss/core.c|2 +- drivers/video/omap2/dss/dispc.c | 626 +++-- drivers/video/omap2/dss/dpi.c | 38 +- drivers/video/omap2/dss/dsi.c | 24 +- drivers/video/omap2/dss/dss.h | 39 ++- drivers/video/omap2/dss/manager.c | 89 +++-- drivers/video/omap2/dss/overlay.c | 14 +- drivers/video/omap2/dss/rfbi.c| 21 +- drivers/video/omap2/dss/sdi.c | 22 +- 10 files changed, 571 insertions(+), 311 deletions(-) -- Version 2: - The DISPC_BASE macro now isn't changed for OMAP4, a future hwmod patch will take care of this dynamically. - Supported_displays member of manager is now assigned correctly for OMAP2. - DISPC Registers common to LCD and LCD2 channels are not defined separately, now there is a parameter which differentiates between the 2 channels. - Secondary LCD manager is now named as lcd2 instead of 2lcd, the patch given in the link below allows DSS2 interpret this correctly. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31714.html Version 1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31458.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
[RFC v2][PATCH 1/7] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h
From: Sumit Semwal sumit.sem...@ti.com
Overlay Manager LCD2 changes in dispay.h
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 8bd15bd..c3643f5
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -64,6 +64,7 @@ enum omap_plane {
enum omap_channel {
OMAP_DSS_CHANNEL_LCD= 0,
OMAP_DSS_CHANNEL_DIGIT = 1,
+ OMAP_DSS_CHANNEL_LCD2 = 2,
};
enum omap_color_mode {
@@ -173,6 +174,7 @@ enum omap_dss_display_state {
enum omap_dss_overlay_managers {
OMAP_DSS_OVL_MGR_LCD,
OMAP_DSS_OVL_MGR_TV,
+ OMAP_DSS_OVL_MGR_LCD2,
};
enum omap_dss_rotation_type {
@@ -462,6 +464,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
/* platform specific */
int (*platform_enable)(struct omap_dss_device *dssdev);
--
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
[RFC v2][PATCH 2/7] OMAP: DSS2: Add new Overlay Manager
From: Sumit Semwal sumit.sem...@ti.com
Add new Overlay Manager in manager.c, make secondary channel changes
and update supported displays for the managers in OMAP4
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/video/omap2/dss/manager.c | 56 ++--
1 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 6a649ab..8b6ff98
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -34,6 +34,8 @@
#include dss.h
+#define MAX_DSS_MANAGERS (cpu_is_omap44xx() ? 3 : 2)
+
static int num_managers;
static struct list_head manager_list;
@@ -449,7 +451,7 @@ struct manager_cache_data {
static struct {
spinlock_t lock;
struct overlay_cache_data overlay_cache[3];
- struct manager_cache_data manager_cache[2];
+ struct manager_cache_data manager_cache[3];
bool irq_enabled;
} dss_cache;
@@ -531,10 +533,9 @@ static int dss_mgr_wait_for_go(struct omap_overlay_manager
*mgr)
if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
return 0;
-
+ channel = mgr-device-channel;
if (dssdev-type == OMAP_DISPLAY_TYPE_VENC) {
irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN;
- channel = OMAP_DSS_CHANNEL_DIGIT;
} else {
if (dssdev-caps OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
enum omap_dss_update_mode mode;
@@ -546,7 +547,6 @@ static int dss_mgr_wait_for_go(struct omap_overlay_manager
*mgr)
} else {
irq = DISPC_IRQ_VSYNC;
}
- channel = OMAP_DSS_CHANNEL_LCD;
}
mc = dss_cache.manager_cache[mgr-id];
@@ -604,13 +604,13 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
return 0;
dssdev = ovl-manager-device;
+ channel = dssdev-channel;
if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
return 0;
if (dssdev-type == OMAP_DISPLAY_TYPE_VENC) {
irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN;
- channel = OMAP_DSS_CHANNEL_DIGIT;
} else {
if (dssdev-caps OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
enum omap_dss_update_mode mode;
@@ -622,7 +622,6 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
} else {
irq = DISPC_IRQ_VSYNC;
}
- channel = OMAP_DSS_CHANNEL_LCD;
}
oc = dss_cache.overlay_cache[ovl-id];
@@ -841,7 +840,8 @@ static int configure_overlay(enum omap_plane plane)
c-rotation_type,
c-rotation,
c-mirror,
- c-global_alpha);
+ c-global_alpha,
+ c-channel);
if (r) {
/* this shouldn't happen */
@@ -883,20 +883,20 @@ static int configure_dispc(void)
struct overlay_cache_data *oc;
struct manager_cache_data *mc;
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_mgrs = MAX_DSS_MANAGERS;
int i;
int r;
- bool mgr_busy[2];
- bool mgr_go[2];
+ bool mgr_busy[MAX_DSS_MANAGERS];
+ bool mgr_go[MAX_DSS_MANAGERS];
bool busy;
r = 0;
busy = false;
- mgr_busy[0] = dispc_go_busy(0);
- mgr_busy[1] = dispc_go_busy(1);
- mgr_go[0] = false;
- mgr_go[1] = false;
+ for (i = 0; i num_mgrs; i++) {
+ mgr_busy[i] = dispc_go_busy(i);
+ mgr_go[i] = false;
+ }
/* Commit overlay settings */
for (i = 0; i num_ovls; ++i) {
@@ -1122,7 +1122,7 @@ void dss_start_update(struct omap_dss_device *dssdev)
struct manager_cache_data *mc;
struct overlay_cache_data *oc;
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
- const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
+ const int num_mgrs = MAX_DSS_MANAGERS;
struct omap_overlay_manager *mgr;
int i;
@@ -1154,10 +1154,10 @@ static void dss_apply_irq_handler(void *data, u32 mask)
const int num_ovls = ARRAY_SIZE(dss_cache.overlay_cache);
const int num_mgrs = ARRAY_SIZE(dss_cache.manager_cache);
int i, r;
- bool mgr_busy[2];
+ bool mgr_busy[MAX_DSS_MANAGERS];
- mgr_busy[0] = dispc_go_busy(0);
- mgr_busy[1] = dispc_go_busy(1);
+ for (i = 0; i num_mgrs; i++)
+ mgr_busy[i] = dispc_go_busy(i);
spin_lock(dss_cache.lock);
@@ -1461,7 +1461,7 @@
[RFC v2][PATCH 3/7] OMAP: DSS2: Modify dss_recheck_connections
From: Sumit Semwal sumit.sem...@ti.com
The addition of the new lcd2 manager requires modifications in the
dss_recheck_connections patch, this function behaves the same if
the lcd2 manager doesn't exist
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/video/omap2/dss/overlay.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 244dca8..29aa157
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -627,12 +627,22 @@ void dss_recheck_connections(struct omap_dss_device
*dssdev, bool force)
int i;
struct omap_overlay_manager *lcd_mgr;
struct omap_overlay_manager *tv_mgr;
+ struct omap_overlay_manager *lcd2_mgr = NULL;
struct omap_overlay_manager *mgr = NULL;
lcd_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_LCD);
tv_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_TV);
-
- if (dssdev-type != OMAP_DISPLAY_TYPE_VENC) {
+ if (cpu_is_omap44xx())
+ lcd2_mgr = omap_dss_get_overlay_manager(OMAP_DSS_OVL_MGR_LCD2);
+
+ if (dssdev-channel == OMAP_DSS_CHANNEL_LCD2) {
+ if (!lcd2_mgr-device || force) {
+ if (lcd2_mgr-device)
+ lcd2_mgr-unset_device(lcd2_mgr);
+ lcd2_mgr-set_device(lcd2_mgr, dssdev);
+ mgr = lcd2_mgr;
+ }
+ } else if (dssdev-type != OMAP_DISPLAY_TYPE_VENC) {
if (!lcd_mgr-device || force) {
if (lcd_mgr-device)
lcd_mgr-unset_device(lcd_mgr);
--
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
[RFC v2][PATCH 4/7] OMAP: DSS2: Incorporate Secondary LCD Channel DISPC Registers
From: Sumit Semwal sumit.sem...@ti.com
Introduce OMAP4 DISPC Secondary LCD Channel registers and the new enum channel
as a parameter in all dispc functions used by interface drivers(dsi, sdi etc)
in order to differentiate between the 2 channels.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/video/omap2/dss/dispc.c | 524 +++
drivers/video/omap2/dss/dss.h | 31 ++-
2 files changed, 335 insertions(+), 220 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5ecdc00..060768a
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -55,22 +55,31 @@ struct dispc_reg { u16 idx; };
#define DISPC_SYSSTATUSDISPC_REG(0x0014)
#define DISPC_IRQSTATUSDISPC_REG(0x0018)
#define DISPC_IRQENABLEDISPC_REG(0x001C)
-#define DISPC_CONTROL DISPC_REG(0x0040)
-#define DISPC_CONFIG DISPC_REG(0x0044)
+#define DISPC_CONTROL(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0040) : (0x0238))
+#define DISPC_CONFIG(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0044) : (0x0620))
#define DISPC_CAPABLE DISPC_REG(0x0048)
-#define DISPC_DEFAULT_COLOR0 DISPC_REG(0x004C)
-#define DISPC_DEFAULT_COLOR1 DISPC_REG(0x0050)
-#define DISPC_TRANS_COLOR0 DISPC_REG(0x0054)
-#define DISPC_TRANS_COLOR1 DISPC_REG(0x0058)
+#define DISPC_DEFAULT_COLOR(ch)DISPC_REG(ch == OMAP_DSS_CHANNEL_LCD \
+ ? (0x004C) : (ch == OMAP_DSS_CHANNEL_DIGIT ? \
+ (0x0050) : (0x03AC)))
+#define DISPC_TRANS_COLOR(ch) DISPC_REG(ch == OMAP_DSS_CHANNEL_LCD \
+ ? (0x0054) : (ch == OMAP_DSS_CHANNEL_DIGIT ? \
+ (0x0058) : (0x03B0)))
#define DISPC_LINE_STATUS DISPC_REG(0x005C)
#define DISPC_LINE_NUMBER DISPC_REG(0x0060)
-#define DISPC_TIMING_H DISPC_REG(0x0064)
-#define DISPC_TIMING_V DISPC_REG(0x0068)
-#define DISPC_POL_FREQ DISPC_REG(0x006C)
-#define DISPC_DIVISOR DISPC_REG(0x0070)
+#define DISPC_TIMING_H(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0064) : (0x0400))
+#define DISPC_TIMING_V(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0068) : (0x0404))
+#define DISPC_POL_FREQ(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x006C) : (0x0408))
+#define DISPC_DIVISOR(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0070) : (0x040C))
#define DISPC_GLOBAL_ALPHA DISPC_REG(0x0074)
#define DISPC_SIZE_DIG DISPC_REG(0x0078)
-#define DISPC_SIZE_LCD DISPC_REG(0x007C)
+#define DISPC_SIZE_LCD(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x007C) : (0x03CC))
/* DISPC GFX plane */
#define DISPC_GFX_BA0 DISPC_REG(0x0080)
@@ -85,13 +94,19 @@ struct dispc_reg { u16 idx; };
#define DISPC_GFX_WINDOW_SKIP DISPC_REG(0x00B4)
#define DISPC_GFX_TABLE_BA DISPC_REG(0x00B8)
-#define DISPC_DATA_CYCLE1 DISPC_REG(0x01D4)
-#define DISPC_DATA_CYCLE2 DISPC_REG(0x01D8)
-#define DISPC_DATA_CYCLE3 DISPC_REG(0x01DC)
-
-#define DISPC_CPR_COEF_R DISPC_REG(0x0220)
-#define DISPC_CPR_COEF_G DISPC_REG(0x0224)
-#define DISPC_CPR_COEF_B DISPC_REG(0x0228)
+/* LCD channels, channel= 0 for primary and n = 2 for secondary */
+#define DISPC_DATA_CYCLE1(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x01D4) : (0x03C0))
+#define DISPC_DATA_CYCLE2(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x01D8) : (0x03C4))
+#define DISPC_DATA_CYCLE3(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x01DC) : (0x03C8))
+#define DISPC_CPR_COEF_R(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0220) : (0x03BC))
+#define DISPC_CPR_COEF_G(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0224) : (0x03B8))
+#define DISPC_CPR_COEF_B(ch) DISPC_REG(ch != OMAP_DSS_CHANNEL_LCD2 ? \
+ (0x0228) : (0x03B4))
#define DISPC_GFX_PRELOAD
[RFC v2][PATCH 5/7] OMAP: DSS2: Secondary LCD Channel DISPC IRQs
From: Sumit Semwal sumit.sem...@ti.com
Introduce Secondary Channel IRQS for dumps and error handling
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |4 ++
drivers/video/omap2/dss/dispc.c | 59 +++-
drivers/video/omap2/dss/manager.c | 33 +++-
3 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index c3643f5..56e7045
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -42,6 +42,10 @@
#define DISPC_IRQ_SYNC_LOST(1 14)
#define DISPC_IRQ_SYNC_LOST_DIGIT (1 15)
#define DISPC_IRQ_WAKEUP (1 16)
+#define DISPC_IRQ_SYNC_LOST_2 (1 17)
+#define DISPC_IRQ_VSYNC2 (1 18)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 21)
+#define DISPC_IRQ_FRAMEDONE2 (1 22)
struct omap_dss_device;
struct omap_overlay_manager;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 060768a..c7811b4
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -144,7 +144,9 @@ struct dispc_reg { u16 idx; };
DISPC_IRQ_VID1_FIFO_UNDERFLOW | \
DISPC_IRQ_VID2_FIFO_UNDERFLOW | \
DISPC_IRQ_SYNC_LOST | \
-DISPC_IRQ_SYNC_LOST_DIGIT)
+DISPC_IRQ_SYNC_LOST_DIGIT | \
+(cpu_is_omap44xx() ? \
+DISPC_IRQ_SYNC_LOST_2 : 0))
#define DISPC_MAX_NR_ISRS 8
@@ -1788,6 +1790,7 @@ static void dispc_enable_lcd_out(enum omap_channel
channel, bool enable)
struct completion frame_done_completion;
bool is_on;
int r;
+ int irq;
enable_clocks(1);
@@ -1796,12 +1799,17 @@ static void dispc_enable_lcd_out(enum omap_channel
channel, bool enable)
* prevents DSS from going to OFF mode */
is_on = REG_GET(DISPC_CONTROL(channel), 0, 0);
+ if (OMAP_DSS_CHANNEL_LCD2 == channel)
+ irq = DISPC_IRQ_FRAMEDONE2;
+ else
+ irq = DISPC_IRQ_FRAMEDONE;
+
if (!enable is_on) {
init_completion(frame_done_completion);
r = omap_dispc_register_isr(dispc_disable_isr,
frame_done_completion,
- DISPC_IRQ_FRAMEDONE);
+ irq);
if (r)
DSSERR(failed to register FRAMEDONE isr\n);
@@ -1816,7 +1824,7 @@ static void dispc_enable_lcd_out(enum omap_channel
channel, bool enable)
r = omap_dispc_unregister_isr(dispc_disable_isr,
frame_done_completion,
- DISPC_IRQ_FRAMEDONE);
+ irq);
if (r)
DSSERR(failed to unregister FRAMEDONE isr\n);
@@ -2412,6 +2420,12 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(SYNC_LOST);
PIS(SYNC_LOST_DIGIT);
PIS(WAKEUP);
+ if (cpu_is_omap44xx()) {
+ PIS(FRAMEDONE2);
+ PIS(VSYNC2);
+ PIS(ACBIAS_COUNT_STAT2);
+ PIS(SYNC_LOST_2);
+ }
#undef PIS
}
#endif
@@ -3013,6 +3027,45 @@ static void dispc_error_worker(struct work_struct *work)
}
}
+ if (errors DISPC_IRQ_SYNC_LOST_2) {
+ struct omap_overlay_manager *manager = NULL;
+ bool enable = false;
+
+ DSSERR(SYNC_LOST for LCD2, disabling LCD2\n);
+
+ for (i = 0; i omap_dss_get_num_overlay_managers(); ++i) {
+ struct omap_overlay_manager *mgr;
+ mgr = omap_dss_get_overlay_manager(i);
+
+ if (mgr-id == OMAP_DSS_CHANNEL_LCD2) {
+ manager = mgr;
+ enable = mgr-device-state ==
+ OMAP_DSS_DISPLAY_ACTIVE;
+ mgr-device-driver-disable(mgr-device);
+ break;
+ }
+ }
+
+ if (manager) {
+ for (i = 0; i omap_dss_get_num_overlays(); ++i) {
+ struct omap_overlay *ovl;
+ ovl = omap_dss_get_overlay(i);
+
+ if (!(ovl-caps OMAP_DSS_OVL_CAP_DISPC))
+ continue;
+
+ if
[RFC v2][PATCH 6/7] OMAP: DSS2: Context Save Restore of DISPC registers for secondary LCD
From: Mayuresh Janorkar ma...@ti.com
Context Save and Restore of DISPC registers for Secondary LCD
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/video/omap2/dss/dispc.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index c7811b4..9f83f7e
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -230,6 +230,17 @@ void dispc_save_context(void)
SR(SIZE_DIG);
SR(SIZE_LCD(0));
+ if (cpu_is_omap44xx()) {
+ SR(CONTROL(2));
+ SR(DEFAULT_COLOR(2));
+ SR(TRANS_COLOR(2));
+ SR(SIZE_LCD(2));
+ SR(TIMING_H(2));
+ SR(TIMING_V(2));
+ SR(POL_FREQ(2));
+ SR(DIVISOR(2));
+ SR(CONFIG(2));
+ }
SR(GFX_BA0);
SR(GFX_BA1);
SR(GFX_POSITION);
@@ -249,6 +260,15 @@ void dispc_save_context(void)
SR(CPR_COEF_G(0));
SR(CPR_COEF_B(0));
+ if (cpu_is_omap44xx()) {
+ SR(CPR_COEF_B(2));
+ SR(CPR_COEF_G(2));
+ SR(CPR_COEF_R(2));
+
+ SR(DATA_CYCLE1(2));
+ SR(DATA_CYCLE2(2));
+ SR(DATA_CYCLE3(2));
+ }
SR(GFX_PRELOAD);
/* VID1 */
@@ -369,6 +389,22 @@ void dispc_restore_context(void)
RR(SIZE_DIG);
RR(SIZE_LCD(0));
+ if (cpu_is_omap44xx()) {
+ RR(DEFAULT_COLOR(2));
+ RR(TRANS_COLOR(2));
+ RR(CPR_COEF_B(2));
+ RR(CPR_COEF_G(2));
+ RR(CPR_COEF_R(2));
+ RR(DATA_CYCLE1(2));
+ RR(DATA_CYCLE2(2));
+ RR(DATA_CYCLE3(2));
+ RR(SIZE_LCD(2));
+ RR(TIMING_H(2));
+ RR(TIMING_V(2));
+ RR(POL_FREQ(2));
+ RR(DIVISOR(2));
+ RR(CONFIG(2));
+ }
RR(GFX_BA0);
RR(GFX_BA1);
RR(GFX_POSITION);
@@ -490,7 +526,8 @@ void dispc_restore_context(void)
/* enable last, because LCD DIGIT enable are here */
RR(CONTROL(0));
-
+ if (cpu_is_omap44xx())
+ RR(CONTROL(2));
/* clear spurious SYNC_LOST_DIGIT interrupts */
dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
--
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
[RFC v2][PATCH 7/7] OMAP: DSS2: Interface driver changes for Secondary LCD Channel
From: Sumit Semwal sumit.sem...@ti.com
Make necessary changes in the interface drivers for the dispc
functions which have the new enum channel added to them
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/video/omap2/dss/core.c |2 +-
drivers/video/omap2/dss/dpi.c | 38 +-
drivers/video/omap2/dss/dsi.c | 24 +---
drivers/video/omap2/dss/dss.h |8 +---
drivers/video/omap2/dss/rfbi.c | 21 -
drivers/video/omap2/dss/sdi.c | 22 --
6 files changed, 64 insertions(+), 51 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b3a498f..e4909ad
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -411,7 +411,7 @@ static void dss_debug_dump_clocks(struct seq_file *s)
dss_dump_clocks(s);
dispc_dump_clocks(s);
#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_dump_clocks(s);
+ dsi_dump_clocks(OMAP_DSS_CHANNEL_LCD, s);
#endif
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 960e977..592c0c0
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -40,8 +40,9 @@ static struct {
} dpi;
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
-static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
- unsigned long *fck, int *lck_div, int *pck_div)
+static int dpi_set_dsi_clk(enum omap_channel channel, bool is_tft,
+ unsigned long pck_req, unsigned long *fck, int *lck_div,
+ int *pck_div)
{
struct dsi_clock_info dsi_cinfo;
struct dispc_clock_info dispc_cinfo;
@@ -58,7 +59,7 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
dss_select_dispc_clk_source(DSS_SRC_DSI1_PLL_FCLK);
- r = dispc_set_clock_div(dispc_cinfo);
+ r = dispc_set_clock_div(channel, dispc_cinfo);
if (r)
return r;
@@ -69,8 +70,9 @@ static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
return 0;
}
#else
-static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,
- unsigned long *fck, int *lck_div, int *pck_div)
+static int dpi_set_dispc_clk(enum omap_channel channel, bool is_tft,
+ unsigned long pck_req, unsigned long *fck, int *lck_div,
+ int *pck_div)
{
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
@@ -84,7 +86,7 @@ static int dpi_set_dispc_clk(bool is_tft, unsigned long
pck_req,
if (r)
return r;
- r = dispc_set_clock_div(dispc_cinfo);
+ r = dispc_set_clock_div(channel, dispc_cinfo);
if (r)
return r;
@@ -107,17 +109,17 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
- dispc_set_pol_freq(dssdev-panel.config, dssdev-panel.acbi,
- dssdev-panel.acb);
+ dispc_set_pol_freq(dssdev-channel, dssdev-panel.config,
+ dssdev-panel.acbi, dssdev-panel.acb);
is_tft = (dssdev-panel.config OMAP_DSS_LCD_TFT) != 0;
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
- r = dpi_set_dsi_clk(is_tft, t-pixel_clock * 1000,
- fck, lck_div, pck_div);
+ r = dpi_set_dsi_clk(dssdev-channel, is_tft,
+ t-pixel_clock * 1000, fck, lck_div, pck_div);
#else
- r = dpi_set_dispc_clk(is_tft, t-pixel_clock * 1000,
- fck, lck_div, pck_div);
+ r = dpi_set_dispc_clk(dssdev-channel, is_tft,
+ t-pixel_clock * 1000, fck, lck_div, pck_div);
#endif
if (r)
goto err0;
@@ -132,7 +134,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t-pixel_clock = pck;
}
- dispc_set_lcd_timings(t);
+ dispc_set_lcd_timings(dssdev-channel, t);
err0:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
@@ -145,10 +147,12 @@ static int dpi_basic_init(struct omap_dss_device *dssdev)
is_tft = (dssdev-panel.config OMAP_DSS_LCD_TFT) != 0;
- dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
- dispc_set_lcd_display_type(is_tft ? OMAP_DSS_LCD_DISPLAY_TFT :
- OMAP_DSS_LCD_DISPLAY_STN);
- dispc_set_tft_data_lines(dssdev-phy.dpi.data_lines);
+ dispc_set_parallel_interface_mode(dssdev-channel,
+ OMAP_DSS_PARALLELMODE_BYPASS);
+ dispc_set_lcd_display_type(dssdev-channel,
+ is_tft ? OMAP_DSS_LCD_DISPLAY_TFT : OMAP_DSS_LCD_DISPLAY_STN);
+ dispc_set_tft_data_lines(dssdev-channel,
+ dssdev-phy.dpi.data_lines);
return 0;
}
diff --git
RE: [RFC v2][PATCH 1/7] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Wednesday, July 14, 2010 12:03 PM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Guruswamy,
Senthilvadivu; Mittal, Mukund; Taneja, Archit; Nilofer, Samreen
Subject: [RFC v2][PATCH 1/7] OMAP: DSS2: Overlay Manager LCD2
changes in dispay.h
From: Sumit Semwal sumit.sem...@ti.com
Overlay Manager LCD2 changes in dispay.h
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
[sp] Do these changes really have to be in a separate patch?
Wouldn't it be better to combine them logically with
the usage?
~sanjeev
arch/arm/plat-omap/include/plat/display.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 8bd15bd..c3643f5
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -64,6 +64,7 @@ enum omap_plane {
enum omap_channel {
OMAP_DSS_CHANNEL_LCD= 0,
OMAP_DSS_CHANNEL_DIGIT = 1,
+ OMAP_DSS_CHANNEL_LCD2 = 2,
};
enum omap_color_mode {
@@ -173,6 +174,7 @@ enum omap_dss_display_state {
enum omap_dss_overlay_managers {
OMAP_DSS_OVL_MGR_LCD,
OMAP_DSS_OVL_MGR_TV,
+ OMAP_DSS_OVL_MGR_LCD2,
};
enum omap_dss_rotation_type {
@@ -462,6 +464,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
/* platform specific */
int (*platform_enable)(struct omap_dss_device *dssdev);
--
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
--
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 v2][PATCH 1/7] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h
Hi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Taneja, Archit Sent: Wednesday, July 14, 2010 12:03 PM To: tomi.valkei...@nokia.com Cc: linux-omap@vger.kernel.org; Semwal, Sumit; Guruswamy, Senthilvadivu; Mittal, Mukund; Taneja, Archit; Nilofer, Samreen Subject: [RFC v2][PATCH 1/7] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h From: Sumit Semwal sumit.sem...@ti.com Overlay Manager LCD2 changes in dispay.h Signed-off-by: Sumit Semwal sumit.sem...@ti.com Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Signed-off-by: Mukund Mittal mmit...@ti.com Signed-off-by: Archit Taneja arc...@ti.com Signed-off-by: Samreen samr...@ti.com --- [sp] Do these changes really have to be in a separate patch? Wouldn't it be better to combine them logically with the usage? ~sanjeev The introduction of the secondary channel causes many changes across different files, patches 1, 2, 4, 5, 7 introduces this feature and splits it both logically and on the basis of files modified. One of the main reason to introduce one single patch for display.h is because it is central to DSS2 and one glance at it tells how the other files will be affected. For example, if in a future patch we need to introduce another video pipeline, the file display.h will introduce the new enum member. Thanks, Archit-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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: ARM defconfig files
On Tue, Jul 13, 2010 at 2:34 AM, David Brown dav...@codeaurora.org wrote: It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. Yes, I think there's a more efficient way to do it, but it would require the SAT resolver, or something like that. -- Felipe Contreras -- 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: ARM defconfig files
On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. That's your point of view. My viewpoint was that I had read your email, thought of some alternative solution, proposed it and the result was shot down without any apparant thought about it. That gave the impression that you _only_ wanted to see your own solution. I think you got it wrong. Linus liked my proposal of minimal defconfigs, and the only discrepancy was on the format: http://article.gmane.org/gmane.linux.kernel/995419 -- Felipe Contreras -- 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/11] staging: tidspbridge: header cleanup series
On Tue, Jul 13, 2010 at 1:55 AM, Nishanth Menon n...@ti.com wrote: Series targetted to remove std.h, GlobalTypes.h and dbdefs.h. These introduce custom types and macros which dont make sense for linux kernel Nishanth Menon (11): staging: tidspbridge: remove custom TRUE FALSE staging: tidspbridge: no need for custom NULL staging: tidspbridge: remove std.h staging: tidspbridge: remove custom typedef reg_uword32 staging: tidspbridge: remove RET_OK RET_FAIL staging: tidspbridge: remove GlobalTypes.h staging: tidspbridge: replace CONST with c standard const staging: tidspbridge: remove IN modifier staging: tidspbridge: remove OPTIONAL staging: tidspbridge: remove OUT define staging: tidspbridge: remove dbdefs.h FWIW: Reviewed-by: Felipe Contreras felipe.contre...@gmail.com -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] mfd: Support for TWL6030 PWM
Hi Hemanth, On Thu, Jul 08, 2010 at 05:40:51PM +0530, Hemanth V wrote: From 2c6efcebf2790a4c968309360cfc3559b6d9c110 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Thu, 8 Jul 2010 17:04:06 +0530 Subject: [PATCH] Add support for TWL6030 PWM TWL6030 supports PWM (Pulse Width Modulator) which is used to control charging LED. PWM allows for controlling brightness. This patch implements the APIs required by leds-pwm driver. Signed-off-by: Hemanth V heman...@ti.com --- drivers/mfd/Kconfig |9 +++ drivers/mfd/Makefile |3 +- drivers/mfd/twl6030-pwm.c | 163 + 3 files changed, 174 insertions(+), 1 deletions(-) create mode 100644 drivers/mfd/twl6030-pwm.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index c7c11ef..4459fe5 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -162,6 +162,15 @@ config TWL6030_GPADC Say yes here if you want support for the TWL6030 General Purpose A/D Convertor. +config TWL6030_PWM + tristate TWL6030 PWM (Pulse Width Modulator) Support + depends on TWL4030_CORE + select HAVE_PWM + default n + help + Say yes here if you want support for TWL6030 PWM. + This is used to control charging LED brightness. + config MFD_TMIO bool default n diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 204a974..e697101 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o obj-$(CONFIG_TWL4030_CODEC) += twl4030-codec.o obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o I don't have this one on my tree, so the patch didnt apply cleanly. I fixed it up though, so the patch is applied. +obj-$(CONFIG_TWL6030_PWM)+= twl6030-pwm.o obj-$(CONFIG_MFD_MC13783)+= mc13783-core.o @@ -63,4 +64,4 @@ obj-$(CONFIG_AB3100_OTP)+= ab3100-otp.o obj-$(CONFIG_AB4500_CORE)+= ab4500-core.o obj-$(CONFIG_MFD_TIMBERDALE)+= timberdale.o obj-$(CONFIG_PMIC_ADP5520) += adp5520.o -obj-$(CONFIG_LPC_SCH)+= lpc_sch.o \ No newline at end of file +obj-$(CONFIG_LPC_SCH)+= lpc_sch.o Unrelated change, please avoid that. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP1: PM: Fix OMAP1610 build
OMAP1610 build fails with following error on the branch pm-wip/hwmods-omap4.
This patch fixes the build error.
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_suspend':
arch/arm/mach-omap1/pm_bus.c:30: error: 'ret' undeclared (first use in this
function)
arch/arm/mach-omap1/pm_bus.c:30: error: (Each undeclared identifier is reported
only once
arch/arm/mach-omap1/pm_bus.c:30: error: for each function it appears in.)
arch/arm/mach-omap1/pm_bus.c:32: error: implicit declaration of function
'clk_get'
arch/arm/mach-omap1/pm_bus.c:32: warning: assignment makes pointer from integer
without a cast
arch/arm/mach-omap1/pm_bus.c:33: error: implicit declaration of function
'IS_ERR'
arch/arm/mach-omap1/pm_bus.c:34: error: implicit declaration of function
'clk_disable'
arch/arm/mach-omap1/pm_bus.c:35: error: implicit declaration of function
'clk_put'
arch/arm/mach-omap1/pm_bus.c:38: warning: assignment makes pointer from integer
without a cast
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_resume':
arch/arm/mach-omap1/pm_bus.c:52: warning: assignment makes pointer from integer
without a cast
arch/arm/mach-omap1/pm_bus.c:54: error: implicit declaration of function
'clk_enable'
arch/arm/mach-omap1/pm_bus.c:58: warning: assignment makes pointer from integer
without a cast
arch/arm/mach-omap1/pm_bus.c:49: warning: unused variable 'r'
arch/arm/mach-omap1/pm_bus.c: In function 'platform_pm_runtime_idle':
arch/arm/mach-omap1/pm_bus.c:72: error: 'ret' undeclared (first use in this
function)
make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1
make: *** [arch/arm/mach-omap1] Error 2
This patch fixes build issues and same has been tested for
omap_h2_1610_defconfig.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap1/pm_bus.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 29d651a..6c5ab40 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -15,6 +15,8 @@
#include linux/pm_runtime.h
#include linux/platform_device.h
#include linux/mutex.h
+#include linux/clk.h
+#include linux/err.h
#include plat/omap_device.h
#include plat/omap-pm.h
@@ -23,6 +25,7 @@
int platform_pm_runtime_suspend(struct device *dev)
{
struct clk *iclk, *fclk;
+ int ret = 0;
dev_dbg(dev, %s\n, __func__);
@@ -46,7 +49,7 @@ int platform_pm_runtime_suspend(struct device *dev)
int platform_pm_runtime_resume(struct device *dev)
{
- int r, ret = 0;
+ int ret = 0;
struct clk *iclk, *fclk;
iclk = clk_get(dev, ick);
@@ -69,6 +72,7 @@ int platform_pm_runtime_resume(struct device *dev)
int platform_pm_runtime_idle(struct device *dev)
{
+ int ret = 0;
ret = pm_runtime_suspend(dev);
dev_dbg(dev, %s [%d]\n, __func__, ret);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: DSS2: Fix error path in omap_dsi_update()
In the case of an error on calling dsi_update_screen_l4(), a
successful framedone callback is still sent to panel-taal. An
error should be returned to taal_update() instead.
Signed-off-by: Archit Taneja arc...@ti.com
---
v2: This fixes a compilation warning seen after
builing with v1.
v1:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31715.html
drivers/video/omap2/dss/dsi.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a6e0f64..b3fa3a7
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2920,7 +2920,12 @@ int omap_dsi_update(struct omap_dss_device *dssdev,
dsi_update_screen_dispc(dssdev, x, y, w, h);
} else {
- dsi_update_screen_l4(dssdev, x, y, w, h);
+ int r;
+
+ r = dsi_update_screen_l4(dssdev, x, y, w, h);
+ if (r)
+ return r;
+
dsi_perf_show(L4);
callback(0, data);
}
--
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: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, July 14, 2010 5:23 PM
To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
[Ghorai] 0 to 3 are the valid numbers.
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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] mmc: csd version check updated to support MMC v4.41
Hi,
you can find it's already merged at mmc tree.
Try to find this one. [PATCH v2] Recognize CSD structure version 3
Thank you,
Kyungmin Park
On Wed, Jul 14, 2010 at 9:19 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, July 14, 2010 5:23 PM
To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
[Ghorai] 0 to 3 are the valid numbers.
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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-mmc 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] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: kyungmi...@gmail.com [mailto:kyungmi...@gmail.com] On Behalf Of
Kyungmin Park
Sent: Wednesday, July 14, 2010 6:09 PM
To: Ghorai, Sukumar
Cc: Sripathy, Vishwanath; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: Re: [PATCH] mmc: csd version check updated to support MMC v4.41
Hi,
you can find it's already merged at mmc tree.
Try to find this one. [PATCH v2] Recognize CSD structure version 3
[Ghorai] Thanks I got it.
Thank you,
Kyungmin Park
On Wed, Jul 14, 2010 at 9:19 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, July 14, 2010 5:23 PM
To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: RE: [PATCH] mmc: csd version check updated to support MMC
v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid
number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
[Ghorai] 0 to 3 are the valid numbers.
printk(KERN_ERR %s: unrecognised CSD structure
version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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-mmc 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: musb_hdrc: usb_disconnect is not called when the USB device is disconnected.
Enric Balletbò i Serra
Hello,
When I disconnect an USB pendrive using twl4030 otg as host (step 2)
the usb_disconnect function is not called. OTOH if I reconnect the
device (step 3), then the usb_disconnect function is called.
Does anyone have any ideas why usb_disconnect is not called when the
device is removed?
Which kernel version is this? Can you check if this patch fixes the behavior?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d9645fdca444d53907b22a4b73e3967efe09781
- Anand
Steps to see the feature:
Step 1 : Plug a USB pendrive:
[ 2116.491546] usb 1-1: new high speed USB device using musb_hdrc and address
6
[ 2116.751861] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
[ 2116.758697] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 2116.765899] usb 1-1: Product: Mass Storage
[ 2116.770019] usb 1-1: Manufacturer: 2.0
[ 2116.773834] usb 1-1: SerialNumber: A15B7B60
[ 2116.786468] scsi4 : usb-storage 1-1:1.0
[ 2117.797332] scsi 4:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ:
0 ANSI: 2
[ 2117.813293] sd 4:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00
GB/961 MiB)
[ 2117.829040] sd 4:0:0:0: [sda] Write Protect is off
[ 2117.834014] sd 4:0:0:0: [sda] Mode Sense: 03 00 00 00
[ 2117.834014] sd 4:0:0:0: [sda] Assuming drive cache: write through
[ 2117.849212] sd 4:0:0:0: [sda] Assuming drive cache: write through
[ 2117.856597] sda: sda1
[ 2117.965698] sd 4:0:0:0: [sda] Assuming drive cache: write through
[ 2117.971954] sd 4:0:0:0: [sda] Attached SCSI removable disk
[ 2118.738769] FAT: bogus number of reserved sectors
[ 2118.743621] VFS: Can't find a valid FAT filesystem on dev sda.
Step 2: Unplug the USB pendrive
[ nothing here ]
Step 3: Plug the USB pendrive:
[ 2218.820556] usb 1-1: USB disconnect, address 6
[ 2219.139831] usb 1-1: new high speed USB device using musb_hdrc and address
7
[ 2219.400146] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
[ 2219.406951] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 2219.414184] usb 1-1: Product: Mass Storage
[ 2219.418304] usb 1-1: Manufacturer: 2.0
[ 2219.422119] usb 1-1: SerialNumber: A15B7B60
[ 2219.434875] scsi5 : usb-storage 1-1:1.0
[ 2220.445770] scsi 5:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ:
0 ANSI: 2
[ 2220.461547] sd 5:0:0:0: [sda] 1968128 512-byte logical blocks:(1.00 GB/961
MiB)
[ 2220.476379] sd 5:0:0:0: [sda] Write Protect is off
[ 2220.481323] sd 5:0:0:0: [sda] Mode Sense: 03 00 00 00
[ 2220.481323] sd 5:0:0:0: [sda] Assuming drive cache: write through
[ 2220.497314] sd 5:0:0:0: [sda] Assuming drive cache: write through
[ 2220.504516] sda: sda1
[ 2220.603790] sd 5:0:0:0: [sda] Assuming drive cache: write through
[ 2220.610015] sd 5:0:0:0: [sda] Attached SCSI removable disk
[ 2221.378570] FAT: bogus number of reserved sectors
[ 2221.383453] VFS: Can't find a valid FAT filesystem on dev sda.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH resend] omap: 3630: disable TLL SAR on 3630 ES1
Paul Walmsley wrote: On Sat, 10 Jul 2010, Anand Gadiyar wrote: USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it enabled could result in incorrect register restores as the OMAP exits off-mode. This could potentially result in unexpected wakeup events. This is fixed in ES1.1. So disable it for ES1.0s. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Paul Walmsley p...@pwsan.com --- This is a fix for buggy hardware, and it would be nice to see this in the next merge window too. Depends on the patch I just posted which adds the CHIP_GE_OMAP3630ES1_1 macro https://patchwork.kernel.org/patch/47/ Verified against the OMAP3630 errata PDF from June 16. Anand, could you please add an erratum ID to the commit message or to a comment in the code? Will do. I just noticed the errata doc has finally been updated with a proper ID that I can use here. I'll resend in a short while. Tony, once Anand does that, it's Acked-by: Paul Walmsley p...@pwsan.com if you want it for .36; otherwise, for .37, I'd be happy to queue it. I assume you mean .35 and .36 here - isn't .37 another 3+ months away? - 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: ARM defconfig files
On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote: On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. Note that no kernel is built at all, only the config is regenerated once for each line. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 resend v2] omap: 3630: disable TLL SAR on 3630 ES1
USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it
enabled could result in incorrect register restores as
the OMAP exits off-mode. This could potentially result in
unexpected wakeup events.
(Refer 3630 errata ID i579)
This is fixed in ES1.1. So disable it for ES1.0s.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
(v2: Added a comment to the code with a reference to the errata IDs
for 3430 and 3630. Also added Paul's ack).
This is a fix for buggy hardware, and it would be nice
to see this in the next merge window too.
Depends on the patch I just posted which adds the
CHIP_GE_OMAP3630ES1_1 macro
https://patchwork.kernel.org/patch/47/
arch/arm/mach-omap2/powerdomains34xx.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/powerdomains34xx.h
+++ linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
@@ -75,12 +75,19 @@ static struct powerdomain mpu_3xxx_pwrdm
},
};
+/*
+ * The USBTLL Save-and-Restore mechanism is broken on
+ * 3430s upto ES3.0 and 3630ES1.0. Hence this feature
+ * needs to be disabled on these chips.
+ * Refer: 3430 errata ID i459 and 3630 errata ID i579
+ */
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
CHIP_IS_OMAP3430ES2 |
- CHIP_IS_OMAP3430ES3_0),
+ CHIP_IS_OMAP3430ES3_0 |
+ CHIP_IS_OMAP3630ES1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 2,
@@ -97,7 +104,8 @@ static struct powerdomain core_3xxx_pre_
static struct powerdomain core_3xxx_es3_1_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1 |
+ CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
--
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: musb_hdrc: usb_disconnect is not called when the USB device is disconnected.
2010/7/14 Gadiyar, Anand gadi...@ti.com: Enric Balletbò i Serra Hello, When I disconnect an USB pendrive using twl4030 otg as host (step 2) the usb_disconnect function is not called. OTOH if I reconnect the device (step 3), then the usb_disconnect function is called. Does anyone have any ideas why usb_disconnect is not called when the device is removed? Which kernel version is this? Can you check if this patch fixes the behavior? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d9645fdca444d53907b22a4b73e3967efe09781 I'm using stable kernel 2.6.33.6 And yes this patch is not applied in this version. I applied and solves the issue. Thank you very much. Best regards, -- Enric - Anand Steps to see the feature: Step 1 : Plug a USB pendrive: [ 2116.491546] usb 1-1: new high speed USB device using musb_hdrc and address 6 [ 2116.751861] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2116.758697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2116.765899] usb 1-1: Product: Mass Storage [ 2116.770019] usb 1-1: Manufacturer: 2.0 [ 2116.773834] usb 1-1: SerialNumber: A15B7B60 [ 2116.786468] scsi4 : usb-storage 1-1:1.0 [ 2117.797332] scsi 4:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2117.813293] sd 4:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2117.829040] sd 4:0:0:0: [sda] Write Protect is off [ 2117.834014] sd 4:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2117.834014] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.849212] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.856597] sda: sda1 [ 2117.965698] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.971954] sd 4:0:0:0: [sda] Attached SCSI removable disk [ 2118.738769] FAT: bogus number of reserved sectors [ 2118.743621] VFS: Can't find a valid FAT filesystem on dev sda. Step 2: Unplug the USB pendrive [ nothing here ] Step 3: Plug the USB pendrive: [ 2218.820556] usb 1-1: USB disconnect, address 6 [ 2219.139831] usb 1-1: new high speed USB device using musb_hdrc and address 7 [ 2219.400146] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2219.406951] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2219.414184] usb 1-1: Product: Mass Storage [ 2219.418304] usb 1-1: Manufacturer: 2.0 [ 2219.422119] usb 1-1: SerialNumber: A15B7B60 [ 2219.434875] scsi5 : usb-storage 1-1:1.0 [ 2220.445770] scsi 5:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2220.461547] sd 5:0:0:0: [sda] 1968128 512-byte logical blocks:(1.00 GB/961 MiB) [ 2220.476379] sd 5:0:0:0: [sda] Write Protect is off [ 2220.481323] sd 5:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2220.481323] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.497314] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.504516] sda: sda1 [ 2220.603790] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.610015] sd 5:0:0:0: [sda] Attached SCSI removable disk [ 2221.378570] FAT: bogus number of reserved sectors [ 2221.383453] VFS: Can't find a valid FAT filesystem on dev sda. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: DSS2: Fix error path in omap_dsi_update()
Taneja, Archit had written, on 07/14/2010 07:11 AM, the following:
In the case of an error on calling dsi_update_screen_l4(), a
successful framedone callback is still sent to panel-taal. An
error should be returned to taal_update() instead.
Signed-off-by: Archit Taneja arc...@ti.com
---
v2: This fixes a compilation warning seen after
builing with v1.
v1:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31715.html
drivers/video/omap2/dss/dsi.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a6e0f64..b3fa3a7
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2920,7 +2920,12 @@ int omap_dsi_update(struct omap_dss_device *dssdev,
dsi_update_screen_dispc(dssdev, x, y, w, h);
dont need the error check here?
} else {
- dsi_update_screen_l4(dssdev, x, y, w, h);
+ int r;
+
+ r = dsi_update_screen_l4(dssdev, x, y, w, h);
+ if (r)
no print for warning developer/user? is this error expected?
+ return r;
+
dsi_perf_show(L4);
callback(0, data);
}
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH resend v2] omap: 3630: disable TLL SAR on 3630 ES1
Hi Anand,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Anand Gadiyar
Sent: Wednesday, July 14, 2010 8:39 AM
To: linux-omap@vger.kernel.org
Cc: Gadiyar, Anand
Subject: [PATCH resend v2] omap: 3630: disable TLL SAR on 3630 ES1
USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it
enabled could result in incorrect register restores as
the OMAP exits off-mode. This could potentially result in
unexpected wakeup events.
(Refer 3630 errata ID i579)
This is fixed in ES1.1. So disable it for ES1.0s.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
(v2: Added a comment to the code with a reference to the errata IDs
for 3430 and 3630. Also added Paul's ack).
This is a fix for buggy hardware, and it would be nice
to see this in the next merge window too.
Depends on the patch I just posted which adds the
CHIP_GE_OMAP3630ES1_1 macro
https://patchwork.kernel.org/patch/47/
arch/arm/mach-omap2/powerdomains34xx.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/powerdomains34xx.h
+++ linux-omap-2.6/arch/arm/mach-omap2/powerdomains34xx.h
@@ -75,12 +75,19 @@ static struct powerdomain mpu_3xxx_pwrdm
},
};
+/*
+ * The USBTLL Save-and-Restore mechanism is broken on
+ * 3430s upto ES3.0 and 3630ES1.0. Hence this feature
+ * needs to be disabled on these chips.
+ * Refer: 3430 errata ID i459 and 3630 errata ID i579
+ */
static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
IMHO, The above name (and below ones) should be revisited, since
its becoming misleading (even before your patch).
Pre ES3.1 on OMAP3 chips is confusing, since both 3630ES1.0 and
ES1.1 _are_ pre ES3.1.
Not sure if this needs to be taken care before or in this patch..
What do you think?
Regards,
Sergio
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 |
CHIP_IS_OMAP3430ES2 |
-CHIP_IS_OMAP3430ES3_0),
+CHIP_IS_OMAP3430ES3_0 |
+CHIP_IS_OMAP3630ES1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 2,
@@ -97,7 +104,8 @@ static struct powerdomain core_3xxx_pre_
static struct powerdomain core_3xxx_es3_1_pwrdm = {
.name = core_pwrdm,
.prcm_offs= CORE_MOD,
- .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1 |
+ CHIP_GE_OMAP3630ES1_1),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
--
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: ARM defconfig files
2010/7/14 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Note that no kernel is built at all, only the config is regenerated once for each line. You could special case blank lines and comments (other than ones like # CONFIG_FOO is not set which do matter). They account for ~15% of the lines in my .config files. But it probably doesn't matter all that much. I just ran reduce_defconfig in parallel on all the ia64 defconfig files (in separate build trees) and they were all done when I looked back an hour or so later. Nice tool! -Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: Joerg Roedel wrote: The DMA-API already does this with the help of IOMMUs if they are present. What is the benefit of your approach over that? The grist to the DMA-API mill is the opaque scatterlist. Each scatterlist element brings together a physical address and a bus address that may be different. The set of scatterlist elements constitute both the set of physical buffers and the mappings to those buffers. My approach separates these two things into a struct physmem which contains the set of physical buffers and a struct reservation which contains the set of bus addresses (or device addresses). Each element in the struct physmem may be of various lengths (without resorting to chaining). A map call maps the one set to the other. Okay, thats a different concept, where is the benefit? Joerg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Add S-Video output to IGEPv2 board
This adds S-Video DSS and VDAC regulator platform definitions to the IGEPv2
board. There isn't a physical connector on-board but one can solder one at test
points provided by ISEE.
Signed-off-by: Maurus Cuelenaere mcuelena...@gmail.com
---
arch/arm/mach-omap2/board-igep0020.c | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index d55c57b..3ec48bd 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -310,8 +310,16 @@ static struct omap_dss_device igep2_dvi_device = {
.platform_disable = igep2_disable_dvi,
};
+static struct omap_dss_device igep2_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
static struct omap_dss_device *igep2_dss_devices[] = {
- igep2_dvi_device
+ igep2_dvi_device,
+ igep2_tv_device,
};
static struct omap_dss_board_info igep2_dss_data = {
@@ -328,6 +336,25 @@ static struct platform_device igep2_dss_device = {
},
};
+static struct regulator_consumer_supply igep2_vdda_dac_supply = {
+ .supply = vdda_dac,
+ .dev= igep2_dss_device.dev,
+};
+
+/* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */
+static struct regulator_init_data igep2_vdac = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = igep2_vdda_dac_supply,
+};
+
static struct regulator_consumer_supply igep2_vpll2_supply = {
.supply = vdds_dsi,
.dev= igep2_dss_device.dev,
@@ -429,7 +456,7 @@ static struct twl4030_platform_data igep2_twldata = {
.vmmc1 = igep2_vmmc1,
.vmmc2 = igep2_vmmc2,
.vpll2 = igep2_vpll2,
-
+ .vdac = igep2_vdac,
};
static struct i2c_board_info __initdata igep2_i2c_boardinfo[] = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 05:14:21 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: You mean that you want to specify this alignment attribute every time you create an IOMMU mapping? Then you can set segment_boundary_mask every time you create an IOMMU mapping. It's odd but it should work. Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to create a mapping that has the alignment I specify, regardless of the mapper. The mapping is created on a VCM and the VCM is associated with a mapper: a CPU, an IOMMU'd device or a direct mapped device. Sounds like you can do the above with the combination of the current APIs, create a virtual address and then an I/O address. Yes, and that's what the implementation does - and all the other implementations that need to do this same thing. Why not solve the problem once? The above can't be a reason to add a new infrastructure includes more than 3,000 lines. Right now its 3000 lines because I haven't converted to a function pointer based implementation. Once I do that the size of the implementation will shrink and the code will act as a lib. Users pass buffer mappers and the lib will ease the management of of those buffers. Another possible solution is extending struct dma_attrs. We could add the alignment attribute to it. That may be useful, but in the current DMA-API may be seen as redundant info. If there is real requirement, we can extend the DMA-API. If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote: If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. Every additional virtual mapping of a physical buffer results in additional cache aliases on aliasing caches, and more workload for developers to sort out the cache aliasing issues. What does VCM to do mitigate that? -- 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 1/1] ARM: Add initial hibernation support
Hi! From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Looks ok to me. ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, 14 Jul 2010 13:11:49 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote: On Tue, 13 Jul 2010 05:14:21 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: You mean that you want to specify this alignment attribute every time you create an IOMMU mapping? Then you can set segment_boundary_mask every time you create an IOMMU mapping. It's odd but it should work. Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to create a mapping that has the alignment I specify, regardless of the mapper. The mapping is created on a VCM and the VCM is associated with a mapper: a CPU, an IOMMU'd device or a direct mapped device. Sounds like you can do the above with the combination of the current APIs, create a virtual address and then an I/O address. Yes, and that's what the implementation does - and all the other implementations that need to do this same thing. Why not solve the problem once? Why we we need a new abstraction layer to solve the problem that the current API can handle? The above two operations don't sound too complicated. The combination of the current API sounds much simpler than your new abstraction. Please show how the combination of the current APIs doesn't work. Otherwise, we can't see what's the benefit of your new abstraction. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Wed, Jul 14, 2010 at 09:34:03PM +0200, Joerg Roedel wrote: On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: Joerg Roedel wrote: The DMA-API already does this with the help of IOMMUs if they are present. What is the benefit of your approach over that? The grist to the DMA-API mill is the opaque scatterlist. Each scatterlist element brings together a physical address and a bus address that may be different. The set of scatterlist elements constitute both the set of physical buffers and the mappings to those buffers. My approach separates these two things into a struct physmem which contains the set of physical buffers and a struct reservation which contains the set of bus addresses (or device addresses). Each element in the struct physmem may be of various lengths (without resorting to chaining). A map call maps the one set to the other. Okay, thats a different concept, where is the benefit? The benefit is that virtual address space and physical address space are managed independently. This may be useful if you want to reuse the same set of physical buffers, a user simply maps them when they're needed. It also means that different physical memories could be targeted and a virtual allocation could map those memories without worrying about where they were. This whole concept is just a logical extension of the already existing separation between pages and page frames... in fact the separation between physical memory and what is mapped to that memory is fundamental to the Linux kernel. This approach just says that arbitrary long buffers should work the same way. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote: On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote: If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. Every additional virtual mapping of a physical buffer results in additional cache aliases on aliasing caches, and more workload for developers to sort out the cache aliasing issues. What does VCM to do mitigate that? The VCM ensures that all mappings that map a given physical buffer: IOMMU mappings, CPU mappings and one-to-one device mappings all map that buffer using the same (or compatible) attributes. At this point the only attribute that users can pass is CACHED. In the absence of CACHED all accesses go straight through to the physical memory. The architecture of the VCM allows these sorts of consistency checks to be made since all mappers of a given physical resource are tracked. This is feasible because the physical resources we're tracking are typically large. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
Zach Pfeffer zpfef...@codeaurora.org writes: On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote: On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote: If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. Every additional virtual mapping of a physical buffer results in additional cache aliases on aliasing caches, and more workload for developers to sort out the cache aliasing issues. What does VCM to do mitigate that? The VCM ensures that all mappings that map a given physical buffer: IOMMU mappings, CPU mappings and one-to-one device mappings all map that buffer using the same (or compatible) attributes. At this point the only attribute that users can pass is CACHED. In the absence of CACHED all accesses go straight through to the physical memory. The architecture of the VCM allows these sorts of consistency checks to be made since all mappers of a given physical resource are tracked. This is feasible because the physical resources we're tracking are typically large. On x86 this is implemented in the pat code, and could reasonably be generalized to be cross platform. This is controlled by HAVE_PFNMAP_TRACKING and with entry points like track_pfn_vma_new. Given that we already have an implementation that tracks the cached vs non-cached attribute using the dma api. I don't see that the API has to change. An implementation of the cached vs non-cached status for arm and other architectures is probably appropriate. It is definitely true that getting your mapping caching attributes out of sync can be a problem. Eric -- 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 1/1] ARM: Add initial hibernation support
Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? Thanks -- 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 resend] omap: 3630: disable TLL SAR on 3630 ES1
On Wed, 14 Jul 2010, Gadiyar, Anand wrote: Paul Walmsley wrote: Tony, once Anand does that, it's Acked-by: Paul Walmsley p...@pwsan.com if you want it for .36; otherwise, for .37, I'd be happy to queue it. I assume you mean .35 and .36 here - isn't .37 another 3+ months away? I mean .35 and .36 -- we're operating under the idea that Linus only wants regressions for the -rc series; and due to summer vacations, Kevin and I have already sent our patch queues for .36 to Tony. So it's likely to be in .37, but it might get in for .36 depending on how schedules pan out. This patch seems quite straightforward to me. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Power managment on Overo
Hi, All, I am running the linux-pm-kernel v2.35.rc3 on Overo Earth. I have managed to suspend the system using echo mem /sys/power/state with enable_off_mode and sleep_while_idle enabled. Currently, I am able to achieve 200mW in suspend mode. However, I am seen in other posts, such as this one (http://old.nabble.com/ Overo-boot-time--power-management-ts28402656.html#a28463135), that people are able to achieve a much lower power signature. I am particularly interested to know what mode has the SDRAM on Overo been set to during suspend mode? Is it auto-refresh or self-refresh? And whether the TPS/TWL power management chip is set to low power mode during suspend mode by the pm kernel, if not, how to set it? Thanks, Han -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/20] OMAP: PM: create omap_devices for MPU, DSP, L3
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Friday, July 02, 2010 9:00 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Kevin Hilman
Subject: [PATCH 12/20] OMAP: PM: create omap_devices for MPU, DSP, L3
From: Kevin Hilman khil...@deeprootsystems.com
Create simple omap_devices for the main processors and busses.
This is required to support the forth-coming device-based OPP
approach, where OPPs are managed and tracked at the device level.
Also, move these common PM init functions into a common_pm_init call
that is called as a device_initcall(). The PM init is done at this level
to ensure that the driver core is initialized before initialized.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
[p...@pwsan.com: sparse warnings cleaned up; newly-created functions moved
from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
to start with omap2 rather than omap]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |2 -
arch/arm/mach-omap2/io.c |2 -
arch/arm/mach-omap2/pm.c | 84
++
arch/arm/plat-omap/include/plat/common.h |4 +
4 files changed, 90 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2fa3418..213f1df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
omap-2-3-common = irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 05c9cdb..2b983ac 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -44,6 +44,7 @@
#include plat/clockdomain.h
#include clockdomains.h
+
#include plat/omap_hwmod.h
/*
@@ -346,7 +347,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
omap_hwmod_late_init(skip_setup_idle);
- omap_pm_if_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
new file mode 100644
index 000..68f9f2e
--- /dev/null
+++ b/arch/arm/mach-omap2/pm.c
@@ -0,0 +1,84 @@
+/*
+ * pm.c - Common OMAP2+ power management-related code
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/io.h
+#include linux/err.h
+
+#include plat/omap-pm.h
+#include plat/omap_device.h
+#include plat/common.h
+
+static struct omap_device_pm_latency *pm_lats;
+
+static struct device *mpu_dev;
+static struct device *dsp_dev;
+static struct device *l3_dev;
+
+struct device *omap2_get_mpuss_device(void)
+{
+ WARN_ON_ONCE(!mpu_dev);
+ return mpu_dev;
+}
+
+struct device *omap2_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
First of all, apologies for so late posting of the comment. IMHO it would be
good to rename this API as omap2_get_iva_device. This is because OMAP4 has
separate IVA and DSP devices and we will need to build the omap_device for
both. If we could rename this as omap2_get_iva_device, we could introduce
another API omap4_get_iva_device until bridge starts doing a omap_device_build
for all these devices.
+
+struct device *omap2_get_l3_device(void)
+{
+ WARN_ON_ONCE(!l3_dev);
+ return l3_dev;
+}
+
+/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
+static int _init_omap_device(char *name, struct device **new_dev)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup(name);
+ if (WARN(!oh, %s: could not find omap_hwmod for %s\n,
+ __func__, name))
+ return -ENODEV;
+
+ od = omap_device_build(oh-name, 0, oh, NULL, 0, pm_lats, 0, false);
+ if (WARN(IS_ERR(od), %s: could not build omap_device for %s\n,
+ __func__, name))
+ return -ENODEV;
+
+ *new_dev = od-pdev.dev;
+
+ return 0;
+}
+
+/*
+ * Build omap_devices for processors and bus.
+ */
+static void omap2_init_processor_devices(void)
+{
+ _init_omap_device(mpu, mpu_dev);
+ _init_omap_device(iva, dsp_dev);
Similar to earlier comment rename dsp_dev to iva_dev.
Paul, I could rebase this patch fixing
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
From: ext Pavel Machek pa...@ucw.cz Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Wed, 14 Jul 2010 15:22:55 +0200 Hi! From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Looks ok to me. ACK. Pavel, Thanks. Russell, would it be possible to put this into your next merge queue? -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 14, 2010 at 06:29:58PM -0700, Zach Pfeffer wrote: On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote: On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote: If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. Every additional virtual mapping of a physical buffer results in additional cache aliases on aliasing caches, and more workload for developers to sort out the cache aliasing issues. What does VCM to do mitigate that? The VCM ensures that all mappings that map a given physical buffer: IOMMU mappings, CPU mappings and one-to-one device mappings all map that buffer using the same (or compatible) attributes. At this point the only attribute that users can pass is CACHED. In the absence of CACHED all accesses go straight through to the physical memory. The architecture of the VCM allows these sorts of consistency checks to be made since all mappers of a given physical resource are tracked. This is feasible because the physical resources we're tracking are typically large. A few more things... In addition to CACHED, the VCMM can support different cache policies as long as the architecture can support it - they get passed down through the device map call. In addition, handling physical mappings in the VCMM enables it to perform refcounting on the physical chunks (ie, to see how many virtual spaces it's been mapped to, including the kernel's). This allows it to turn on any coherency protocols that are available in hardware (ie, setting the shareable bit on something that is mapped to more than one virtual space). That same attribute can be left off on a buffer that has only one virtual mapping (ie, scratch buffers used by one device only). It is then up to the underlying system to deal with that shared attribute - to enable redirection if it's supported, or to force something to be non-cacheable, etc. Doing it all through the VCMM allows all these mechanisms be worked out once per architecture and then reused. -- 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 1/1] ARM: Add initial hibernation support
From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Wed, Jul 14, 2010 at 06:47:34PM -0700, Eric W. Biederman wrote: Zach Pfeffer zpfef...@codeaurora.org writes: On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote: On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote: If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. Every additional virtual mapping of a physical buffer results in additional cache aliases on aliasing caches, and more workload for developers to sort out the cache aliasing issues. What does VCM to do mitigate that? The VCM ensures that all mappings that map a given physical buffer: IOMMU mappings, CPU mappings and one-to-one device mappings all map that buffer using the same (or compatible) attributes. At this point the only attribute that users can pass is CACHED. In the absence of CACHED all accesses go straight through to the physical memory. The architecture of the VCM allows these sorts of consistency checks to be made since all mappers of a given physical resource are tracked. This is feasible because the physical resources we're tracking are typically large. On x86 this is implemented in the pat code, and could reasonably be generalized to be cross platform. This is controlled by HAVE_PFNMAP_TRACKING and with entry points like track_pfn_vma_new. Given that we already have an implementation that tracks the cached vs non-cached attribute using the dma api. I don't see that the API has to change. An implementation of the cached vs non-cached status for arm and other architectures is probably appropriate. It is definitely true that getting your mapping caching attributes out of sync can be a problem. Sure, but we're still stuck with needing lots of scatterlist list elements and needing to copy them to share physical buffers. -- 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 1/1] ARM: Add initial hibernation support
Dne Čt 15. července 2010 07:39:31 Hiroshi DOYU napsal(a): From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. I see ... do I need any special support on the bootloader or userland side ? Sorry for stupid questions :) -- 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
