[PATCH] OMAP: Enable Sysrq on serial console
SUPPORT_SYSRQ must be defined to enable handling of sysrq character. Signed-off-by: Thomas Weber we...@corscience.de --- drivers/serial/omap-serial.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c index 1201eff..907be9b 100644 --- a/drivers/serial/omap-serial.c +++ b/drivers/serial/omap-serial.c @@ -20,6 +20,10 @@ * this driver as required for the omap-platform. */ +#if defined(CONFIG_SERIAL_OMAP_CONSOLE) defined(CONFIG_MAGIC_SYSRQ) +#define SUPPORT_SYSRQ +#endif + #include linux/module.h #include linux/init.h #include linux/console.h -- 1.7.4.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP DSS Enable clocks in dss_setup_partial_planes
Hi, On Tue, 2011-01-11 at 17:41 +, ext Ben Tucker wrote: From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Thu, 13 Jan 2011 12:56:45 + Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes Enable the interface clocks while calling configure_dispc(). This description doesn't really tell anything which isn't selfevident from the code below. Please check http://who-t.blogspot.com/2009/12/on-commit-messages.html But I presume this is about RFBI. If so, correct place to enable the clocks would be in rfbi.c. Tomi --- drivers/video/omap2/dss/manager.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c index 545e9b9..cb90dac 100644 --- a/drivers/video/omap2/dss/manager.c +++ b/drivers/video/omap2/dss/manager.c @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device *dssdev, mc-w = w; mc-h = h; + dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1); configure_dispc(); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1); mc-do_manual_update = false; -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe 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 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
On Tue, Jan 11, 2011 at 06:02:30PM -0600, Dave Martin wrote:
To make it easier to deal with cases like this, I've had a
go at writing some macros to make copying function bodies
easier, while being robust for ARM and Thumb-2.
How about instead providing some infrastructure which coes the
copy too? Something like:
#define copy_fn_to_sram(to, fn, size) ({\
__typeof__(fn) f; \
unsigned long ptr; \
__asm__( : =r (ptr) : 0 (fn));\
memcpy(to, (void *)(ptr ~1), size); \
ptr = (ptr 1) | (unsigned long)to;\
__asm__( : =r (f) : 0 (ptr)); \
f; \
})
Used by:
extern void my_func(int foo);
extern int my_func_size;
void call_my_func(void *to, int arg)
{
void (*fn)(int);
fn = copy_fn_to_sram(to, my_func, my_func_size);
fn(arg);
}
Then if you need to fix the way the copies are done for some
architectural reason, there's only one place to do it.
I'm not sure asm/unified.h is the right place - I don't think this has
anything to do with the unified assembler syntax. Please create a new
header for this.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP DSS Enable clocks in dss_setup_partial_planes
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: 12 January 2011 09:14 To: ext Ben Tucker Cc: linux-omap@vger.kernel.org Subject: Re: OMAP DSS Enable clocks in dss_setup_partial_planes Hi, On Tue, 2011-01-11 at 17:41 +, ext Ben Tucker wrote: From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Thu, 13 Jan 2011 12:56:45 + Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes Enable the interface clocks while calling configure_dispc(). This description doesn't really tell anything which isn't selfevident from the code below. Please check http://who-t.blogspot.com/2009/12/on-commit-messages.html But I presume this is about RFBI. If so, correct place to enable the clocks would be in rfbi.c. Tomi Apologies for the commit message. Updated patch below. Are you sure the code to enable clocks should be placed in rfbi.c? The DSI code (dsi.c) uses dss_setup_partial_planes() in the same way as rfbi.c and there is no clock enable code there. Also omap_dss_mgr_apply() within manager.c enables clocks for the configure_dispc() call. Ben From fac7afefc4f80c3045ce73bb34e24a037ed26edc Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Sat, 15 Jan 2011 07:18:49 + Subject: [PATCH] OMAP2,3: DSS2: Enable clocks in dss_setup_partial_planes Fix a deadly bus halt when using RFBI or DSI interfaced panels due to access to the OMAP DSS subsystem while interface and peripheral clocks are disabled. Resolved by enabling the clocks while calling the configure_dispc() in dss_setup_partial_planes(). --- drivers/video/omap2/dss/manager.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c index 545e9b9..cb90dac 100644 --- a/drivers/video/omap2/dss/manager.c +++ b/drivers/video/omap2/dss/manager.c @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device *dssdev, mc-w = w; mc-h = h; + dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1); configure_dispc(); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1); mc-do_manual_update = false; -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe 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 0/3] OMAP4 static dependency support
OMAP4 supports 2 type of domain dependency between clock domains. -1- Static dependency Given a domain dependency from clockdomain A to another clockdomain B, static dependency consists in constraining domain B to become or stay active, as soon as and as long as there exists atleast one system initiator of domain A willing to access domain B. This is very similar to what was supported on OMAP3, except for the fact that there is no distinction between a sleep and a wakeup dependency. A static dependency here means both. -2- Dynamic dependency Given a domain dependency from clock domain A to another clockdomain B, dynamic dependency consists in constraining domain B to become or stay active, as soon as and as long as OCP traffic is ongoing or pending from domain A to domain B. A sliding window (configurable in software) is used to determine if a OCP transaction is ongoing or stopped. This is newly supported in OMAP4 and did not exist on any of the older OMAPs. This patch series adds support only for static dependency configuration in clockdomain framework and is dependent on the clockdomain-split series posted here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41748.html Another series to support dynamic dependency will be posted soon. Rajendra Nayak (3): OMAP4: clockdomain: Add clkmd static dependency srcs OMAP4: CM: Add CM accesor api for bitwise control OMAP4: clockdomain: Add wkup/sleep dependency support arch/arm/mach-omap2/clockdomain44xx.c | 52 + arch/arm/mach-omap2/clockdomains44xx_data.c | 313 ++- arch/arm/mach-omap2/cm44xx.h|1 + arch/arm/mach-omap2/cminst44xx.c| 21 ++ arch/arm/mach-omap2/cminst44xx.h|6 + 5 files changed, 388 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] OMAP4: clockdomain: Add wkup/sleep dependency support
Add OMAP4 platform specific implementation to support clkdm
wkup and sleep dependencies a.k.a static dependencies.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain44xx.c | 52 +
arch/arm/mach-omap2/cm44xx.h |1 +
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index c0ccc47..594c25d 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -12,8 +12,52 @@
* published by the Free Software Foundation.
*/
+#include linux/kernel.h
#include clockdomain.h
#include cminst44xx.h
+#include cm44xx.h
+
+static void omap4_clkdm_add_wkup_sleep_dep(struct clockdomain *clkdm1,
+ struct clockdomain *clkdm2)
+{
+ omap4_cminst_set_inst_reg_bits((1 clkdm2-dep_bit),
+ clkdm1-prcm_partition,
+ clkdm1-cm_inst, OMAP4_CM_STATICDEP);
+}
+
+static void omap4_clkdm_del_wkup_sleep_dep(struct clockdomain *clkdm1,
+ struct clockdomain *clkdm2)
+{
+ omap4_cminst_clear_inst_reg_bits((1 clkdm2-dep_bit),
+ clkdm1-prcm_partition,
+ clkdm1-cm_inst, OMAP4_CM_STATICDEP);
+}
+
+static int omap4_clkdm_read_wkup_sleep_dep(struct clockdomain *clkdm1,
+ struct clockdomain *clkdm2)
+{
+ return omap4_cminst_read_inst_reg_bits(clkdm1-prcm_partition,
+ clkdm1-cm_inst, OMAP4_CM_STATICDEP,
+ (1 clkdm2-dep_bit));
+}
+
+static void omap4_clkdm_clear_all_wkup_sleep_deps(struct clockdomain *clkdm)
+{
+ struct clkdm_dep *cd;
+ u32 mask = 0;
+
+ for (cd = clkdm-wkdep_srcs; cd cd-clkdm; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ /* PRM accesses are slow, so minimize them */
+ mask |= 1 cd-clkdm-dep_bit;
+ atomic_set(cd-wkdep_usecount, 0);
+ }
+
+ omap4_cminst_clear_inst_reg_bits(mask, clkdm-prcm_partition,
+ clkdm-cm_inst, OMAP4_CM_STATICDEP);
+}
static int omap4_clkdm_sleep(struct clockdomain *clkdm)
{
@@ -68,6 +112,14 @@ static int omap4_clkdm_clk_disable(struct clockdomain
*clkdm)
}
struct clkdm_ops omap4_clkdm_operations = {
+ .clkdm_add_wkdep= omap4_clkdm_add_wkup_sleep_dep,
+ .clkdm_del_wkdep= omap4_clkdm_del_wkup_sleep_dep,
+ .clkdm_read_wkdep = omap4_clkdm_read_wkup_sleep_dep,
+ .clkdm_clear_all_wkdeps = omap4_clkdm_clear_all_wkup_sleep_deps,
+ .clkdm_add_sleepdep = omap4_clkdm_add_wkup_sleep_dep,
+ .clkdm_del_sleepdep = omap4_clkdm_del_wkup_sleep_dep,
+ .clkdm_read_sleepdep= omap4_clkdm_read_wkup_sleep_dep,
+ .clkdm_clear_all_sleepdeps = omap4_clkdm_clear_all_wkup_sleep_deps,
.clkdm_sleep= omap4_clkdm_sleep,
.clkdm_wakeup = omap4_clkdm_wakeup,
.clkdm_allow_idle = omap4_clkdm_allow_idle,
diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
index 48fc3f4..4d0cfd3 100644
--- a/arch/arm/mach-omap2/cm44xx.h
+++ b/arch/arm/mach-omap2/cm44xx.h
@@ -21,6 +21,7 @@
#include cm.h
#define OMAP4_CM_CLKSTCTRL 0x
+#define OMAP4_CM_STATICDEP 0x4
/* Function prototypes */
# ifndef __ASSEMBLER__
--
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
[RFC 2/3] OMAP4: CM: Add CM accesor api for bitwise control
Add new OMAP4 CM accesor apis to set/clear and read
bitfields (based on mask) from CM registers.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 21 +
arch/arm/mach-omap2/cminst44xx.h |6 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index c04bbbe..a482bfa 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -73,6 +73,27 @@ u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8
part, s16 inst,
return v;
}
+u32 omap4_cminst_set_inst_reg_bits(u32 bits, u8 part, s16 inst, s16 idx)
+{
+ return omap4_cminst_rmw_inst_reg_bits(bits, bits, part, inst, idx);
+}
+
+u32 omap4_cminst_clear_inst_reg_bits(u32 bits, u8 part, s16 inst, s16 idx)
+{
+ return omap4_cminst_rmw_inst_reg_bits(bits, 0x0, part, inst, idx);
+}
+
+u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx, u32 mask)
+{
+ u32 v;
+
+ v = omap4_cminst_read_inst_reg(part, inst, idx);
+ v = mask;
+ v = __ffs(mask);
+
+ return v;
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index a6abd0a..2b32c18 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -25,6 +25,12 @@ extern u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16
idx);
extern void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx);
extern u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8 part,
s16 inst, s16 idx);
+extern u32 omap4_cminst_set_inst_reg_bits(u32 bits, u8 part, s16 inst,
+ s16 idx);
+extern u32 omap4_cminst_clear_inst_reg_bits(u32 bits, u8 part, s16 inst,
+ s16 idx);
+extern u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx,
+ u32 mask);
extern int omap4_cm_wait_module_ready(void __iomem *clkctrl_reg);
--
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
[RFC 1/3] OMAP4: clockdomain: Add clkmd static dependency srcs
OMAP4 supports static dependencies and dynamic dependencies
between clock domains. Static dependencies imply both
wakeup as well as sleep dependencies.
Generate all clkdm static dependency srcs.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 313 ++-
1 files changed, 308 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 2fe1570..cb2d02f 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -18,11 +18,6 @@
* published by the Free Software Foundation.
*/
-/*
- * To-Do List
- * - Populate the Sleep/Wakeup dependencies for the domains
- */
-
#include linux/kernel.h
#include linux/io.h
@@ -37,6 +32,275 @@
#include prcm44xx.h
#include prcm_mpu44xx.h
+/* Wakeup and sleep Dependencies for OMAP4 Clock Domains */
+
+static struct clkdm_dep tesla_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = ivahd_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = abe_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_1_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_cfg_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_init_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_2_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_wkup_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_per_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ { NULL },
+};
+
+static struct clkdm_dep l3_gfx_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = ivahd_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_1_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ { NULL },
+};
+
+static struct clkdm_dep ivahd_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = l3_1_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ { NULL },
+};
+
+static struct clkdm_dep l4_secure_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = l4_per_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_1_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ { NULL },
+};
+
+static struct clkdm_dep l3_init_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = ivahd_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_per_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_secure_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_cfg_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l4_wkup_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = abe_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ { NULL },
+};
+
+static struct clkdm_dep mpuss_wkup_sleep_deps[] = {
+ {
+ .clkdm_name = l3_emif_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+ .clkdm_name = l3_1_clkdm,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ },
+ {
+
RE: OMAP DSS Enable clocks in dss_setup_partial_planes
On Wed, 2011-01-12 at 11:20 +, ext Ben Tucker wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: 12 January 2011 09:14 To: ext Ben Tucker Cc: linux-omap@vger.kernel.org Subject: Re: OMAP DSS Enable clocks in dss_setup_partial_planes Hi, On Tue, 2011-01-11 at 17:41 +, ext Ben Tucker wrote: From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Thu, 13 Jan 2011 12:56:45 + Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes Enable the interface clocks while calling configure_dispc(). This description doesn't really tell anything which isn't selfevident from the code below. Please check http://who-t.blogspot.com/2009/12/on-commit-messages.html But I presume this is about RFBI. If so, correct place to enable the clocks would be in rfbi.c. Tomi Apologies for the commit message. Updated patch below. Are you sure the code to enable clocks should be placed in rfbi.c? The DSI code (dsi.c) uses dss_setup_partial_planes() in the same way as rfbi.c and there is no clock enable code there. Also omap_dss_mgr_apply() within manager.c enables clocks for the configure_dispc() call. Usually the user should enable the clocks, in this case rfbi.c. DSI handles this so that the clocks are always enabled when the display is enabled. This could be easier for RFBI also, but due to legacy reasons RFBI currently tries to keep clocks disabled except when its actually doing something. As for omap_dss_mgr_apply(), that function is also a user in this case. Apply is called from outside DSS driver, usually from omapfb. If the clk_enable/disable calls would be in the lower levels, this would mean a) greater overhead from clk_enable/disable calls and b) context saves and restores, as the DSS HW could go into OFF mode when the clocks are disabled. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
On Wednesday 12 January 2011 07:56:45 Len Brown wrote: I'm not fond of inventing a new 3-character abbreviation field for every state because display tools can't handle the existing 16-character name field. I am also not fond of it, but it's a sane and easy solution and appropriate for this issue. If the display tools can only handle 3 characters, then why not have them simply use the 1st 3 characters of the existing name field? You mean use: C3 NHM instead of NHM-C3 for intel_idle? Then userspace has to parse the two informations glued together, get rid of the whitespace, etc. But by sysfs convention a separate file must be used if two data are passed to userspace which is the case here. If that is not unique, then re-arrange the strings so that it is unique... See above, it would unnecessarily make life hard for userspace. Afaik sysfs entries do not consume resources as long as they do not get accessed. Of course the ACPI part of this patch will not apply, as it depends on patch 1 in this series, which was erroneous. For ACPI, the existing name field is already fine, as C%d fits into 3 characters. For acpi_idle only it would work, but this is (nearly) the only one. For example for sh arch: name: SuperH SH SuperH contains two data and should get split up into: name: SuperH abbr: SH By convention the first characters of description could be used, but you would again end up in userspace parsing and double info in one sysfs file. I hope that's enough for convincing, I'd really like to go the .abbr way. Do you give me an acked-by for that one? Thanks, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] X86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
On Wednesday 12 January 2011 07:42:59 Len Brown wrote: I'm happy to see the trace point move up into cpuidle from intel_idle. If somebody is picking this up in a perf tree, Acked-by: Len Brown len.br...@intel.com else I can put it in the idle tree, let me know. I didn't know you have an idle tree. If you can push this one through the idle tree that would be great. I'll go through the rest of my patches and resubmit in some days as soon as some things are clarified. But I need this one to still be included in .38. Please tell me if this could be a problem. Thanks, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
Hi,
On Wed, Jan 12, 2011 at 3:32 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 11, 2011 at 06:02:30PM -0600, Dave Martin wrote:
To make it easier to deal with cases like this, I've had a
go at writing some macros to make copying function bodies
easier, while being robust for ARM and Thumb-2.
How about instead providing some infrastructure which coes the
copy too? Something like:
#define copy_fn_to_sram(to, fn, size) ({ \
__typeof__(fn) f; \
unsigned long ptr; \
__asm__( : =r (ptr) : 0 (fn)); \
memcpy(to, (void *)(ptr ~1), size); \
ptr = (ptr 1) | (unsigned long)to; \
__asm__( : =r (f) : 0 (ptr)); \
f; \
})
omap provides some infrastructure for both allocating SRAM space and
doing the copy, using omap_sram_push() and friends. So I wasn't sure
what the correct level of abstraction was for the new helpers.
Certainly, providing a sort of function memcpy macro like your
copy_fn_to_sram makes sense. I think this should still be safe from a
type system perspective: providing the blind type casts using asm()
appear somewhere in the execution flow C shouldn't make silly
assumptions even if Linux ends up enabling multifile optimisation
sometime in the future.
Would you agree with that assertion?
Used by:
extern void my_func(int foo);
extern int my_func_size;
Potentially, we could define, an extra assembler macro to complement
ENDPROC() which records the size of a function automatically. What do
you think?
void call_my_func(void *to, int arg)
{
void (*fn)(int);
fn = copy_fn_to_sram(to, my_func, my_func_size);
fn(arg);
}
Then if you need to fix the way the copies are done for some
architectural reason, there's only one place to do it.
The model used in the omap code is to copy some functions into SRAM
ahead of time and stash the pointers away to be called later: for that
model, it's not so useful to have something like call_my_func
directly. Also, I wasn't sure whether conflating other functionality
such as cache flushing into the new macros would be a good idea -- is
might be cleaner and more maintainable, but might result in less
efficient usage. Any thoughts?
I'm not sure asm/unified.h is the right place - I don't think this has
anything to do with the unified assembler syntax. Please create a new
header for this.
I suspected unified.h might not be right--- thanks for the feedback.
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
On Wed, Jan 12, 2011 at 10:00:25AM -0600, Dave Martin wrote: omap provides some infrastructure for both allocating SRAM space and doing the copy, using omap_sram_push() and friends. So I wasn't sure what the correct level of abstraction was for the new helpers. Certainly, providing a sort of function memcpy macro like your copy_fn_to_sram makes sense. It'd just be a matter of splitting the copying out of omap_sram_push(). I think this should still be safe from a type system perspective: providing the blind type casts using asm() appear somewhere in the execution flow C shouldn't make silly assumptions even if Linux ends up enabling multifile optimisation sometime in the future. Yes. The only thing that is missing from my version is the flush_icache_range() which should also be there. Used by: extern void my_func(int foo); extern int my_func_size; Potentially, we could define, an extra assembler macro to complement ENDPROC() which records the size of a function automatically. What do you think? That would pad the code out with a fair number of additional integers. That's probably not a good idea. The model used in the omap code is to copy some functions into SRAM ahead of time and stash the pointers away to be called later: for that model, it's not so useful to have something like call_my_func directly. Also, I wasn't sure whether conflating other functionality such as cache flushing into the new macros would be a good idea -- is might be cleaner and more maintainable, but might result in less efficient usage. Any thoughts? My example was only that - an example. You can also use it in the way you describe too: to = omap_sram_push(size); _omap_sram_reprogram_clock = copy_fn_to_sram(to, omap1_sram_reprogram_clock, size); and it'll also ensure type-safety between the omap1_sram_reprogram_clock and _omap_sram_reprogram_clock symbols, which the current code doesn't do. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Q: OMAP 4430 FDIF (Face Detection Interface)
Dear OMAP Developers, I'm working on a driver for the face detection interface (FDIF) IP core that is part of the OMAP 4430 SoC. My development platform is the Pandaboard. I'm make good progress - I was able to set up the IP core according to the TI documents (SWPU231N). For now, I'm not using interrupts but poll while waiting for the results. Starting the FDIF engine (FD_CTRL RUN bit) works as expected and the completion of the procedure is indicated via the FD_CTRL FINISH bit as described by the documentation. So far so good. The issue I have is that no matter what data (i.e., 320x240 grayscale image with faces on it) i send to the core, I always get 0 detections reported in the FD_DNUM register. I've been playing around with the performance parameters exposed by the core via the FD_COND and FD_LHIT registers but had no luck. I have no idea why I'm not getting any detections. And since I do not get any other feedback than the 0 in FD_DNUM from the core, this is difficult to debug. Are there somewhere test images available that are known to produce results other than 0 faces? Maybe someone from TI who is familiar with the FDIF subsystem could help me with this one. I'd really appreciate that! Thank you, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
On Wed, Jan 12, 2011 at 10:11 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jan 12, 2011 at 10:00:25AM -0600, Dave Martin wrote: omap provides some infrastructure for both allocating SRAM space and doing the copy, using omap_sram_push() and friends. So I wasn't sure what the correct level of abstraction was for the new helpers. Certainly, providing a sort of function memcpy macro like your copy_fn_to_sram makes sense. It'd just be a matter of splitting the copying out of omap_sram_push(). I think this should still be safe from a type system perspective: providing the blind type casts using asm() appear somewhere in the execution flow C shouldn't make silly assumptions even if Linux ends up enabling multifile optimisation sometime in the future. Yes. The only thing that is missing from my version is the flush_icache_range() which should also be there. Used by: extern void my_func(int foo); extern int my_func_size; Potentially, we could define, an extra assembler macro to complement ENDPROC() which records the size of a function automatically. What do you think? Sure -- we shouldn't change ENDPROC() itself, but we could have, say, and ENDPROC_SZ() macro which people should use strictly when they know they need it. That would pad the code out with a fair number of additional integers. That's probably not a good idea. The model used in the omap code is to copy some functions into SRAM ahead of time and stash the pointers away to be called later: for that model, it's not so useful to have something like call_my_func directly. Also, I wasn't sure whether conflating other functionality such as cache flushing into the new macros would be a good idea -- is might be cleaner and more maintainable, but might result in less efficient usage. Any thoughts? My example was only that - an example. You can also use it in the way you describe too: to = omap_sram_push(size); _omap_sram_reprogram_clock = copy_fn_to_sram(to, omap1_sram_reprogram_clock, size); and it'll also ensure type-safety between the omap1_sram_reprogram_clock and _omap_sram_reprogram_clock symbols, which the current code doesn't do. Ah, OK -- I'd interpreted call_my_func() as part of the API, rather than a usage example. I'll have a think and update the patch. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with ADATA SD cards on OMAP?
On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
[Ghorai]
We also experienced the same issue using 32GB SD card for omap3 and omap4.
And the problem is seen is that DTO value (in SYSCTL) is not current
in following function.
So add the following modification and please update the status.
And we will submit proper patch towards the same.
static void set_data_timeout(..){
...
cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
+ timeout *=2;
if (timeout) {
...
}
I tried this change. While it seemed to improve things a bit for the
ADATA card I tested, I was still not able to boot successfully.
I will investigate further. Forcing a value of 14 makes the card
work. I'll add a printk to see what dto value is computed by your
patch.
Steve
--
To unsubscribe from this list: send the line unsubscribe 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: 2.6.37-omap1 tag?
Op 11 jan 2011, om 17:34 heeft Tony Lindgren het volgende geschreven: * Anand Gadiyar gadi...@ti.com [110111 03:04]: Koen Kooi wrote: Are there any plans to do a 2.6.37-omap1 tag? Given that linux-omap is now closely tracking mainline, is this still needed? Those tags are no longer needed, the mainline kernel is now the stable kernel and should be used as the base for any distros or products. It turns out that l-o head (.37-rc8 currently) and Linus' .37 differ a lot, so after spending an evening fruitlessly trying to rebase my patches on top of Linus' .37 I decided to go the other way and just do 'git format-patch v2.6.37-rc8..v2.6.37', apply those on top of l-o rc8 and then rebase my patchset on top of that. That was 5 minutes of work. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] omap3: Add basic support for 720MHz part
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
This patch specifically doe following:
* Detect devices capable of 720MHz.
* Add new OPP
* Ensure that OPP is conditionally enabled.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Since last revision:
1) Using opp_enable() to enable the OPP after the OPP
table has been initialized.
2) Starting at 3 levels of indent, the statements had
be broken into multiple lines for most of the code.
So, opted to create a new static that enables the
OPPs corresponding to 720MHz.
3) I have only build tested this patch - will be able
to confirm working tomorrow. With any further change,
if needed. (However, functionally nothing has changed.)
arch/arm/mach-omap2/control.h |7
arch/arm/mach-omap2/id.c | 10 ++
arch/arm/mach-omap2/opp3xxx_data.c| 53 -
arch/arm/plat-omap/include/plat/cpu.h |2 +
4 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..eebc045 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#defineOMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+* Does it support 720MHz?
+*/
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
}
static void __init omap3_check_revision(void)
@@ -445,6 +454,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+ OMAP3_SHOW_FEATURE(720mhz);
printk()\n);
}
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..9405c3f 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -17,8 +17,10 @@
* GNU General Public License for more details.
*/
#include linux/module.h
+#include linux/opp.h
#include plat/cpu.h
+#include plat/omap_device.h
#include omap_opp_data.h
@@ -33,6 +35,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, 135),
+ /* MPU OPP6 */
+ OPP_INITIALIZER(mpu, false, 72000, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +62,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(iva, true, 4, 127),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, 135),
+ /* DSP OPP6 */
+ OPP_INITIALIZER(iva, false, 52000, 135),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
@@ -85,6 +91,46 @@ static struct omap_opp_def __initdata
omap36xx_opp_def_list[] = {
OPP_INITIALIZER(iva, false, 8, 1375000),
};
+
+/**
+ * omap3_opp_enable_720Mhz() - Enable the OPP corresponding to 720MHz
+ *
+ * This function would be executed only if the silicon is capable of
+ * running at the 720MHz.
+ */
+static int __init omap3_opp_enable_720Mhz(void)
+{
+ int r = -ENODEV;
+ struct omap_hwmod *oh_mpu = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *oh_iva = omap_hwmod_lookup(iva);
+
+ if (!oh_mpu || !oh_mpu-od) {
+ goto err;
+ } else {
+ r = opp_enable((oh_mpu-od-pdev.dev), 72000);
+ if (r 0) {
+ pr_err(%s: Unable to enable OPP for mpu., __func__);
+ goto err;
+ }
+ }
+
+ if (!oh_iva || !oh_iva-od) {
+ r = -ENODEV;
+ goto err;
+ } else {
+ r = opp_enable((oh_iva-od-pdev.dev), 52000);
+ if (r 0) {
+ pr_err(%s: Unable to enable OPP for iva., __func__);
+ goto err;
+ }
+ }
+
+ pr_info(Enabled OPP corresponding to 720MHz\n);
+
+err:
+
Re: 2.6.37-omap1 tag?
On Wed, 12 Jan 2011, Koen Kooi wrote: Op 11 jan 2011, om 17:34 heeft Tony Lindgren het volgende geschreven: * Anand Gadiyar gadi...@ti.com [110111 03:04]: Koen Kooi wrote: Are there any plans to do a 2.6.37-omap1 tag? Given that linux-omap is now closely tracking mainline, is this still needed? Those tags are no longer needed, the mainline kernel is now the stable kernel and should be used as the base for any distros or products. It turns out that l-o head (.37-rc8 currently) and Linus' .37 differ a lot, Tony's master branch is basically a development branch. It's rebuilt often, and it's up to Tony what gets added or dropped. The patches that Tony sends to linux-next, and then Linus, go into Tony's omap-for-linus branch. That branch includes changes from other OMAP maintainers or submaintainers, like Kevin, Benoît, myself, etc. A significant amount of effort is focused after -rc6 making sure that omap-for-linus builds cleanly and that features important to us work. Of course, sometimes we miss things, but in general, omap-for-linus receives much more OMAP maintainer testing than Tony's master branch. so after spending an evening fruitlessly trying to rebase my patches on top of Linus' .37 I decided to go the other way and just do 'git format-patch v2.6.37-rc8..v2.6.37', apply those on top of l-o rc8 and then rebase my patchset on top of that. That was 5 minutes of work. Sounds fine if you are creating Koenux. If not, I guess you'll eventually need to rebase the patches on mainline anyway. - Paul
Re: 2.6.37-omap1 tag?
Hi, On Wed, 2011-01-12 at 19:03 +0100, Koen Kooi wrote: Op 11 jan 2011, om 17:34 heeft Tony Lindgren het volgende geschreven: * Anand Gadiyar gadi...@ti.com [110111 03:04]: Koen Kooi wrote: Are there any plans to do a 2.6.37-omap1 tag? Given that linux-omap is now closely tracking mainline, is this still needed? Those tags are no longer needed, the mainline kernel is now the stable kernel and should be used as the base for any distros or products. It turns out that l-o head (.37-rc8 currently) and Linus' .37differ a lot, so after spending an evening fruitlessly trying to rebase my patches on top of Linus' .37 I decided to go the other way and just do 'git format-patch v2.6.37-rc8..v2.6.37', apply those on top of l-o rc8 and then rebase my patchset on top of that. That was 5 minutes of work. regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.37-omap1 tag?
On Wed, 2011-01-12 at 19:03 +0100, Koen Kooi wrote: Op 11 jan 2011, om 17:34 heeft Tony Lindgren het volgende geschreven: * Anand Gadiyar gadi...@ti.com [110111 03:04]: Koen Kooi wrote: Are there any plans to do a 2.6.37-omap1 tag? Given that linux-omap is now closely tracking mainline, is this still needed? Those tags are no longer needed, the mainline kernel is now the stable kernel and should be used as the base for any distros or products. It turns out that l-o head (.37-rc8 currently) and Linus' .37 differ a lot, so after spending an evening fruitlessly trying to rebase my patches on top of Linus' .37 I decided to go the other way and just do 'git format-patch v2.6.37-rc8..v2.6.37', apply those on top of l-o rc8 and then rebase my patchset on top of that. That was 5 minutes of work. Generally git rebase --onto helps a lot on these cases. I also like to use interactive rebase to check if the patches are correct. So, something like: $ git rebase -i --onto linus/master tony/master current branch will rebase current branch on top of linus/master considering that old head was tony/master. You can also use commit ids instead of remote heads, of course. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding gpmc configuration functions, west bridge related
On Wed, Jan 12, 2011 at 12:56:44PM -0800, Sutharsan Ramamoorthy wrote: This patch implements gpmc configuration functions. Why? These gpmc functions are used by westbridge device controller driver in staging tree to configure gpmc timings and bus width. How does the driver live today without these functions? And as this is a staging driver, any way to just leave the functions in the staging driver for now, as there are lots of other things that need to be done to this driver before it can be moved out of the staging tree. Or is this one of those things? This patch has been compiled in linux-2.6.37-rc4 This line isn't needed. You also forgot the line: This patch is corrupted by my email client and can not be applied or built properly. :( New files: 1. ../arch/arm/mach-omap2/usb-cywb-pnand.c 2. ../include/linux/usb/cywb.h Modified files: 1. ../arch/arm/mach-omap2/board-zoom-peripherals.c 2. ../arch/arm/mach-omap2/Makefile 3. ../drivers/staging/westbridge/astoria/arch/arm/mach-omap2/cyashalomap_kernel.c 4. ../drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/cyashalomap_kernel.h 5. ../drivers/staging/westbridge/astoria/device/cyasdevice.c What is this? We know what has been added and modified by virtue of the patch itself. Please use 'git format-patch' to create a patch that includes the diffstat in it automatically, if you want to show that (which you should.) Signed-off by: Sutharsan Ramamoorthy s...@cypress.com This differs from your From: line in your email. If you want to properly attribute the patch's author, please read Documentation/SubmittingPatches to do that. Care to try it again? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding gpmc configuration functions, west bridge related
On Wed, Jan 12, 2011 at 12:56:44PM -0800, Sutharsan Ramamoorthy wrote: This patch implements gpmc configuration functions. snip Oh, and you also sent your email in html format, which caused the mailing lists to reject it. Please fix this as well. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
If the display tools can only handle 3 characters, then why not have them simply use the 1st 3 characters of the existing name field? You mean use: C3 NHM instead of NHM-C3 for intel_idle? Yes. is there a reason that would be a problem? If only 3 characters are useful, then I'd rather see you simly do this: #define CPUIDLE_NAME_LEN 3 Then userspace has to parse the two informations glued together, get rid of the whitespace, etc. what two informations? why is kernel bloat the instrument of choice to avoid the expense of string truncation in user-space tools? But by sysfs convention a separate file must be used if two data are passed to userspace which is the case here. what two data? It is fine for a string to include space characters. If that is not unique, then re-arrange the strings so that it is unique... See above, it would unnecessarily make life hard for userspace. Afaik sysfs entries do not consume resources as long as they do not get accessed. they clutter the source code, they create an additional name for something that arguably already has 3 names -- the state #, the name, and the description. I'd rather delete a few of the fields than add a 4th... Of course the ACPI part of this patch will not apply, as it depends on patch 1 in this series, which was erroneous. For ACPI, the existing name field is already fine, as C%d fits into 3 characters. For acpi_idle only it would work, but this is (nearly) the only one. For example for sh arch: name: SuperH SH SuperH contains two data and should get split up into: name: SuperH abbr: SH acpi/arch/sh/kernel/cpu/shmobile/cpuidle.c already uses state-name = C0, C1, C2. Just use them and be done. By convention the first characters of description could be used, but you would again end up in userspace parsing and double info in one sysfs file. I hope that's enough for convincing, I'd really like to go the .abbr way. Do you give me an acked-by for that one? No. We should not invent an additional abbreviation field. The tools should use the existing name field. If the existing name field is not sufficient, then the states should simply be enumerated and numbers be shown in the GUI. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] X86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
Applied to idle-test git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6.git idle-test Thomas, Please test this branch, and base your incremental patches on it. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states
On Wednesday 12 January 2011 23:25:12 Len Brown wrote: If the display tools can only handle 3 characters, then why not have them simply use the 1st 3 characters of the existing name field? You mean use: C3 NHM instead of NHM-C3 for intel_idle? Yes. is there a reason that would be a problem? A much more elegant solution came to my mind: I'll rewrite the perf timechart patch to do: Title: C-stateName1 [1] , C-stateName2 [2] and later I will refer to the states by 1, 2, ... Eventually a: Description: [1] C-stateDescription1 [2] C-stateDescription2 ... can be put somewhere as well. Please ignore this patch. Stupid that I didn't think of that in the first place. Thanks, Thomas -- To unsubscribe from this list: send the line unsubscribe 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: Passing mem=1G to kernel on Panda, system is unstable.
On Wed, 12 Jan 2011, Bryan Wu wrote: We are trying to build kernel package or GCC natively on OMAP4 panda board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based kernel, we met same instabilities on the system when we try to use mem=1G on the board. Please find our bug tracker here: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 and I think another bug is also related: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370. System will freeze at all when building GCC natively on Panda. Did any folks meet this issue? or we need more simple test case to catch the root cause of this issue. Does the problem also happen if you boot with 'nosmp' on the kernel command line? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Passing mem=1G to kernel on Panda, system is unstable.
On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 12 Jan 2011, Bryan Wu wrote: We are trying to build kernel package or GCC natively on OMAP4 panda board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based kernel, we met same instabilities on the system when we try to use mem=1G on the board. Please find our bug tracker here: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 and I think another bug is also related: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370. System will freeze at all when building GCC natively on Panda. Did any folks meet this issue? or we need more simple test case to catch the root cause of this issue. Does the problem also happen if you boot with 'nosmp' on the kernel command line? Yeah, I think so, since Sebastien reported that 'nosmp' doesn't work either. Thanks, -Bryan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] omap3: Add basic support for 720MHz part
Hi Sanjeev,
On Thu, Jan 13, 2011 at 12:03:54AM +0530, Sanjeev Premi wrote:
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
This patch specifically doe following:
* Detect devices capable of 720MHz.
* Add new OPP
* Ensure that OPP is conditionally enabled.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Since last revision:
1) Using opp_enable() to enable the OPP after the OPP
table has been initialized.
2) Starting at 3 levels of indent, the statements had
be broken into multiple lines for most of the code.
So, opted to create a new static that enables the
OPPs corresponding to 720MHz.
3) I have only build tested this patch - will be able
to confirm working tomorrow. With any further change,
if needed. (However, functionally nothing has changed.)
arch/arm/mach-omap2/control.h |7
arch/arm/mach-omap2/id.c | 10 ++
arch/arm/mach-omap2/opp3xxx_data.c| 53
-
arch/arm/plat-omap/include/plat/cpu.h |2 +
4 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..eebc045 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
#define FEAT_NEON 0
#define FEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#define OMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+ * Does it support 720MHz?
+ */
multiline style comment
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
braces not required
}
static void __init omap3_check_revision(void)
@@ -445,6 +454,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+ OMAP3_SHOW_FEATURE(720mhz);
printk()\n);
}
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..9405c3f 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -17,8 +17,10 @@
* GNU General Public License for more details.
*/
#include linux/module.h
+#include linux/opp.h
#include plat/cpu.h
+#include plat/omap_device.h
#include omap_opp_data.h
@@ -33,6 +35,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(mpu, true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, 135),
+ /* MPU OPP6 */
+ OPP_INITIALIZER(mpu, false, 72000, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +62,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4, 127),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, 135),
+ /* DSP OPP6 */
+ OPP_INITIALIZER(iva, false, 52000, 135),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
@@ -85,6 +91,46 @@ static struct omap_opp_def __initdata
omap36xx_opp_def_list[] = {
OPP_INITIALIZER(iva, false, 8, 1375000),
};
+
+/**
+ * omap3_opp_enable_720Mhz() - Enable the OPP corresponding to 720MHz
+ *
+ * This function would be executed only if the silicon is capable of
+ * running at the 720MHz.
+ */
+static int __init omap3_opp_enable_720Mhz(void)
+{
+ int r = -ENODEV;
+ struct omap_hwmod *oh_mpu = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *oh_iva = omap_hwmod_lookup(iva);
+
+ if (!oh_mpu || !oh_mpu-od) {
+ goto err;
+ } else {
+ r = opp_enable((oh_mpu-od-pdev.dev), 72000);
+ if (r 0) {
+ pr_err(%s: Unable to enable OPP for mpu., __func__);
since you have dev pointer, pr_err can be replaced with dev_err
+ goto err;
+ }
+ }
+
+ if (!oh_iva || !oh_iva-od) {
+ r = -ENODEV;
+ goto err;
+ } else {
+ r = opp_enable((oh_iva-od-pdev.dev), 52000);
+
[PATCH 12/12] cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
From: Thomas Renninger tr...@suse.de
Currently intel_idle and acpi_idle driver show double cpu_idle exit idle
events - this patch fixes it and makes cpu_idle events throwing less complex.
It also introduces cpu_idle events for all architectures which use
the cpuidle subsystem, namely:
- arch/arm/mach-at91/cpuidle.c
- arch/arm/mach-davinci/cpuidle.c
- arch/arm/mach-kirkwood/cpuidle.c
- arch/arm/mach-omap2/cpuidle34xx.c
- arch/drivers/acpi/processor_idle.c (for all cases, not only mwait)
- arch/x86/kernel/process.c (did throw events before, but was a mess)
- drivers/idle/intel_idle.c (did throw events before)
Convention should be:
Fire cpu_idle events inside the current pm_idle function (not somewhere
down the the callee tree) to keep things easy.
Current possible pm_idle functions in X86:
c1e_idle, poll_idle, cpuidle_idle_call, mwait_idle, default_idle
- this is really easy is now.
This affects userspace:
The type field of the cpu_idle power event can now direclty get
mapped to:
/sys/devices/system/cpu/cpuX/cpuidle/stateX/{name,desc,usage,time,...}
instead of throwing very CPU/mwait specific values.
This change is not visible for the intel_idle driver.
For the acpi_idle driver it should only be visible if the vendor
misses out C-states in his BIOS.
Another (perf timechart) patch reads out cpuidle info of cpu_idle
events from:
/sys/.../cpuidle/stateX/*, then the cpuidle events are mapped
to the correct C-/cpuidle state again, even if e.g. vendors miss
out C-states in their BIOS and for example only export C1 and C3.
- everything is fine.
Signed-off-by: Thomas Renninger tr...@suse.de
CC: Robert Schoene robert.scho...@tu-dresden.de
CC: Jean Pihet j-pi...@ti.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: Frederic Weisbecker fweis...@gmail.com
CC: linux...@lists.linux-foundation.org
CC: linux-a...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-perf-us...@vger.kernel.org
CC: linux-omap@vger.kernel.org
Signed-off-by: Len Brown len.br...@intel.com
---
arch/x86/kernel/process.c|6 --
arch/x86/kernel/process_32.c |4
arch/x86/kernel/process_64.c |6 --
drivers/cpuidle/cpuidle.c| 10 --
drivers/idle/intel_idle.c|2 --
5 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 09c08a1..67e96e6 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -386,6 +386,8 @@ void default_idle(void)
else
local_irq_enable();
current_thread_info()-status |= TS_POLLING;
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
} else {
local_irq_enable();
/* loop is done by the caller */
@@ -443,8 +445,6 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
*/
void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
{
- trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id());
- trace_cpu_idle((ax4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(__this_cpu_ptr(cpu_info),
X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -471,6 +471,8 @@ static void mwait_idle(void)
__sti_mwait(0, 0);
else
local_irq_enable();
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
} else
local_irq_enable();
}
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 4b9befa..8d12878 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -57,8 +57,6 @@
#include asm/syscalls.h
#include asm/debugreg.h
-#include trace/events/power.h
-
asmlinkage void ret_from_fork(void) __asm__(ret_from_fork);
/*
@@ -113,8 +111,6 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
- trace_power_end(smp_processor_id());
- trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4c818a7..bd387e8 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -51,8 +51,6 @@
#include asm/syscalls.h
#include asm/debugreg.h
-#include trace/events/power.h
-
asmlinkage extern void ret_from_fork(void);
DEFINE_PER_CPU(unsigned long, old_rsp);
@@ -141,10 +139,6 @@ void cpu_idle(void)
pm_idle();
start_critical_timings();
- trace_power_end(smp_processor_id());
-
RE: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x reset
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Monday, September 27, 2010 8:26 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Premi, Sanjeev; t...@atomide.com
Subject: Re: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x
reset
Varadarajan, Charulatha ch...@ti.com writes:
Sanjeev,
With GPIO hwmod series, OMAP3EVM board is not up with DHCP + nfs root.
This issue was reported by Kevin.
The root cause of this issue is that during OMAP3EVM board init, the
Ethernet controller (smsc911x) is not reset and it relies on the uboot
configurations for it's operations. The reset GPIO pin used for this
purpose is not even reserved.
After gpio hmwod series are merged, this patch is required to make the
EVM board working. Also omap3evm_init_smsc911x() needs to be fixed
including CS settings and other required settings for Ethernet
controller.
Links to related discussions:
http://www.spinics.net/lists/linux-omap/msg37234.html
http://www.spinics.net/lists/linux-omap/msg36698.html
http://www.spinics.net/lists/linux-omap/msg36799.html
The below patch is tested on OMAP3 EVM board (ES3.1).
Also note that the patch below didn't work on my EVM (ES2.1), making me
assume that it uses a different GPIO for older boards.
[Hiremath, Vaibhav] I have also tried it on my REV-G version of EVM (Silicon
ES3.1) and it is not working for me.
Trying to debug further.
Thanks,
Vaibhav
Kevin
-Original Message-
From: Varadarajan, Charulatha
Sent: Saturday, September 25, 2010 5:07 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; t...@atomide.com; Premi, Sanjeev;
Varadarajan, Charulatha
Subject: [PATCH RFC:] FIX: OMAP3EVM: Ethernet controller smsc911x reset
Do reset of Ethernet controller smsc911x using OMAP gpio7
while initializing the Ethernet controller.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index f76d9c0..54a7e20 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -55,6 +55,7 @@
#define OMAP3EVM_ETHR_SIZE1024
#define OMAP3EVM_ETHR_ID_REV 0x50
#define OMAP3EVM_ETHR_GPIO_IRQ176
+#define OMAP3EVM_ETHR_GPIO_RST 7
#define OMAP3EVM_SMSC911X_CS 5
static u8 omap3_evm_version;
@@ -134,6 +135,20 @@ static inline void __init
omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (gpio_request(OMAP3EVM_ETHR_GPIO_RST, SMSC911x gpio) 0) {
+ pr_err(KERN_ERR Failed to request GPIO8 for smsc911x
gpio\n);
+ return;
+ }
+
+ gpio_direction_output(OMAP3EVM_ETHR_GPIO_RST, 1);
+
+ /* reset pulse to ethernet controller*/
+ gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 0);
+ usleep_range(150, 220);
+ gpio_set_value(OMAP3EVM_ETHR_GPIO_RST, 1);
+ usleep_range(1, 2);
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, SMSC911x irq) 0) {
printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
OMAP3EVM_ETHR_GPIO_IRQ);
--
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
--
To unsubscribe from this list: send the line unsubscribe 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: Issues with ADATA SD cards on OMAP?
On Wed, Jan 12, 2011 at 9:48 AM, Steve Sakoman sako...@gmail.com wrote:
On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
[Ghorai]
We also experienced the same issue using 32GB SD card for omap3 and omap4.
And the problem is seen is that DTO value (in SYSCTL) is not current
in following function.
So add the following modification and please update the status.
And we will submit proper patch towards the same.
static void set_data_timeout(..){
...
cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
+ timeout *=2;
if (timeout) {
...
}
I tried this change. While it seemed to improve things a bit for the
ADATA card I tested, I was still not able to boot successfully.
I will investigate further. Forcing a value of 14 makes the card
work. I'll add a printk to see what dto value is computed by your
patch.
The printk showed that dto was being set in the range 11-13 with your patch.
I still was seeing some corruption occurring with the patch -- but at
a much lower level that without the patch.
Since I knew that the card would definitely work if dto were hard
coded to 14, I next tried bumping the value your patch computed by 1:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9c7c590..09a7e21 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1372,6 +1372,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host,
dto -= 13;
else
dto = 0;
+ dto++;
if (dto 14)
dto = 14;
}
I've been running fairly intensive testing for the past 6 hours with out issue.
This chunk of code really should be reviewed by an mmc expert -- I
have a feeling that it could be simplified or at least made a bit
easier to understand!
Steve
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap3: Add basic support for 720MHz part
-Original Message-
From: G, Manjunath Kondaiah [mailto:manj...@ti.com]
Sent: Thursday, January 13, 2011 9:24 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv2] omap3: Add basic support for 720MHz part
Hi Sanjeev,
[snip]...[snip]
*/
+
+ /*
+* Does it support 720MHz?
+*/
multiline style comment
[sp] This is used many places. Don't see any issue with it.
unless you really want to see this on single line.
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
braces not required
[sp] Will change. forgot to remove after moving code to a
different function.
}
[snip]...[snip]
+ r = opp_enable((oh_mpu-od-pdev.dev), 72000);
+ if (r 0) {
+ pr_err(%s: Unable to enable OPP for
mpu., __func__);
since you have dev pointer, pr_err can be replaced with dev_err
[sp] Idea was to get to this function - in case of error; but can
be changed as well.
+ goto err;
+ }
+ }
+
+ if (!oh_iva || !oh_iva-od) {
+ r = -ENODEV;
+ goto err;
+ } else {
+ r = opp_enable((oh_iva-od-pdev.dev), 52000);
+ if (r 0) {
+ pr_err(%s: Unable to enable OPP for
iva., __func__);
+ goto err;
+ }
+ }
Can be optimized as(not tested and compiled):
struct platform_device *pdev;
[sp] Like this! ... to get to dev.
struct omap_hwmod *oh_mpu = omap_hwmod_lookup(mpu);
struct omap_hwmod *oh_iva = omap_hwmod_lookup(iva);
int r = -ENODEV;
if (!oh_mpu || !oh_mpu-od || !oh_iva || !oh_iva-od)
goto err;
pdev = oh_mpu-od-pdev;
r = opp_enable(pdev-dev, 72000);
if (r 0) {
dev_err(pdev-dev, Unable to enable OPP for mpu.\n);
goto err;
}
pdev = oh_iva-od-pdev;
r = opp_enable(pdev-dev, 52000);
if (r 0) {
dev_err(pdev-dev, Unable to enable OPP for iva.\n);
goto err;
}
Do you see any issues?
Though it is not considered in this patch, but in the devices that
don't contain iva, the code related to enabling the iva freq can
be easily excluded in current flow.
Plan to send v3 with all other changes by evening. The optimization
will only be undone once I introduce the check for presence of IVA.
~sanjeev
-Manjunath
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
