Re: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
snip
+/**
+ * omap_timer_init - top level timer device initialization
+ *
+ * uses dedicated hwmod api to parse through hwmod database for
+ * given class names and then build and register the timer device.
+ */
+static int __init omap2_dmtimer_device_init(void)
+{
+ int ret = omap_hwmod_for_each_by_class(timer, omap2_timer_init,
NULL);
+
+ if (unlikely(ret))
+ pr_debug(%s: device registration FAILED\n, __func__);
+
+ return ret;
+}
+arch_initcall(omap2_dmtimer_device_init);
While introducing this, calls to omap_dm_timer_init() should be
removed. Else, the init
will happen twice for dmtimer devices
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP: hwmod core fix and cleanup for 2.6.38
Hi Paul, Here is a small series that just remove the omap_hwmod_mutex and move functions not needed at runtime to the __init section. It fix as well a bug discovered during the on-going hwmod migration of device that does have a functional clock external (mcpdm). The series is based on mainline (2.6.37-rc2) and is available here: git://gitorious.org/omap-pm/linux.git for_2.6.38/hwmod Tested on SDP4430 ES2.0 with omap2plus_defconfig. It still requires some test on OMAP3 and OMAP2. Regards, Benoit Benoit Cousson (3): OMAP: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister OMAP: hwmod: Mark functions used only during initialization with __init OMAP: hwmod: Remove omap_hwmod_mutex Rajendra Nayak (1): OMAP: hwmod: Disable clocks when hwmod enable fails arch/arm/mach-omap2/omap_hwmod.c | 152 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 - 2 files changed, 54 insertions(+), 100 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAP: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister
Do not allow omap_hwmod_register to be used outside the core
hwmod code. An omap_hwmod should be register only at init time.
Remove the omap_hwmod_unregister that is not used today since the
hwmod list will be build once at init time and never be modified
at runtime.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 135 ++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 -
2 files changed, 54 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..9cedea0 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1374,6 +1374,58 @@ static int _setup(struct omap_hwmod *oh, void *data)
return 0;
}
+/**
+ * _register - register a struct omap_hwmod
+ * @oh: struct omap_hwmod *
+ *
+ * Registers the omap_hwmod @oh. Returns -EEXIST if an omap_hwmod
+ * already has been registered by the same name; -EINVAL if the
+ * omap_hwmod is in the wrong state, if @oh is NULL, if the
+ * omap_hwmod's class field is NULL; if the omap_hwmod is missing a
+ * name, or if the omap_hwmod's class is missing a name; or 0 upon
+ * success.
+ *
+ * XXX The data should be copied into bootmem, so the original data
+ * should be marked __initdata and freed after init. This would allow
+ * unneeded omap_hwmods to be freed on multi-OMAP configurations. Note
+ * that the copy process would be relatively complex due to the large number
+ * of substructures.
+ */
+static int _register(struct omap_hwmod *oh)
+{
+ int ret, ms_id;
+
+ if (!oh || !oh-name || !oh-class || !oh-class-name ||
+ (oh-_state != _HWMOD_STATE_UNKNOWN))
+ return -EINVAL;
+
+ mutex_lock(omap_hwmod_mutex);
+
+ pr_debug(omap_hwmod: %s: registering\n, oh-name);
+
+ if (_lookup(oh-name)) {
+ ret = -EEXIST;
+ goto ohr_unlock;
+ }
+
+ ms_id = _find_mpu_port_index(oh);
+ if (!IS_ERR_VALUE(ms_id)) {
+ oh-_mpu_port_index = ms_id;
+ oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
+ } else {
+ oh-_int_flags |= _HWMOD_NO_MPU_PORT;
+ }
+
+ list_add_tail(oh-node, omap_hwmod_list);
+
+ oh-_state = _HWMOD_STATE_REGISTERED;
+
+ ret = 0;
+
+ohr_unlock:
+ mutex_unlock(omap_hwmod_mutex);
+ return ret;
+}
/* Public functions */
@@ -1427,59 +1479,6 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
- * omap_hwmod_register - register a struct omap_hwmod
- * @oh: struct omap_hwmod *
- *
- * Registers the omap_hwmod @oh. Returns -EEXIST if an omap_hwmod
- * already has been registered by the same name; -EINVAL if the
- * omap_hwmod is in the wrong state, if @oh is NULL, if the
- * omap_hwmod's class field is NULL; if the omap_hwmod is missing a
- * name, or if the omap_hwmod's class is missing a name; or 0 upon
- * success.
- *
- * XXX The data should be copied into bootmem, so the original data
- * should be marked __initdata and freed after init. This would allow
- * unneeded omap_hwmods to be freed on multi-OMAP configurations. Note
- * that the copy process would be relatively complex due to the large number
- * of substructures.
- */
-int omap_hwmod_register(struct omap_hwmod *oh)
-{
- int ret, ms_id;
-
- if (!oh || !oh-name || !oh-class || !oh-class-name ||
- (oh-_state != _HWMOD_STATE_UNKNOWN))
- return -EINVAL;
-
- mutex_lock(omap_hwmod_mutex);
-
- pr_debug(omap_hwmod: %s: registering\n, oh-name);
-
- if (_lookup(oh-name)) {
- ret = -EEXIST;
- goto ohr_unlock;
- }
-
- ms_id = _find_mpu_port_index(oh);
- if (!IS_ERR_VALUE(ms_id)) {
- oh-_mpu_port_index = ms_id;
- oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
- } else {
- oh-_int_flags |= _HWMOD_NO_MPU_PORT;
- }
-
- list_add_tail(oh-node, omap_hwmod_list);
-
- oh-_state = _HWMOD_STATE_REGISTERED;
-
- ret = 0;
-
-ohr_unlock:
- mutex_unlock(omap_hwmod_mutex);
- return ret;
-}
-
-/**
* omap_hwmod_lookup - look up a registered omap_hwmod by name
* @name: name of the omap_hwmod to look up
*
@@ -1558,8 +1557,8 @@ int omap_hwmod_init(struct omap_hwmod **ohs)
oh = *ohs;
while (oh) {
if (omap_chip_is(oh-omap_chip)) {
- r = omap_hwmod_register(oh);
- WARN(r, omap_hwmod: %s: omap_hwmod_register returned
+ r = _register(oh);
+ WARN(r, omap_hwmod: %s: _register returned
%d\n, oh-name, r);
}
oh = *++ohs;
@@ -1597,32 +1596,6 @@ int omap_hwmod_late_init(u8 skip_setup_idle)
}
[PATCH 2/4] OMAP: hwmod: Mark functions used only during initialization with __init
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs
that will be used only during the omap_hwmod initialization phase.
There is no need to keep them for runtime.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9cedea0..8e47006 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -675,7 +675,7 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)
* Returns the array index of the OCP slave port that the MPU
* addresses the device on, or -EINVAL upon error or not found.
*/
-static int _find_mpu_port_index(struct omap_hwmod *oh)
+static int __init _find_mpu_port_index(struct omap_hwmod *oh)
{
int i;
int found = 0;
@@ -709,7 +709,7 @@ static int _find_mpu_port_index(struct omap_hwmod *oh)
* Return the virtual address of the base of the register target of
* device @oh, or NULL on error.
*/
-static void __iomem *_find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
+static void __iomem * __init _find_mpu_rt_base(struct omap_hwmod *oh, u8 index)
{
struct omap_hwmod_ocp_if *os;
struct omap_hwmod_addr_space *mem;
@@ -1391,7 +1391,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
* that the copy process would be relatively complex due to the large number
* of substructures.
*/
-static int _register(struct omap_hwmod *oh)
+static int __init _register(struct omap_hwmod *oh)
{
int ret, ms_id;
@@ -1541,7 +1541,7 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh,
void *data),
* listed in @ohs that are valid for this chip. Returns -EINVAL if
* omap_hwmod_init() has already been called or 0 otherwise.
*/
-int omap_hwmod_init(struct omap_hwmod **ohs)
+int __init omap_hwmod_init(struct omap_hwmod **ohs)
{
struct omap_hwmod *oh;
int r;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] OMAP: hwmod: Remove omap_hwmod_mutex
The hwmod list will be built are init time and never
modified at runtime. There is no need anymore to protect
the list from concurrent access using the mutex.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 26 --
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8e47006..f221587 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,8 +156,6 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
-static DEFINE_MUTEX(omap_hwmod_mutex);
-
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -874,7 +872,6 @@ static void _shutdown_sysc(struct omap_hwmod *oh)
* @name: find an omap_hwmod by name
*
* Return a pointer to an omap_hwmod by name, or NULL if not found.
- * Caller must hold omap_hwmod_mutex.
*/
static struct omap_hwmod *_lookup(const char *name)
{
@@ -1399,14 +1396,10 @@ static int __init _register(struct omap_hwmod *oh)
(oh-_state != _HWMOD_STATE_UNKNOWN))
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
-
pr_debug(omap_hwmod: %s: registering\n, oh-name);
- if (_lookup(oh-name)) {
- ret = -EEXIST;
- goto ohr_unlock;
- }
+ if (_lookup(oh-name))
+ return -EEXIST;
ms_id = _find_mpu_port_index(oh);
if (!IS_ERR_VALUE(ms_id)) {
@@ -1422,8 +1415,6 @@ static int __init _register(struct omap_hwmod *oh)
ret = 0;
-ohr_unlock:
- mutex_unlock(omap_hwmod_mutex);
return ret;
}
@@ -1492,9 +1483,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
if (!name)
return NULL;
- mutex_lock(omap_hwmod_mutex);
oh = _lookup(name);
- mutex_unlock(omap_hwmod_mutex);
return oh;
}
@@ -1520,13 +1509,11 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(omap_hwmod_mutex);
return ret;
}
@@ -2048,9 +2035,8 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh,
const char *name)
* @fn: callback function pointer to call for each hwmod in class @classname
* @user: arbitrary context data to pass to the callback function
*
- * For each omap_hwmod of class @classname, call @fn. Takes
- * omap_hwmod_mutex to prevent the hwmod list from changing during the
- * iteration. If the callback function returns something other than
+ * For each omap_hwmod of class @classname, call @fn.
+ * If the callback function returns something other than
* zero, the iterator is terminated, and the callback function's return
* value is passed back to the caller. Returns 0 upon success, -EINVAL
* if @classname or @fn are NULL, or passes back the error code from @fn.
@@ -2069,8 +2055,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
pr_debug(omap_hwmod: %s: looking for modules of class %s\n,
__func__, classname);
- mutex_lock(omap_hwmod_mutex);
-
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
if (!strcmp(temp_oh-class-name, classname)) {
pr_debug(omap_hwmod: %s: %s: calling callback fn\n,
@@ -2081,8 +2065,6 @@ int omap_hwmod_for_each_by_class(const char *classname,
}
}
- mutex_unlock(omap_hwmod_mutex);
-
if (ret)
pr_debug(omap_hwmod: %s: iterator terminated early: %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
[PATCH 4/4] OMAP: hwmod: Disable clocks when hwmod enable fails
From: Rajendra Nayak rna...@ti.com
In cases where a module (hwmod) does not become accesible on enabling
the main clocks (can happen if there are external clocks needed
for the module to become accesible), make sure the clocks are not
left enabled.
This ensures that when the requisite external dependencies are met
a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable
and disable clocks using clk framework. Leaving the clocks enabled in
the error case causes additional usecounting at the clock framework
level leaving the clock enabled forever.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f221587..896012d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1210,6 +1210,7 @@ int _omap_hwmod_enable(struct omap_hwmod *oh)
_enable_sysc(oh);
}
} else {
+ _disable_clocks(oh);
pr_debug(omap_hwmod: %s: _wait_target_ready: %d\n,
oh-name, r);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] AM35x: musb: fix compilation error
Fixes compilation error as control.h APIs are not available to
drivers/usb/musb/am35x.c file. Earlier it was getting included
from plat/control.h but now moved to new location by another
pacth.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against latest Linus's tree (v2.6.37-rc3)
arch/arm/plat-omap/include/plat/usb.h |2 ++
drivers/usb/musb/am35x.c |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..f1b8b40 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -6,6 +6,8 @@
#include linux/usb/musb.h
#include plat/board.h
+#include ../../../mach-omap2/control.h
+
#define OMAP3_HS_USB_PORTS 3
enum ehci_hcd_omap_mode {
EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b0aabf3..30f524a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -30,7 +30,6 @@
#include linux/clk.h
#include linux/io.h
-#include plat/control.h
#include plat/usb.h
#include musb_core.h
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] musb_gadget: fix compilation warning
Fixes below compilation warning when musb driver is compiled for PIO mode. drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx': drivers/usb/musb/musb_gadget.c:840: warning: label 'exit' defined but not used Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Patch created against latest Linus's tree (v2.6.37-rc3) drivers/usb/musb/musb_gadget.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 36cfd06..bb9f05e 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -837,7 +837,9 @@ void musb_g_rx(struct musb *musb, u8 epnum) if (!request) return; } +#if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_TUSB_OMAP_DMA) exit: +#endif /* Analyze request */ rxstate(musb, to_musb_request(request)); } -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Patch v1] AM35xx: Craneboard: Add USB EHCI support
Hi Sergei,
Thanks for review, I will modify and resend patch.
With Regards
Srinath
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Saturday, November 20, 2010 5:09 PM
To: srin...@mistralsolutions.com
Cc: linux-omap@vger.kernel.org; n...@ti.com; li...@arm.linux.org.uk;
ume...@mistralsolutions.com; t...@atomide.com;
nagen...@mistralsolutions.com; linux-ker...@vger.kernel.org;
khil...@deeprootsystems.com; j...@ti.com;
linux-arm-ker...@lists.infradead.org
Subject: Re: [Patch v1] AM35xx: Craneboard: Add USB EHCI support
Hello.
On 19-11-2010 19:07, srin...@mistralsolutions.com wrote:
From: Srinathsrin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
Signed-off-by: Srinathsrin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..0e1a806 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
[...]
@@ -53,10 +55,29 @@ static void __init am3517_crane_init_irq(void)
omap_gpio_init();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 38,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_crane_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(35, OMAP_PIN_OUTPUT);
+ gpio_request(35, usb_ehci_enable);
+ gpio_direction_output(35, 1);
+ gpio_set_value(35, 1);
There's no need to call gpio_set_value(), as gpio_direction_output() has
already set the GPIO's value.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2] AM35xx: Craneboard: Add USB EHCI support
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..91791bc 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -28,8 +28,10 @@
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
#include mux.h
+#include control.h
/* Board initialization */
static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
@@ -53,10 +55,28 @@ static void __init am3517_crane_init_irq(void)
omap_gpio_init();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 38,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_crane_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(35, OMAP_PIN_OUTPUT);
+ gpio_request(35, usb_ehci_enable);
+ gpio_direction_output(35, 1);
+ omap_mux_init_gpio(38, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
}
MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
--
1.7.1.226.g770c5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #8)
On Thu, Nov 18, 2010 at 5:11 PM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: On Thu, 2010-11-18 at 10:14 +0800, ext Bryan Wu wrote: On Wed, Nov 17, 2010 at 10:18 PM, Tomi Valkeinen Are you also interested in solving the backlight issue? =) Yeah, can I start with drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c. I plan to move the blacklight code to drivers/video/blacklight/ and let sharp_ls to use panel-generic-dpi.c driver. Yes, I think that's a good solution for the panels which have a separate backlight (ie. all these dummy panels). However, I'm not sure how that would work for panels with more integrated backlight, for example Taal. But we don't need to worry about that right now. As I'm working on the sharp-ls panel driver, I just find the backlight code is almost dummy functions which will call dssdev-set_backlight(). How about create platform driver for sharp-ls backlight driver? We pass those dssdev data from platform data struct. Thanks a lot, -- Bryan Wu bryan...@canonical.com Kernel Developer +86.138-1617-6545 Mobile Ubuntu Kernel Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 1:55 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha
Subject: Re: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
snip
+/**
+ * omap_timer_init - top level timer device initialization
+ *
+ * uses dedicated hwmod api to parse through hwmod database for
+ * given class names and then build and register the timer device.
+ */
+static int __init omap2_dmtimer_device_init(void)
+{
+ int ret = omap_hwmod_for_each_by_class(timer,
omap2_timer_init, NULL);
+
+ if (unlikely(ret))
+ pr_debug(%s: device registration FAILED\n, __func__);
+
+ return ret;
+}
+arch_initcall(omap2_dmtimer_device_init);
While introducing this, calls to omap_dm_timer_init() should be
removed. Else, the init
will happen twice for dmtimer devices
This function is called only when the switch-over takes place.
That is why you still see the omap_dm_timer_init().
So this is more to do with organizing the patch.
I could have introduced this init code as part of platform driver
Swith-over.
--
Tarun
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
On Mon, Nov 22, 2010 at 14:30, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 1:55 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara; Basak, Partha
Subject: Re: [PATCHv4 11/14] OMAP2+: dmtimer: convert to platform devices
snip
+/**
+ * omap_timer_init - top level timer device initialization
+ *
+ * uses dedicated hwmod api to parse through hwmod database for
+ * given class names and then build and register the timer device.
+ */
+static int __init omap2_dmtimer_device_init(void)
+{
+ int ret = omap_hwmod_for_each_by_class(timer,
omap2_timer_init, NULL);
+
+ if (unlikely(ret))
+ pr_debug(%s: device registration FAILED\n, __func__);
+
+ return ret;
+}
+arch_initcall(omap2_dmtimer_device_init);
While introducing this, calls to omap_dm_timer_init() should be
removed. Else, the init
will happen twice for dmtimer devices
This function is called only when the switch-over takes place.
That is why you still see the omap_dm_timer_init().
So this is more to do with organizing the patch.
Exactly. Please take care of this.
I could have introduced this init code as part of platform driver
Swith-over.
--
Tarun
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device driver
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 12:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device
driver
snip
-/*
- * Reads timer registers in posted and non-posted mode. The posted mode
bit
- * is encoded in reg. Note that in posted mode write pending bit must
be
- * checked. Otherwise a read of a non completed write will produce an
error.
+/**
+ * omap_dm_timer_read_reg - read timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which read operation to perform
+ * @reg: lowest byte holds the register offset
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
write
+ * pending bit must be checked. Otherwise a read of a non completed
write
+ * will produce an error.
*/
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer,
u32 reg)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-func_offst)
+ 0xff)) (reg WPSHIFT))
You may add a timeout in this.
There are few reasons why I have not done:
(1) This was in this way from the beginning and I thought some analysis
Was done already for not adding timeout and so did not wish to alter that.
(2) wanted to keep low level functions as simple as possible by avoiding
As many checks as possible unless really needed.
(3) The client driver can take care of timeout. Even if timeout is
Introduced in this api, the client driver anyways have to check for the
Timeout.
--
Tarun
cpu_relax();
return readl(timer-io_base + (reg 0xff));
}
-/*
- * Writes timer registers in posted and non-posted mode. The posted
mode bit
- * is encoded in reg. Note that in posted mode the write pending bit
must be
- * checked. Otherwise a write on a register which has a pending write
will be
- * lost.
+/**
+ * omap_dm_timer_write_reg - write timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which write operation is to perform
+ * @reg: lowest byte holds the register offset
+ * @value: data to write into the register
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode the
write
+ * pending bit must be checked. Otherwise a write on a register which
has a
+ * pending write will be lost.
*/
static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32
reg,
u32 value)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-func_offst)
+ 0xff)) (reg WPSHIFT))
Ditto.
cpu_relax();
writel(value, timer-io_base + (reg 0xff));
}
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On Fri, Nov 19, 2010 at 03:50:02PM +0100, Cousson, Benoit wrote: Most of the time, we do not want to use the IP revision because it is un-accurate and does not reflect the change we'd like to track. For example some time a minor change in the RTL that will not impact the SW at all might trigger a change in the IP revision, whereas on the other hand a major bug fix that will impact the SW is not capture in the IP revision... yeah, that's bad, but this can happen. That's why we are relying on a rev field in the hwmod. But then, what's inside this rev field ? Is it some internal revision of hwmod or do you read from the hw ? -- 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] omap4: 4430sdp: enable the ehci port on 4430SDP
On Mon, Nov 22, 2010 at 12:13:19AM +0530, Anand Gadiyar wrote: From: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Tony Lindgren t...@atomide.com Tony, if you give me your Ack I can take this with Greg since it depends on the series I'm checking now. -- 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 04/11] omap: clock: add clkdev aliases for EHCI clocks
On Mon, Nov 22, 2010 at 12:10:07AM +0530, Anand Gadiyar wrote: Add clkdev aliases for the USBHOST and USBTLL clocks on OMAP3 and OMAP4, so that the driver can refer to the clocks using a common alias. This will disappear when the driver is converted to use the hwmod database, but until then this patch is needed. Signed-off-by: Anand Gadiyar gadi...@ti.com Tony, I need your Ack here too. -- 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 1/2] AM35x: musb: fix compilation error
Hi,
On Mon, Nov 22, 2010 at 02:22:40PM +0530, Ajay Kumar Gupta wrote:
Fixes compilation error as control.h APIs are not available to
drivers/usb/musb/am35x.c file. Earlier it was getting included
from plat/control.h but now moved to new location by another
pacth.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Tony ? Do you ack the usage of that header ?
---
Patch created against latest Linus's tree (v2.6.37-rc3)
arch/arm/plat-omap/include/plat/usb.h |2 ++
drivers/usb/musb/am35x.c |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..f1b8b40 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -6,6 +6,8 @@
#include linux/usb/musb.h
#include plat/board.h
+#include ../../../mach-omap2/control.h
+
#define OMAP3_HS_USB_PORTS 3
enum ehci_hcd_omap_mode {
EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index b0aabf3..30f524a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -30,7 +30,6 @@
#include linux/clk.h
#include linux/io.h
-#include plat/control.h
#include plat/usb.h
#include musb_core.h
--
1.6.2.4
--
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 10/11] usb: ehci-omap: Add OMAP4 support
Hi, On Mon, Nov 22, 2010 at 12:10:13AM +0530, Anand Gadiyar wrote: missing description here. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com After a description is added, I'll be waiting for Tony's Ack. -- 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 v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
Hi Thomas / Kevin,
I did verify Thomas Petazzoni's patch - [PATCH] omap: prcm: switch to a
chained IRQ handler mechanism, and I have below questions or comments.
1. I see for each WKUP_ST or IO_ST interrupt the _prcm_int_handle_wakeup
handler is getting called 2 times which impacts on performance.
printk(irq:%d,%d\n,irq,c); just before returning from the handler shows.
[ 221.966308] irq wkst:377,2
[ 221.968597] irq wkst:377,0
I see, the code checking the below warning is removed, won't it be good to
retain this check ?
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Also need to address the corner case issue, for which I submitted the patch
fix.
[ 222.002563] irq wkst:368,3
[ 222.004913] irq iost:377,0
Regards
Gowda
From: ext Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, November 19, 2010 6:36 PM
To: Gowda Madhusudhan.1 (EXT-Elektrobit/Helsinki)
Cc: linux-omap@vger.kernel.org; p...@pwsan.com
Subject: Re: [PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but
no wakeup sources
Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com writes:
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Since the above warning condition is only valid if the prcm_interrupt
handler is called but no wakeup sources are marked in first iteration.
The patch fixes this corner case.
Updated after Paul Walmsley's only handle selected PRCM interrupts patch.
Can you have a look at the recent work by Thomas Petazzoni:
[PATCH] omap: prcm: switch to a chained IRQ handler mechanism
where the PRCM IRQ handler is broken up to see if this problem still
exists? I suspect the problem is gone as each type of interrupt is
separated out, but should be verified.
Kevin
Signed-off-by: Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..2ed3662 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -266,6 +266,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
{
u32 irqenable_mpu, irqstatus_mpu;
int c = 0;
+ int ct = 0;
irqenable_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
@@ -277,13 +278,15 @@ static irqreturn_t prcm_interrupt_handler (int irq,
void *dev_id)
if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
c = _prcm_int_handle_wakeup();
+ ct++;
/*
* Is the MPU PRCM interrupt handler racing with the
* IVA2 PRCM interrupt handler ?
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
- but no wakeup sources are marked\n);
+ WARN(!c (ct == 1), prcm: WARNING: PRCM indicated
+ MPU wakeup but no wakeup sources
+ are marked\n);
} else {
/* XXX we need to expand our PRCM interrupt handler */
WARN(1, prcm: WARNING: PRCM interrupt received, but
--
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 07/11] arm: omap4: add USBHOST and related base addresses
On Mon, Nov 22, 2010 at 12:10:10AM +0530, Anand Gadiyar wrote: Add base addresses for USBHOST, USBTLL, EHCI and OHCI to the header file. This will disappear when the drivers are converted to use the hwmod database, however this patch is needed until then. Signed-off-by: Anand Gadiyar gadi...@ti.com Tony, I need an Ack here again :-p -- 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: newbie: can I ask a question about linux-omap-pm on this mailing list?
Hi. I want to ask a newbie questions regarding linux-omap-pm repositories(http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary). I know this mailing list is for the linux-omap repository. I have searched the web for a mailing list specific for linux-omap-pm without success. Is this the right mailing list to pose my question? If not, can you point me to a better one? You have come to the right place. The linux-omap-pm tree is maintained by Kevin Hilman, and he checks this mailing list regularly. Ask away... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] musb_gadget: fix compilation warning
On Mon, Nov 22, 2010 at 02:22:41PM +0530, Ajay Kumar Gupta wrote: Fixes below compilation warning when musb driver is compiled for PIO mode. drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx': drivers/usb/musb/musb_gadget.c:840: warning: label 'exit' defined but not used Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Applied, thanks -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: disable idle early in the suspend sequence
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the call to disable_hlt at the very beginning
of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare),
and the call to enable_hlt at the very end of the suspend sequence
(in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..022fdff 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -508,7 +508,6 @@ static suspend_state_t suspend_state;
static int omap3_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -576,12 +575,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,6 +590,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: disable idle early in the suspend sequence
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Monday, November 22, 2010 4:15 PM
To: linux-omap@vger.kernel.org
Cc: Jean Pihet; Kevin Hilman
Subject: [PATCH] OMAP3: disable idle early in the suspend sequence
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
Can you elaborate more on what kind of issues were seen?
The solution is to move the call to disable_hlt at the very beginning
of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare),
and the call to enable_hlt at the very end of the suspend sequence
(in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..022fdff 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -508,7 +508,6 @@ static suspend_state_t suspend_state;
static int omap3_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -576,12 +575,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,6 +590,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c
Hi Paul,
snip
...
+
+int omap2_wd_timer_disable(struct omap_hwmod *oh)
+{
+ void __iomem *base;
+ int ret;
+
+ if (!oh) {
+ pr_err(%s: Could not look up wdtimer_hwmod\n, __func__);
+ return -EINVAL;
+ }
+
Just a minor observation. I was wondering if we need this check because
omap_hwmod_for_each_by_class(...) would call this only for valid oh.
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
if (!strcmp(temp_oh-class-name, classname)) {
pr_debug(omap_hwmod: %s: %s: calling callback fn\n,
__func__, temp_oh-name);
ret = (*fn)(temp_oh, user);
--
Tarun
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: disable idle early in the suspend sequence
Hi, On Mon, Nov 22, 2010 at 11:44:57AM +0100, Jean Pihet wrote: Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. The solution is to move the call to disable_hlt at the very beginning of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare), and the call to enable_hlt at the very end of the suspend sequence (in omap3_pm_end instead of omap3_pm_finish). Tested with RET and OFF on Beagle and OMAP3EVM. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com This patch will look weird on git log, it's going to be From: Jean Pihet jean.pi...@newoldbits.com and Signed-off-by: Jean Pihet j-pi...@ti.com. Maybe you should change user.email variable on your .gitconfig and use envelope sender as your newoldbits.com address ? -- 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] OMAP3: disable idle early in the suspend sequence
On Mon, Nov 22, 2010 at 11:53 AM, Rajendra Nayak rna...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Monday, November 22, 2010 4:15 PM To: linux-omap@vger.kernel.org Cc: Jean Pihet; Kevin Hilman Subject: [PATCH] OMAP3: disable idle early in the suspend sequence Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. Can you elaborate more on what kind of issues were seen? Trying to get the PRCM registers dump after a suspend/resume does not show the correct registers values, cf. Kevin's patch at http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=9fc4891d4a21d2b644a463d62c77ef97da55f091. Digging a bit further I found out that the idle routine is called 50 times while the suspend/resume sequence still is on-going. The root cause is because disable_hlt is called from omap3_pm_prepare which runs after omap3_pm_begin (and the same issue in the resume sequence). This leaves a time window for idle to kick-in while the suspend sequence is busy saving/restoring the system state. This is a potential bug that just waits to show up soon or later, especially if more code is added in the suspend prepare and finish functions. Does the changelog need an update? Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: disable idle early in the suspend sequence
Hi, On Mon, Nov 22, 2010 at 12:11 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 22, 2010 at 11:44:57AM +0100, Jean Pihet wrote: Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. The solution is to move the call to disable_hlt at the very beginning of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare), and the call to enable_hlt at the very end of the suspend sequence (in omap3_pm_end instead of omap3_pm_finish). Tested with RET and OFF on Beagle and OMAP3EVM. Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com This patch will look weird on git log, it's going to be From: Jean Pihet jean.pi...@newoldbits.com and Signed-off-by: Jean Pihet j-pi...@ti.com. Maybe you should change user.email variable on your .gitconfig and use envelope sender as your newoldbits.com address ? That is exactly what I am trying to achieve but it does not work ;-( git config -l shows: user.name=Jean Pihet user.email=j-pi...@ti.com sendemail.smtpuser=jean.pi...@newoldbits.com The original patch has the ti.com address in both the From: and Signed-off-by: fields, but the From: on the ML still shows otherwise. Weird... Any idea how to fix that? Thanks! Jean -- 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] OMAP3: disable idle early in the suspend sequence
Hi, On Mon, Nov 22, 2010 at 12:38:21PM +0100, Jean Pihet wrote: The original patch has the ti.com address in both the From: and Signed-off-by: fields, but the From: on the ML still shows otherwise. Weird... Any idea how to fix that? how about setting sendemail.envelopesender ?? -- 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On Mon, Nov 22, 2010 at 4:08 AM, Felipe Balbi ba...@ti.com wrote: On Fri, Nov 19, 2010 at 03:50:02PM +0100, Cousson, Benoit wrote: Most of the time, we do not want to use the IP revision because it is un-accurate and does not reflect the change we'd like to track. For example some time a minor change in the RTL that will not impact the SW at all might trigger a change in the IP revision, whereas on the other hand a major bug fix that will impact the SW is not capture in the IP revision... yeah, that's bad, but this can happen. That's why we are relying on a rev field in the hwmod. But then, what's inside this rev field ? Is it some internal revision of hwmod or do you read from the hw ? From the dmtimer stuff, it looks like the driver defines the version types, which hwmod uses to define the rev field. /* timer ip constants */ #define OMAP_TIMER_IP_LEGACY0x1 #define OMAP_TIMER_IP_VERSION_2 0x2 Thank you, Best regards, Hari Kanigeri -- 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
Felipe, On Mon, Nov 22, 2010 at 5:51 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 22, 2010 at 05:46:53AM -0600, Kanigeri, Hari wrote: From the dmtimer stuff, it looks like the driver defines the version types, which hwmod uses to define the rev field. /* timer ip constants */ #define OMAP_TIMER_IP_LEGACY 0x1 #define OMAP_TIMER_IP_VERSION_2 0x2 in that case, it's the same as if you pass in a flag via platform_data. You might as well call it rev, then the diff when converting to hwmod will be smaller maybe :-p I agree with you, the changes should be minimal converting to hwmod. Thank you, Best regards, Hari Kanigeri -- 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: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device driver
On Mon, Nov 22, 2010 at 14:44, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 12:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device
driver
snip
-/*
- * Reads timer registers in posted and non-posted mode. The posted mode
bit
- * is encoded in reg. Note that in posted mode write pending bit must
be
- * checked. Otherwise a read of a non completed write will produce an
error.
+/**
+ * omap_dm_timer_read_reg - read timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which read operation to perform
+ * @reg: lowest byte holds the register offset
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
write
+ * pending bit must be checked. Otherwise a read of a non completed
write
+ * will produce an error.
*/
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer,
u32 reg)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-func_offst)
+ 0xff)) (reg WPSHIFT))
You may add a timeout in this.
There are few reasons why I have not done:
(1) This was in this way from the beginning and I thought some analysis
Was done already for not adding timeout and so did not wish to alter that.
(2) wanted to keep low level functions as simple as possible by avoiding
As many checks as possible unless really needed.
(3) The client driver can take care of timeout. Even if timeout is
Introduced in this api, the client driver anyways have to check for the
Timeout.
I don't think that client driver should take care of this. The client
driver should
check only for the return value. If timeout, return error.
In your case, one of the calls to omap_dm_timer_write_reg() is as given below:
omap2_gp_timer_init()
- omap2_gp_clockevent_init()
- omap_dm_timer_request_specific()
- omap_dm_timer_prepare()
- omap_dm_timer_write_reg()
Here timeout is not taken care.
--
Tarun
cpu_relax();
return readl(timer-io_base + (reg 0xff));
}
-/*
- * Writes timer registers in posted and non-posted mode. The posted
mode bit
- * is encoded in reg. Note that in posted mode the write pending bit
must be
- * checked. Otherwise a write on a register which has a pending write
will be
- * lost.
+/**
+ * omap_dm_timer_write_reg - write timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which write operation is to perform
+ * @reg: lowest byte holds the register offset
+ * @value: data to write into the register
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode the
write
+ * pending bit must be checked. Otherwise a write on a register which
has a
+ * pending write will be lost.
*/
static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32
reg,
u32 value)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base + (OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-func_offst)
+ 0xff)) (reg WPSHIFT))
Ditto.
cpu_relax();
writel(value, timer-io_base + (reg 0xff));
}
snip
--
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] omap4: 4430sdp: enable the ehci port on 4430SDP
On Mon, Nov 22, 2010 at 05:24:08PM +0530, Anand Gadiyar wrote: On 11/22/2010 3:47 PM, Felipe Balbi wrote: On Mon, Nov 22, 2010 at 12:13:19AM +0530, Anand Gadiyar wrote: From: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Tony Lindgren t...@atomide.com Tony, if you give me your Ack I can take this with Greg since it depends on the series I'm checking now. This one can go through Tony - I deliberately left it out of the EHCI series. The dependency is needed for the EHCI port to actually be usable, however we can register the device in the board file independently of the driver. I forgot to update the patch description - I'll wait some more for any more comments and then repost with a proper description. Ok, so it's Tony's call now. Tony, if you want to take this together with OMAP changes, just let me know and I'll drop this patch from my branch, if you want me to take it through Greg, then give me an Acked-by :-) -- 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: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device driver
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device
driver
On Mon, Nov 22, 2010 at 14:44, DebBarma, Tarun Kanti tarun.ka...@ti.com
wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 12:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform
device
driver
snip
-/*
- * Reads timer registers in posted and non-posted mode. The posted
mode
bit
- * is encoded in reg. Note that in posted mode write pending bit
must
be
- * checked. Otherwise a read of a non completed write will produce
an
error.
+/**
+ * omap_dm_timer_read_reg - read timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which read operation to perform
+ * @reg: lowest byte holds the register offset
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
write
+ * pending bit must be checked. Otherwise a read of a non completed
write
+ * will produce an error.
*/
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer
*timer,
u32 reg)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base +
(OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-
func_offst)
+ 0xff)) (reg WPSHIFT))
You may add a timeout in this.
There are few reasons why I have not done:
(1) This was in this way from the beginning and I thought some analysis
Was done already for not adding timeout and so did not wish to alter
that.
(2) wanted to keep low level functions as simple as possible by avoiding
As many checks as possible unless really needed.
(3) The client driver can take care of timeout. Even if timeout is
Introduced in this api, the client driver anyways have to check for the
Timeout.
I don't think that client driver should take care of this. The client
driver should
check only for the return value. If timeout, return error.
So what I am saying is it can add the timeout instead of checking for the
Return value. This would keep the low level function simple.
Please try to understand that this is a common function called by all the
Client drivers associated with all the timers. If you can reduce a check
The benefit is tremendous.
--
Tarun
In your case, one of the calls to omap_dm_timer_write_reg() is as given
below:
omap2_gp_timer_init()
- omap2_gp_clockevent_init()
- omap_dm_timer_request_specific()
- omap_dm_timer_prepare()
- omap_dm_timer_write_reg()
Here timeout is not taken care.
--
Tarun
cpu_relax();
return readl(timer-io_base + (reg 0xff));
}
-/*
- * Writes timer registers in posted and non-posted mode. The posted
mode bit
- * is encoded in reg. Note that in posted mode the write pending bit
must be
- * checked. Otherwise a write on a register which has a pending
write
will be
- * lost.
+/**
+ * omap_dm_timer_write_reg - write timer registers in posted and
non-
posted mode
+ * @timer: timer pointer over which write operation is to
perform
+ * @reg: lowest byte holds the register offset
+ * @value: data to write into the register
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
the
write
+ * pending bit must be checked. Otherwise a write on a register
which
has a
+ * pending write will be lost.
*/
static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32
reg,
u32 value)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base +
(OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-
func_offst)
+ 0xff)) (reg WPSHIFT))
Ditto.
cpu_relax();
writel(value, timer-io_base + (reg 0xff));
}
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: [PATCH] OMAP3: disable idle early in the suspend sequence
-Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Monday, November 22, 2010 5:01 PM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org; Jean Pihet-XID; Kevin Hilman Subject: Re: [PATCH] OMAP3: disable idle early in the suspend sequence On Mon, Nov 22, 2010 at 11:53 AM, Rajendra Nayak rna...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Monday, November 22, 2010 4:15 PM To: linux-omap@vger.kernel.org Cc: Jean Pihet; Kevin Hilman Subject: [PATCH] OMAP3: disable idle early in the suspend sequence Some bad interaction between the idle and the suspend paths has been noticed: the idle code is called during the suspend enter and exit sequences. This could cause corruption or lock-up of resources. Can you elaborate more on what kind of issues were seen? Trying to get the PRCM registers dump after a suspend/resume does not show the correct registers values, cf. Kevin's patch at http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commitdiff;h=9fc4891d4a21d2b644a463d62c77ef97da55f091. Digging a bit further I found out that the idle routine is called 50 times while the suspend/resume sequence still is on-going. The root cause is because disable_hlt is called from omap3_pm_prepare which runs after omap3_pm_begin (and the same issue in the resume sequence). This leaves a time window for idle to kick-in while the suspend sequence is busy saving/restoring the system state. This is a potential bug that just waits to show up soon or later, especially if more code is added in the suspend prepare and finish functions. Ok. Thanks. Basically we had some similar issues on OMAP4. I am yet to root cause, but the initial hunch was there was a race between idle and suspend and I did pretty much the same change in pm44xx.c. That fixed the issue but only partially, so am still in the process of debugging it further to see what exactly is the issue. So was just curious to know what issues you ran into on OMAP3. Will update once I know whats happening on OMAP4. Does the changelog need an update? No, The changelog looks fine to me. Thanks, Rajendra Regards, Jean -- 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: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device driver
On Mon, Nov 22, 2010 at 17:38, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device
driver
On Mon, Nov 22, 2010 at 14:44, DebBarma, Tarun Kanti tarun.ka...@ti.com
wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 12:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform
device
driver
snip
-/*
- * Reads timer registers in posted and non-posted mode. The posted
mode
bit
- * is encoded in reg. Note that in posted mode write pending bit
must
be
- * checked. Otherwise a read of a non completed write will produce
an
error.
+/**
+ * omap_dm_timer_read_reg - read timer registers in posted and non-
posted mode
+ * @timer: timer pointer over which read operation to perform
+ * @reg: lowest byte holds the register offset
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
write
+ * pending bit must be checked. Otherwise a read of a non completed
write
+ * will produce an error.
*/
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer
*timer,
u32 reg)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base +
(OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-
func_offst)
+ 0xff)) (reg WPSHIFT))
You may add a timeout in this.
There are few reasons why I have not done:
(1) This was in this way from the beginning and I thought some analysis
Was done already for not adding timeout and so did not wish to alter
that.
(2) wanted to keep low level functions as simple as possible by avoiding
As many checks as possible unless really needed.
(3) The client driver can take care of timeout. Even if timeout is
Introduced in this api, the client driver anyways have to check for the
Timeout.
I don't think that client driver should take care of this. The client
driver should
check only for the return value. If timeout, return error.
So what I am saying is it can add the timeout instead of checking for the
Return value. This would keep the low level function simple.
Please try to understand that this is a common function called by all the
Client drivers associated with all the timers. If you can reduce a check
The benefit is tremendous.
I do not agree. If low level driver functions are using these common read/write
functions, there is a possibility of getting struck up in the while loop since
there is no timeout. If you think that there is no possibility of timeout when
called from low level driver functions, remove the while loop unless if it is
really required.
If these functions uses while loops, please have a timeout error. Otherwise,
analyze and remove the while loop from these functions.
--
Tarun
In your case, one of the calls to omap_dm_timer_write_reg() is as given
below:
omap2_gp_timer_init()
- omap2_gp_clockevent_init()
- omap_dm_timer_request_specific()
- omap_dm_timer_prepare()
- omap_dm_timer_write_reg()
Here timeout is not taken care.
--
Tarun
cpu_relax();
return readl(timer-io_base + (reg 0xff));
}
-/*
- * Writes timer registers in posted and non-posted mode. The posted
mode bit
- * is encoded in reg. Note that in posted mode the write pending bit
must be
- * checked. Otherwise a write on a register which has a pending
write
will be
- * lost.
+/**
+ * omap_dm_timer_write_reg - write timer registers in posted and
non-
posted mode
+ * @timer: timer pointer over which write operation is to
perform
+ * @reg: lowest byte holds the register offset
+ * @value: data to write into the register
+ *
+ * The posted mode bit is encoded in reg. Note that in posted mode
the
write
+ * pending bit must be checked. Otherwise a write on a register
which
has a
+ * pending write will be lost.
*/
static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32
reg,
u32 value)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
-
RE: DSS2 and 2.6.36
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Grant Erickson Sent: Friday, November 12, 2010 11:35 PM To: linux-omap@vger.kernel.org Subject: DSS2 and 2.6.36 I have a Mistral AM37x development board and am working on transitioning it from the 2.6.32 provided with the SDK to 2.6.36 and have run into some issues with the OMAP2 DSS driver that it seems others have encountered as well (e.g. DSS2 broken with 36-rc1 [Hiremath, Vaibhav] Are you using 2.6.36 stable version or 2.6.36-rcX? I would suggest you to use latest kernel, I started using 2.6.36 stable version and it is working fine for me. Thanks, Vaibhav http://marc.info/?t=12819629504r=1w=2 and [PATCH 1/2] video: omap: vram: remove from normal memory http://marc.info/?t=12871470534r=1w=2). Is 2.6.37-rcY the preferred canonical tree to fast-forward to pick up the remap/allocation/reserve changes for this or is there another preferred tree (e.g. git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux- omap-2.6.git or git://gitorious.org/linux-omap-dss2/linux.git)? Best, Grant -- 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: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device driver
Charu and Benoit,
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 6:05 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform device
driver
On Mon, Nov 22, 2010 at 17:38, DebBarma, Tarun Kanti tarun.ka...@ti.com
wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform
device
driver
On Mon, Nov 22, 2010 at 14:44, DebBarma, Tarun Kanti
tarun.ka...@ti.com
wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Monday, November 22, 2010 12:15 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv4 12/14] OMAP: dmtimer: switch-over to platform
device
driver
snip
-/*
- * Reads timer registers in posted and non-posted mode. The
posted
mode
bit
- * is encoded in reg. Note that in posted mode write pending bit
must
be
- * checked. Otherwise a read of a non completed write will
produce
an
error.
+/**
+ * omap_dm_timer_read_reg - read timer registers in posted and
non-
posted mode
+ * @timer: timer pointer over which read operation to
perform
+ * @reg: lowest byte holds the register offset
+ *
+ * The posted mode bit is encoded in reg. Note that in posted
mode
write
+ * pending bit must be checked. Otherwise a read of a non
completed
write
+ * will produce an error.
*/
static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer
*timer,
u32 reg)
{
+ struct dmtimer_platform_data *pdata = timer-pdev-
dev.platform_data;
+
+ if (reg = OMAP_TIMER_WAKEUP_EN_REG)
+ reg += pdata-func_offst;
+
if (timer-posted)
- while (readl(timer-io_base +
(OMAP_TIMER_WRITE_PEND_REG
0xff))
- (reg WPSHIFT))
+ while (readl(timer-io_base +
+ ((OMAP_TIMER_WRITE_PEND_REG + pdata-
func_offst)
+ 0xff)) (reg WPSHIFT))
You may add a timeout in this.
There are few reasons why I have not done:
(1) This was in this way from the beginning and I thought some
analysis
Was done already for not adding timeout and so did not wish to alter
that.
(2) wanted to keep low level functions as simple as possible by
avoiding
As many checks as possible unless really needed.
(3) The client driver can take care of timeout. Even if timeout is
Introduced in this api, the client driver anyways have to check for
the
Timeout.
I don't think that client driver should take care of this. The client
driver should
check only for the return value. If timeout, return error.
So what I am saying is it can add the timeout instead of checking for
the
Return value. This would keep the low level function simple.
Please try to understand that this is a common function called by all
the
Client drivers associated with all the timers. If you can reduce a check
The benefit is tremendous.
I do not agree. If low level driver functions are using these common
read/write
functions, there is a possibility of getting struck up in the while loop
since
there is no timeout. If you think that there is no possibility of timeout
when
called from low level driver functions, remove the while loop unless if it
is
really required.
If these functions uses while loops, please have a timeout error.
Otherwise,
analyze and remove the while loop from these functions.
As long as we use *posted* mode we need the while loop check.
So the timeout can be added inside the while loop.
Benoit,
Under this circumstance I am feeling no more value for having
Separate set of low level functions for accessing the interrupt
Registers, viz. omap_dm_timer_read_intr_reg() and
omap_dm_timer_write_intr_reg() which were added to keep the
low level functions simple.
So can I go ahead and merge them within omap_dm_timer_read_reg()
And omap_dm_timer_write_reg()?
--
Tarun
In your case, one of the calls to omap_dm_timer_write_reg() is as given
below:
omap2_gp_timer_init()
- omap2_gp_clockevent_init()
- omap_dm_timer_request_specific()
- omap_dm_timer_prepare()
- omap_dm_timer_write_reg()
Here timeout is not taken care.
--
Tarun
cpu_relax();
return readl(timer-io_base + (reg 0xff));
}
-/*
- * Writes timer registers in posted and non-posted mode. The
posted
mode bit
- * is encoded in reg. Note that in posted mode the write pending
bit
must be
- * checked. Otherwise a write on a register which has a pending
write
will
Re: DSS2 and 2.6.36
On Fri, Nov 12, 2010 at 8:04 PM, Grant Erickson maratho...@gmail.com wrote: I have a Mistral AM37x development board and am working on transitioning it from the 2.6.32 provided with the SDK to 2.6.36 and have run into some issues with the OMAP2 DSS driver that it seems others have encountered as well (e.g. DSS2 broken with 36-rc1 http://marc.info/?t=12819629504r=1w=2 and [PATCH 1/2] video: omap: vram: remove from normal memory http://marc.info/?t=12871470534r=1w=2). Is 2.6.37-rcY the preferred canonical tree to fast-forward to pick up the remap/allocation/reserve changes for this or is there another preferred tree (e.g. git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git or git://gitorious.org/linux-omap-dss2/linux.git)? 2.6.36 should work fine, but you need to configure the amount of VRAM to reserve: CONFIG_OMAP2_VRAM_SIZE=6, or something like that. Previous methods (board, omap.vram boot param) don't work any more AFAIK. -- 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
DSP Bridge video decode of above VGA videos
Hi All, We are running Android on a custom Gumstix Overo Water platform. We have ported the 25.12 Zoom2 release to do this. It is almost working except that when trying to decode H264 videos with resolution above 640x480 (either horizontally or vertically, e.g. 640*544) the DSP module appears to crash. Decoding anything at VGA or below is working fine. DSP bridge is configured with 0x60 memory (but larger doesn't seem to help). Is anyone aware of other configuration options that we should be checking (e.g. in DSP bridge, OMAP video drivers, or android?) that might cause large video decodes to fail? Thanks in advance, James -- 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: DSP Bridge video decode of above VGA videos
James, On Mon, Nov 22, 2010 at 7:14 AM, James Adams james.r.ad...@gmail.com wrote: Hi All, We are running Android on a custom Gumstix Overo Water platform. We have ported the 25.12 Zoom2 release to do this. It is almost working except that when trying to decode H264 videos with resolution above 640x480 (either horizontally or vertically, e.g. 640*544) the DSP module appears to crash. Decoding anything at VGA or below is working fine. DSP bridge is configured with 0x60 memory (but larger doesn't seem to help). Is anyone aware of other configuration options that we should be checking (e.g. in DSP bridge, OMAP video drivers, or android?) that might cause large video decodes to fail? Can you please post any error/failure logs ? Thank you, Best regards, Hari Kanigeri -- 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: newbie: can I ask a question about linux-omap-pm on this mailing list?
Thank you for your reply. I am a newbie when it comes down to Linux git repositories. I am trying to do a 2.6.32 paravirtualization on top of L4, to run on the beagleboard(omap3 CPU), using as native kernel one from the linux-omap-pm repository. Why 2.6.32? It seems we have to run some userland modules that were written to be compatible with that version of Linux. One part of the problem is to select the best suitable native commit for this purpose. I am now trying to identify the best native commit from linux-omap-pm that fits the bill: working 2.6.32 + pm features for omap3 processors. My initial attempt was to use pm-2.6.32 branch (git checkout --track -b pm-2.6.32 origin/pm-2.6.32). I realized there are issues with some devices: the USB host (EHCI) detecting hubs. I have some problems navigating the linux-omap-pm git repository and I would really appreciate some feedback on these questions: 1. Was the pm-2.6.32 branch designed to add pm features to the TI 2.6.32-omap and Torvalds 2.6.32? 1.1. if true, the pm-2.6.32 was focused on omap1 (not omap3) features? 1.2. if not true, is there a better branch/commit/tag that deals with pm features on the omap3 SOC? 1.3. As far as you know has any testing been performed on omap3 with a version of Linux close to 2.6.32? Thank you for your input, Gabi Voiculescu --- On Mon, 11/22/10, S, Venkatraman svenk...@ti.com wrote: From: S, Venkatraman svenk...@ti.com Subject: Re: newbie: can I ask a question about linux-omap-pm on this mailing list? To: Gabi Voiculescu boy3d...@yahoo.com Cc: linux-omap linux-omap@vger.kernel.org Date: Monday, November 22, 2010, 12:36 PM Hi. I want to ask a newbie questions regarding linux-omap-pm repositories(http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary). I know this mailing list is for the linux-omap repository. I have searched the web for a mailing list specific for linux-omap-pm without success. Is this the right mailing list to pose my question? If not, can you point me to a better one? You have come to the right place. The linux-omap-pm tree is maintained by Kevin Hilman, and he checks this mailing list regularly. Ask away... -- 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/22/2010 11:08 AM, Balbi, Felipe wrote: On Fri, Nov 19, 2010 at 03:50:02PM +0100, Cousson, Benoit wrote: Most of the time, we do not want to use the IP revision because it is un-accurate and does not reflect the change we'd like to track. For example some time a minor change in the RTL that will not impact the SW at all might trigger a change in the IP revision, whereas on the other hand a major bug fix that will impact the SW is not capture in the IP revision... yeah, that's bad, but this can happen. That's why we are relying on a rev field in the hwmod. But then, what's inside this rev field ? Is it some internal revision of hwmod or do you read from the hw ? So far we are using a artificial SW IP revision that reflect the difference we'd like to highlight v1, v2. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/22/2010 12:51 PM, Felipe Balbi wrote: Hi, On Mon, Nov 22, 2010 at 05:46:53AM -0600, Kanigeri, Hari wrote: From the dmtimer stuff, it looks like the driver defines the version types, which hwmod uses to define the rev field. /* timer ip constants */ #define OMAP_TIMER_IP_LEGACY0x1 #define OMAP_TIMER_IP_VERSION_2 0x2 in that case, it's the same as if you pass in a flag via platform_data. You might as well call it rev, then the diff when converting to hwmod will be smaller maybe :-p Yes, this is exactly what I was proposing to Hari. For the moment create the pdata field that will be populated at init time using the cpu_is. During the hwmod migration, the value will be extracted from the hwmod rev field. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSP Bridge video decode of above VGA videos
Hi Hari,
Please see output below - hopefully there are some clues in there? many thanks,
James
I/ActivityManager( 966): Starting activity: Intent {
act=android.intent.action.
MAIN cat=[android.intent.category.LAUNCHER] flg=0x1020
cmp=com.android.devel
opment/.Development }
I/ActivityManager( 966): Start proc com.android.development for
activity com.an
droid.development/.Development: pid=1249 uid=10016 gids={3003}
binder_open: 1249:1249
binder_mmap: 1249 44682000-4478 (1016 K) vma 200075 pagep 30f
D/dalvikvm( 933): GC freed 281 objects / 10696 bytes in 225ms
D/dalvikvm( 933): GC freed 50 objects / 2232 bytes in 64ms
D/dalvikvm( 933): GC freed 2 objects / 48 bytes in 57ms
I/ActivityManager( 966): Displayed activity
com.android.development/.Developmen
t: 898 ms (total 898 ms)
I/ActivityManager( 966): Starting activity: Intent {
act=android.intent.action.
MAIN cat=[android.intent.category.TEST] flg=0x1000
cmp=com.android.developme
nt/.MediaScannerActivity }
D/MediaScannerService( 1073): start scanning volume external
I/ActivityManager( 966): Displayed activity
com.android.development/.MediaScann
erActivity: 294 ms (total 294 ms)
D/dalvikvm( 1073): GC freed 6291 objects / 312432 bytes in 66ms
V/MediaProvider( 1073): we got work to do for checkThumbnail:
/sdcard/videos/wal
l_e_720p.m4v, there are still 0 tasks left in queue
D/omx_interface( 934): TIOMXInterface: creating interface
D/omx_interface( 934): Calling DLOPEN on OMX_CORE_LIBRARY
(libOMX_Core.so)
D/omx_interface( 934): DLOPEN SUCCEEDED (libOMX_Core.so)
D/omx_interface( 934): TIOMXInterface: library lookup success
D/TIOMX_CORE( 934): init count = 1
D/MediaScanner( 1073): prescan time: 189ms
D/MediaScanner( 1073): scan time: 1019ms
D/MediaScanner( 1073): postscan time: 2ms
D/MediaScanner( 1073):total time: 1210ms
D/MediaScannerService( 1073): done scanning volume external
E/MetadataDriver( 934): handleQueryTrackSelectionHelper()
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
I/TI_Parser_Utils( 934): iGetAVCConfigInfo:: 909:
entropy_coding_mode_flag = 0
D/TIOMX_CORE( 934): Found component OMX.TI.Video.Decoder with refCount
0
D/TI_Video_Decoder( 934): OMX_ComponentInit():296 TI Video Decoder
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6570 Before
Rounding: nFrame
Width = 1280, nFrameHeight = 544
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding:
nFrameW
idth = 1280, nFrameHeight = 544
drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed.
D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619
LCML_InitMMCodec Failed
!...80001009
D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1
D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select
I/DEBUG ( 930): *** *** *** *** *** *** *** *** *** *** *** *** ***
*** *** *
**
I/DEBUG ( 930): Build fingerprint:
'generic/zoom2/zoom2/zoom2:2.1/ERD79/eng.a
.20101027.181041:eng/test-keys'
I/DEBUG ( 930): pid: 934, tid: 1258 /system/bin/mediaserver
I/DEBUG ( 930): signal 11 (SIGSEGV), fault addr deadbaad
I/DEBUG ( 930): r0 r1 afe13329 r2 0027 r3 0054
I/DEBUG ( 930): r4 afe3ae08 r5 r6 r7 a000
I/DEBUG ( 930): r8 0010 r9 a9d1c1d5 10 40c08000 fp c8a0
I/DEBUG ( 930): ip 2ed8 sp 40d07b28 lr deadbaad pc afe109e0
cpsr 600
00030
I/DEBUG ( 930): #00 pc 000109e0 /system/lib/libc.so
I/DEBUG ( 930): #01 pc b332 /system/lib/libc.so
I/DEBUG ( 930): #02 pc 00032936
/system/lib/libOMX.TI.Video.Decode
r.so
I/DEBUG ( 930): #03 pc 111e /system/lib/libOMX_Core.so
I/DEBUG ( 930): #04 pc 00039f90
/system/lib/libopencore_common.so
I/DEBUG ( 930): #05 pc 000aad68
/system/lib/libopencore_common.so
I/DEBUG ( 930): #06 pc 000ad364
/system/lib/libopencore_common.so
I/DEBUG ( 930): #07 pc 000a0144
/system/lib/libopencore_common.so
I/DEBUG ( 930): #08 pc 0009e348
/system/lib/libopencore_common.so
I/DEBUG ( 930): #09 pc 0009f5ea
/system/lib/libopencore_player.so
I/DEBUG ( 930): #10 pc 000939fa
/system/lib/libopencore_player.so
I/DEBUG ( 930): #11 pc 00093a2a
/system/lib/libopencore_player.so
I/DEBUG ( 930): #12 pc 00096c42
/system/lib/libopencore_player.so
I/DEBUG ( 930): #13 pc 00089446
/system/lib/libopencore_player.so
I/DEBUG ( 930): #14 pc 0002b0cc
/system/lib/libopencore_common.so
I/DEBUG ( 930): #15 pc 0002b334
/system/lib/libopencore_common.so
I/DEBUG ( 930): #16 pc 0002b6ec
/system/lib/libopencore_common.so
I/DEBUG ( 930): #17 pc 000a3118
/system/lib/libopencore_player.so
I/DEBUG ( 930): #18 pc 000a313a
Re: [PATCH ver. 2] PM: add synchronous runtime interface for interrupt handlers
On Mon, 22 Nov 2010, Rafael J. Wysocki wrote: I didn't like this change before and I still don't like it. Quite frankly, I'm not sure I can convince Linus to pull it. :-) Why don't we simply execute the callback under the spinlock in the IRQ safe case? Because it wouldn't work. The job of the runtime_idle callback is to call pm_runtime_suspend when needed. But if the callback runs under the spinlock then pm_runtime_suspend would hang when it tries to grab the lock. Yes, in the _idle case. I actually should have put my comment under the change in rpm_callback(), which is what I really meant. But the new rpm_callback() _does_ simply execute the callback under the spinlock in the irq-safe case. So I don't understand what you mean here. Moreover, I'm not sure if we need an IRQ safe version of _idle. Why do we need it, exactly? Because pm_runtime_put_sync() calls rpm_idle(). If there were no irq-safe version of rpm_idle() then drivers wouldn't be able to call pm_runtime_put_sync() from within an interrupt handler. The problem I have with this change is that switching interrupts off really is a part of the locking operation, so using spin_unlock() after spin_lock_irq...() is kind of like releasing the lock partially, which I don't think is valid (even if we're going to reacquire the lock immediately). On the contrary; spin_unlock() after spin_lock_irq() doesn't partially release the lock -- it releases the lock _entirely_! :-) Besides which, the existing code already releases the spinlock before making callbacks, so there should be no reason to worry about that issue. The new code either: releases the spinlock but keeps interrupts disabled (in rpm_idle), or doesn't release the spinlock (in rpm_callback). Either way, I should think you'd find the new code _less_ objectionable than the existing code, not _more_ objectionable. Alan Stern -- 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 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
Resending the mail in plain text format..
On Mon, Nov 22, 2010 at 9:20 PM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
On Mon, Oct 11, 2010 at 11:48 AM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG
register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing the
similar thing for the smartstandby issue on SDMA.
OK.
Looks like we have a problem when we write an API similar to the one
written
by Manju (omap_hwmod_set_master_standbymode()) [1]. In the case of
McBSP,
I have to modify omap_hwmod_set_slave_idlemode() (which is already
existing),
to include something like
+ if (sf SYSC_HAS_SIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags
HWMOD_SWSUP_SIDLE) ?
+ HWMOD_IDLEMODE_NO :
HWMOD_IDLEMODE_SMART;
+ }
Then an API like omap_device_require_no_idle() and
omap_device_release_no_idle()
would be written similar to omap_device_require_no_mstandby and
omap_device_release_no_mstandby() (see [1]) that calls
omap_hwmod_set_slave_idlemode() with true/false. Passing true to
omap_hwmod_set_slave_idlemode() will write SIDLE bits with
HWMOD_IDLEMODE_NO and false to it will write
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART depending on
HWMOD_SWSUP_SIDLE to SIDLE bits.
This works fine for McBSP since only two modes come to play here
(HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART).
But omap_hwmod_set_slave_idlemode() API is used by UART
(serial.c Please refer [2]) which writes SIDLE bits to
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART/ and
HWMOD_IDLEMODE_FORCE.
Modifying omap_hwmod_set_slave_idlemode() will require
1) serial.c to be modified to call functions like
'omap_device_require_no_idle(),
omap_device_release_no_idle()' and
'omap_device_require_force_idle() and
omap_device_release_force_idle()' instead of
omap_hwmod_set_slave_idlemode() which is currently present.
There are 2 problems associated with it
1) The first problem is having a single API like
omap_hwmod_set_slave_idlemode() to
set two different values like HWMOD_IDLEMODE_NO or
HWMOD_IDLEMODE_FORCE (intended to be called by
omap_device_require_no_idle()
and omap_device_require_force_idle() respectively). According to
the new design
omap_hwmod_set_slave_idlemode() is intended to take only true/false
as
arguments.
2) The second problem is having the release API's
(omap_device_release_no_idle() and
omap_device_release_force_idle()) to restore the SYSCONFIG to the
previous state.
Remember, this was not problem for McBSP since only two modes were
needed.
Please provide your comment on this.
-Kishon
[1] https://patchwork.kernel.org/patch/335591/
[2]
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/serial.c;h=edd7c99de38dde5bf877788fb4e48055c0d9fbfa;hb=HEAD
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Cc: Partha Basakp-bas...@ti.com
---
arch/arm/plat-omap/mcbsp.c | 69
++--
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index c7c6a83..6b705e1 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -228,10 +228,21 @@ void omap_mcbsp_config(unsigned int id, const
struct omap_mcbsp_reg_cfg *config)
EXPORT_SYMBOL(omap_mcbsp_config);
#ifdef CONFIG_ARCH_OMAP3
+static struct omap_hwmod **find_hwmods_by_dev(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ pdev = container_of(dev, struct platform_device, dev);
+ od = container_of(pdev, struct omap_device, pdev);
+ return od-hwmods;
Rule #1, don't touch oh in your code. The device should be the only
interface.
If such API is needed, it should be in omap_device. But in your case, I
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? Kevin That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
On Mon, Nov 22, 2010 at 5:03 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? Yes the patch is '[PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy' Kevin That still leaves the 500 L3 cycle delay though. Cheers, Peter. -- 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/13] OMAP3: OFF mode fixes
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 11/19/2010 03:20 PM, the following: Request for testing this series for comparison between master and this series requested for additional platforms where available. I haven't yet been through the entire series, but some general comments to share before the weekend: thanks for comments so far. I will wait for the complete series to be reviewed before reposting a v2. The secure mode code is growing in size and complexity, so I think it should be removed from pm34xx.c and moved into it's own file (secure3xxx.c ?) This will help keep pm34xx.c lean, and it can call into secure code as needed. IMHO - we should do that set of cleanups as part of Jean's patch series where we transition to sdram where possible - that will allow us to have C code replacement for sleep34xx.S and optimize better in conjunction with sram_idle function and helpers. No, I'd like to see the secure code in your patch all in a separate file. Jean's cleanups are independent of better organization and structure of your code. Even better (and already suggested in some comments on patch 8), now that there are board-configurable knobs, this should be set up as a very simple platform driver/device so boards can pass configuration in a standard way instead of having new APIs for use by board code to set configuration settings. in this specific context, having a platform data device is more of an overkill - 90% of the HS platforms (just a guess based on the limited devices I know of and is not a hard statistics) use the TI defaults - we do have exceptional customers who do their own PPA - and having a device-driver model IMHO is an overkill for that flexibility. The board-level configuration is only one (minor) reason to have a separate driver for the secure stuff. Discussions on the other patches suggested other reasons for this as well, including some reasons from you as well. :) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
On Mon, Nov 22, 2010 at 05:03:59PM +0100, ext Kevin Hilman wrote: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote: -Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Friday, November 19, 2010 9:37 AM On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet jean.pi...@newoldbits.com wrote: On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Here is what I experimented: 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases, 2) checked the real state entered in low power mode from the console messages, the output of /debug/pm_debug/count and PRCM registers dump 2) is OK, which means that the RET and OFF modes are correctly hit. Can I conclude from 1) that the wake-up code is not running from the cache in RETention? [Derrick, David] To add some context to the wait_sdrc_ok function and why it was added: wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles to lock. So you do not want to go back to DDR before DLL is locked. Also, we found some times DLL never locked so we introduced the DLL kick procedure to force it to lock. The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? Cheers, Peter. -- 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: newbie: can I ask a question about linux-omap-pm on this mailing list?
Gabi Voiculescu boy3d...@yahoo.com writes: Thank you for your reply. I am a newbie when it comes down to Linux git repositories. I am trying to do a 2.6.32 paravirtualization on top of L4, to run on the beagleboard(omap3 CPU), using as native kernel one from the linux-omap-pm repository. Why 2.6.32? It seems we have to run some userland modules that were written to be compatible with that version of Linux. One part of the problem is to select the best suitable native commit for this purpose. I am now trying to identify the best native commit from linux-omap-pm that fits the bill: working 2.6.32 + pm features for omap3 processors. My initial attempt was to use pm-2.6.32 branch (git checkout --track -b pm-2.6.32 origin/pm-2.6.32). I realized there are issues with some devices: the USB host (EHCI) detecting hubs. I have some problems navigating the linux-omap-pm git repository and I would really appreciate some feedback on these questions: 1. Was the pm-2.6.32 branch designed to add pm features to the TI 2.6.32-omap and Torvalds 2.6.32? 1.1. if true, the pm-2.6.32 was focused on omap1 (not omap3) features? 1.2. if not true, is there a better branch/commit/tag that deals with pm features on the omap3 SOC? 1.3. As far as you know has any testing been performed on omap3 with a version of Linux close to 2.6.32? This wiki might help a little: http://elinux.org/OMAP_Power_Management But also, a little clarification: The PM branch is for experimental, under development, rapidly changing, and unstable code. As the code is stabilized it merges upstream and disappears from the PM branch. As such, the PM branch should not be considered a stable development or product base. It's goal is to have a common base for the developers working on the OMAP PM core, and be the queue for new PM features to merge upstream. The branches/snapshots taken at various kernel release (e.g. 2.6.32) were for convenience, but there were no promises of stability or feature completeness. So, while I do maintain the PM branch, I do not support anything but the current versions on the latest kernel, and even there I make no promises of stability or feature completeness. In other words, once PM features are stable and complete enough, they merge into the mainline kernel, so only half-working or poorly designed features are left in the PM branch. I understand this probably sounds kind of harsh, but that is the current state of affairs. That being said, there are several code bases that used my pm-2.6.32 code base as a starting point (android-omap-2.6.32 for one) so you could start there, but your chances of getting help/support from the community on these older versions of the kernel are slim to none. I realize this probably doesn't help much, but hope it at least clarifies a little, Kevin Thank you for your input, Gabi Voiculescu --- On Mon, 11/22/10, S, Venkatraman svenk...@ti.com wrote: From: S, Venkatraman svenk...@ti.com Subject: Re: newbie: can I ask a question about linux-omap-pm on this mailing list? To: Gabi Voiculescu boy3d...@yahoo.com Cc: linux-omap linux-omap@vger.kernel.org Date: Monday, November 22, 2010, 12:36 PM Hi. I want to ask a newbie questions regarding linux-omap-pm repositories(http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary). I know this mailing list is for the linux-omap repository. I have searched the web for a mailing list specific for linux-omap-pm without success. Is this the right mailing list to pose my question? If not, can you point me to a better one? You have come to the right place. The linux-omap-pm tree is maintained by Kevin Hilman, and he checks this mailing list regularly. Ask away... -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. -- 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: DSP Bridge video decode of above VGA videos
Hi James, On Mon, Nov 22, 2010 at 9:26 AM, James Adams james.r.ad...@gmail.com wrote: D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding: nFrameW idth = 1280, nFrameHeight = 544 drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed. drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed. Does the version of your sync.c file points to sync_entercs() and the the assert failed for in_interrupt() for the line 357? Do your dspbridge version uses the WDT implementation? D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619 LCML_InitMMCodec Failed !...80001009 D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1 D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select Regards, Rene Sapiens -- 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: DSP Bridge video decode of above VGA videos
Hi Rene, We have got the watchdog timer enabled at the moment (interval 5 seconds). The code does indeed point to the line as you say. I tried using dump_stack and it was getting triggered by an interrupt calling handle_hibernation_fromDSP which then called functions eventually triggering the SYNC_entercs (via DEV_getfirst if I remember right) I certainly don't understand why this should happen, but it seems to happen quite a lot (probably every 5 seconds...) and the lower resolution videos didn't seem to mind so I have been ignoring it. Is it a bad idea to use WDT? Thanks, James On Mon, Nov 22, 2010 at 4:56 PM, Sapiens, Rene rene.sapi...@ti.com wrote: Hi James, On Mon, Nov 22, 2010 at 9:26 AM, James Adams james.r.ad...@gmail.com wrote: D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6573 After Rounding: nFrameW idth = 1280, nFrameHeight = 544 drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed. drivers/dsp/bridge/services/sync.c, line 357: Assertion (0) failed. Does the version of your sync.c file points to sync_entercs() and the the assert failed for in_interrupt() for the line 357? Do your dspbridge version uses the WDT implementation? D/TI_Video_Decoder( 934): VIDDEC_InitDSP_H264Dec():6619 LCML_InitMMCodec Failed !...80001009 D/TI_Video_Decoder( 934): VIDDEC_HandleCommand():1950 LCML Error 1 D/TI_Video_Decoder( 934): OMX_VidDec_Thread():165 Error in Select Regards, Rene Sapiens -- 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: [PATCHv4 1/14] OMAP2+: dmtimer: add device names to flck nodes
Hi Tarun,
On 11/20/2010 3:39 AM, Tarun Kanti DebBarma wrote:
From: Thara Gopinathth...@ti.com
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 58 +++--
arch/arm/mach-omap2/clock2430_data.c | 58 +++--
arch/arm/mach-omap2/clock3xxx_data.c | 46 --
arch/arm/mach-omap2/clock44xx_data.c | 42 ++--
4 files changed, 161 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..d2e90ae 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpt1_ick,gpt1_ick, CK_242X),
CLK(NULL, gpt1_fck,gpt1_fck, CK_242X),
Why is the timer1 not using a clockdev with device name?
+ CLK(omap-timer.1, fck,gpt1_fck, CK_242X),
It is the case for all the other platforms.
Thanks,
Benoit
CLK(NULL, gpt2_ick,gpt2_ick, CK_242X),
- CLK(NULL, gpt2_fck,gpt2_fck, CK_242X),
+ CLK(omap-timer.2, fck,gpt2_fck, CK_242X),
CLK(NULL, gpt3_ick,gpt3_ick, CK_242X),
- CLK(NULL, gpt3_fck,gpt3_fck, CK_242X),
+ CLK(omap-timer.3, fck,gpt3_fck, CK_242X),
CLK(NULL, gpt4_ick,gpt4_ick, CK_242X),
- CLK(NULL, gpt4_fck,gpt4_fck, CK_242X),
+ CLK(omap-timer.4, fck,gpt4_fck, CK_242X),
CLK(NULL, gpt5_ick,gpt5_ick, CK_242X),
- CLK(NULL, gpt5_fck,gpt5_fck, CK_242X),
+ CLK(omap-timer.5, fck,gpt5_fck, CK_242X),
CLK(NULL, gpt6_ick,gpt6_ick, CK_242X),
- CLK(NULL, gpt6_fck,gpt6_fck, CK_242X),
+ CLK(omap-timer.6, fck,gpt6_fck, CK_242X),
CLK(NULL, gpt7_ick,gpt7_ick, CK_242X),
- CLK(NULL, gpt7_fck,gpt7_fck, CK_242X),
+ CLK(omap-timer.7, fck,gpt7_fck, CK_242X),
CLK(NULL, gpt8_ick,gpt8_ick, CK_242X),
- CLK(NULL, gpt8_fck,gpt8_fck, CK_242X),
+ CLK(omap-timer.8, fck,gpt8_fck, CK_242X),
CLK(NULL, gpt9_ick,gpt9_ick, CK_242X),
- CLK(NULL, gpt9_fck,gpt9_fck, CK_242X),
+ CLK(omap-timer.9, fck,gpt9_fck, CK_242X),
CLK(NULL, gpt10_ick,gpt10_ick, CK_242X),
- CLK(NULL, gpt10_fck,gpt10_fck, CK_242X),
+ CLK(omap-timer.10,fck,gpt10_fck, CK_242X),
CLK(NULL, gpt11_ick,gpt11_ick, CK_242X),
- CLK(NULL, gpt11_fck,gpt11_fck, CK_242X),
+ CLK(omap-timer.11,fck,gpt11_fck, CK_242X),
CLK(NULL, gpt12_ick,gpt12_ick, CK_242X),
- CLK(NULL, gpt12_fck,gpt12_fck, CK_242X),
+ CLK(omap-timer.12,fck,gpt12_fck, CK_242X),
CLK(omap-mcbsp.1, ick,mcbsp1_ick,CK_242X),
CLK(omap-mcbsp.1, fck,mcbsp1_fck,CK_242X),
CLK(omap-mcbsp.2, ick,mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick,pka_ick, CK_242X),
CLK(NULL, usb_fck,usb_fck, CK_242X),
CLK(musb_hdrc,fck,osc_ck,CK_242X),
+ CLK(omap-timer.1, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.2, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.3, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.4, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.5, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.6, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.7, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.8, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.9, 32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.10,32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.11,32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.12,32k_ck,func_32k_ck, CK_243X),
+ CLK(omap-timer.1, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.2, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.3, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.4, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.5, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.6, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.7, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.8, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.9, sys_ck,sys_ck,CK_243X),
+ CLK(omap-timer.10,sys_ck,sys_ck,
Re: [PATCH] OMAP3: disable idle early in the suspend sequence
Jean Pihet jean.pi...@newoldbits.com writes:
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the call to disable_hlt at the very beginning
of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare),
and the call to enable_hlt at the very end of the suspend sequence
(in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
I think the description could have a little more detail. Something like:
Idle path should be disabled during the entire suspend/resume sequence.
Currently it is disabled in -prepare() and re-enabled in -finish(),
but the suspend sequence starts with -begin() and ends with -end(),
leaving windows where the suspend/resume sequence is still underway and
idle code could execute.
To fix, move idle disable and enable into -begin() and -end()
respectively to ensure idle path is disabled for the entire
suspend/resume sequence.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..022fdff 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -508,7 +508,6 @@ static suspend_state_t suspend_state;
static int omap3_pm_prepare(void)
{
- disable_hlt();
return 0;
}
@@ -576,12 +575,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
Might as well remove these empty functions now.
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,6 +590,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v2] AM35xx: Craneboard: Add USB EHCI support
srin...@mistralsolutions.com writes:
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..91791bc 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -28,8 +28,10 @@
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
#include mux.h
+#include control.h
/* Board initialization */
static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
@@ -53,10 +55,28 @@ static void __init am3517_crane_init_irq(void)
omap_gpio_init();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 38,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_crane_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(35, OMAP_PIN_OUTPUT);
Please define a symbolic constant for these GPIO numbers instead of using
hard-coded constants.
+ gpio_request(35, usb_ehci_enable);
GPIO APIs can fail. Please check return value and act accordingly.
+ gpio_direction_output(35, 1);
+ omap_mux_init_gpio(38, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
}
MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Nishanth Menon n...@ti.com writes: Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. It would be worth noting other known issues that are not worked around in this series due to external dependencies. Also, is the current SR/voltage series as proposed capable of handling the workaround for this fix? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin Hilman had written, on 11/22/2010 12:23 PM, the following: Nishanth Menon n...@ti.com writes: Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following: [...] The root cause for the DLL not locking has been found though and a workaround implemented. So it should work now :) Is the workaround for this reflected in Nishanth's series? No. It seems not. The workaround needs VDD2 voltage scaling which seems to be missing now from l-o ? yep, that is correct - we dont have dvfs/OPP/voltage scaling in kernel.org as of today - until we have those, it might not be possible to push the real workaround. the mentioned patch is, as documented, support for the voltage workaround. It would be worth noting other known issues that are not worked around in this series due to external dependencies. I believe I have done that http://marc.info/?l=linux-omapm=129013172525234w=2 IMPORTANT: this is not a complete workaround implementation as recommended by the silicon errata. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. Also, is the current SR/voltage series as proposed capable of handling the workaround for this fix? I believe a new series is due sometime- we should see if the required changes are part of that series. 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 10/13] OMAP3: PM: Errata i582: per domain reset issue: uart
[ +Govindraj for omap-serial ]
Nishanth Menon n...@ti.com writes:
From: Archana Sriram archana.sri...@ti.com
Errata Id:i582
PER Domain reset issue after Domain-OFF/OSWR Wakeup.
Issue:
When Peripheral Power Domain (PER-PD) is woken up from OFF / OSWR
state while Core Power Domain (CORE-PD) is kept active, write or
read access to some internal memory (e.g., UART3 FIFO) does not
work correctly.
Workaround :
* Prevent PER from going off when CORE has not gone to off.
We currently prevent this from happening in CPUidle: omap3_enter_idle_bm.
Its not clear if this patch is trying to do something additional
* When both CORE-PD and PER-PD goes into OSWR/OFF, PER-PD should be
brought to active before CORE-PD.This can be done by configuring a wakeup
dependency so that CORE-PD and PER-PD will wake up at the same time.
Acked-by: Tero Kristo tero.kri...@nokia.com
Tested-by: Eduardo Valentin eduardo.valen...@nokia.com
Tested-by: Westerberg Mika ext-mika.1.westerb...@nokia.com
[vishwanath...@ti.com: initial code and suggestions]
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[...@ti.com: forward ported to 2.6.37-rc2 and suggestions]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Archana Sriram archana.sri...@ti.com
I don't think the workaround for this erratum belongs in the PM core.
Rather, it seems to me that it belongs in the UART core, or even better,
the omap-serial driver (once it grows runtime PM support, which should
happen real soon now.)
We would like to to keep device specific idle/errata management in
device specific code wherever possible. This seems like an example
where this will be straight forward.
---
arch/arm/mach-omap2/pm34xx.c | 41 +++-
arch/arm/mach-omap2/serial.c | 80
++
arch/arm/plat-omap/include/plat/serial.h |4 ++
3 files changed, 124 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c7e2db0..218d0b0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -84,6 +84,10 @@ static struct powerdomain *cam_pwrdm;
static int secure_ram_save_status;
static int secure_ram_saved;
+#define PER_WAKEUP_ERRATA_i582 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATA(id) (pm34xx_errata (id))
+
static inline void omap3_per_save_context(void)
{
omap_gpio_save_context();
@@ -371,7 +375,8 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
- int core_prev_state, per_prev_state;
+ int core_prev_state = PWRDM_POWER_ON;
+ int per_prev_state = PWRDM_POWER_ON;
u32 sdrc_pwr = 0;
if (!_omap_sram_idle)
@@ -496,6 +501,23 @@ void omap_sram_idle(void)
omap3_per_restore_context();
omap_uart_resume_idle(2);
omap_uart_resume_idle(3);
+ if (IS_PM34XX_ERRATA(PER_WAKEUP_ERRATA_i582)
+ omap_uart_check_per_uarts_used()
+ (core_prev_state == PWRDM_POWER_ON)
+ (per_prev_state == PWRDM_POWER_OFF)) {
If the condition above is prevented, how is this happening?
As stated above, why can't this checking be done inside the UART core
(in this case omap_uart_resume_idle() ?)
+ /*
+ * We dont seem to have a real recovery other than reset
+ * Errata i582:Alternative available here is to do a
+ * reboot OR go to per off/core off, we will just print
+ * and cause uart to be in an unstable state and
+ * continue on till we hit the next off transition.
+ * Reboot of the device due to this corner case is
+ * undesirable.
+ */
+ if (omap_uart_per_errata())
+ pr_err(%s: PER UART hit with Errata i582
+ Corner case.\n, __func__);
+ }
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -1021,15 +1043,27 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void pm_errata_configure(void)
+{
+ if (cpu_is_omap34xx()) {
+ pm34xx_errata |= PER_WAKEUP_ERRATA_i582;
+ if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_1))
+ pm34xx_errata = ~PER_WAKEUP_ERRATA_i582;
+ }
+}
+
static int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
+ struct clockdomain *wkup_clkdm;
int ret;
if (!cpu_is_omap34xx())
return -ENODEV;
+ pm_errata_configure();
+
Re: [PATCH 00/13] OMAP3: OFF mode fixes
Nishanth Menon n...@ti.com writes: Bunch of fixes as part of phase 1 targetting mainly OMAP3630 HS devices for OFF mode logic. It is important to note - for proper functionality of HS OFF mode on OMAP3630, CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE=y and CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID should be set to the correct service that the security PPA supports on the platform. Based on kernel.org 2.6.37-rc2 tag Smoke tested on: SDP3630 -GP Zoom3 (3630): GP EMU (Es1.1, ES1.2) SDP3430 - GP EMU (ES3.1) These are fixes for corner case bugs seen, so tests of off and ret done with wakeup timer - behavior between 2.6.37-rc2 before and after applying patch seen consistent. Request for testing this series for comparison between master and this series requested for additional platforms where available. After some more thought and review, here's what I think should be the approach moving this forward: This can be broken up into 3 independent series as follows: 1) fix for UART erratum (patch 10) 2) fixes for idle path errata (patches 1, 2, 11, 12, 13) 3) secure ram save path (the rest) For (3), I'd like to see the secure ram management moved out of the PM core, and into it's own library/driver. Strictly speaking, context save/restore for secure ram is not a function of the PM idle core. As with every other device, context save/restore is the responsibility of the driver(s) using that device. For secure RAM, the restore is handled by ROM code, but the save should be managed by the secure driver(s). IOW, any secure driver should be using runtime PM and when the secure driver is no longer in use, it should ensure secure RAM context is saved using its runtime_suspend method to save secure RAM. The code in this series should be moved out into a library/driver which can be called by secure drivers in their runtime PM hooks. Stated otherwise, the PM core is doing the job that should be done by secure driver(s). Rather than continuing to extend that hack, it's time for that to be fixed correctly in a way that can be maintainted. Kevin Archana Sriram (1): OMAP3: PM: Errata i582: per domain reset issue: uart Eduardo Valentin (3): OMAP3: PM: Deny MPU idle while saving secure RAM OMAP3: PM: Apply errata i540 before save secure ram OMAP3630: PM: Errata i583: disable coreoff if ES1.2 Nishanth Menon (3): OMAP3: PM: make secure ram save size configurable OMAP3: PM: Fix secure save size for OMAP3 OMAP3630: PM: Errata i608: disable RTA Peter 'p2' De Schrijver (2): OMAP3: PM: Errata i581 suppport: dll kick strategy OMAP3630: PM: Disable L2 cache while invalidating L2 cache Richard Woodruff (1): OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all Tero Kristo (3): OMAP3: PM: Save secure RAM context before entering WFI OMAP3: PM: optional save secure RAM context every core off cycle OMAP3: PM: allocate secure RAM context memory from low-mem arch/arm/mach-omap2/control.c|5 +- arch/arm/mach-omap2/control.h|5 + arch/arm/mach-omap2/io.c | 11 ++ arch/arm/mach-omap2/pm.h | 40 +++ arch/arm/mach-omap2/pm34xx.c | 184 - arch/arm/mach-omap2/serial.c | 80 + arch/arm/mach-omap2/sleep34xx.S | 187 ++--- arch/arm/plat-omap/include/plat/serial.h |4 + 8 files changed, 412 insertions(+), 104 deletions(-) Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: disable idle during the entire suspend/resume sequence
From: Jean Pihet j-pi...@ti.com
Idle path should be disabled during the entire suspend/resume sequence.
Currently it is disabled in -prepare() and re-enabled in -finish(),
but the suspend sequence starts with -begin() and ends with -end(),
leaving windows where the suspend/resume sequence is still underway and
idle code could execute.
The fix is to move the idle disable (disable_hlt) and enable (enable_hlt)
into -begin() and -end() respectively to ensure that the idle path
is disabled for the entire suspend/resume sequence.
Remvoving omap3_pm_prepare and omap3_pm_finish since there are now empty.
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Comment rework suggested by Kevin.
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c | 15 ++-
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..2e0621e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -506,12 +506,6 @@ out:
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state;
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -574,14 +568,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,15 +581,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end= omap3_pm_end,
- .prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: disable idle early in the suspend sequence
On Mon, Nov 22, 2010 at 6:51 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Some bad interaction between the idle and the suspend paths has been
noticed: the idle code is called during the suspend enter and exit
sequences. This could cause corruption or lock-up of resources.
The solution is to move the call to disable_hlt at the very beginning
of the suspend sequence (in omap3_pm_begin instead of omap3_pm_prepare),
and the call to enable_hlt at the very end of the suspend sequence
(in omap3_pm_end instead of omap3_pm_finish).
Tested with RET and OFF on Beagle and OMAP3EVM.
I think the description could have a little more detail. Something like:
Idle path should be disabled during the entire suspend/resume sequence.
Currently it is disabled in -prepare() and re-enabled in -finish(),
but the suspend sequence starts with -begin() and ends with -end(),
leaving windows where the suspend/resume sequence is still underway and
idle code could execute.
To fix, move idle disable and enable into -begin() and -end()
respectively to ensure idle path is disabled for the entire
suspend/resume sequence.
Ok thx for the suggestion.
@@ -576,12 +575,12 @@ static int omap3_pm_enter(suspend_state_t unused)
static void omap3_pm_finish(void)
{
- enable_hlt();
}
Might as well remove these empty functions now.
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,6 +590,7 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
Kevin
Ok resent!
Thx,
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] omap4: l2x0: Construct the AUXCTRL value using defines
Santosh Shilimkar santosh.shilim...@ti.com writes:
This patch removes the hardcoded value of auxctrl value and
construct it using bitfields
Bit 25 is reserved and is always set to 1. Same value
of this bit is retained in this patch
Is this OMAP specific, or is this ARM generic?
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap4-common.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 2f89555..c814604 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -53,6 +53,8 @@ static void omap4_l2x0_disable(void)
static int __init omap_l2_cache_init(void)
{
+ u32 aux_ctrl = 0;
+
/*
* To avoid code running on other OMAPs in
* multi-omap builds
@@ -72,10 +74,17 @@ static int __init omap_l2_cache_init(void)
* Way size - 32KB (es1.0)
* Way size - 64KB (es2.0 +)
*/
+ aux_ctrl = ((1 L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT) |
+ (0x1 25) |
it doesn't look right to have a single hard-coded constant here among
the others. Either give this a name (RESERVED_ALWAYS_1, or something)
or add a comment to the code like is done in the changelog.
+ (0x1 L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT) |
+ (0x1 L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT));
+
if (omap_rev() == OMAP4430_REV_ES1_0)
- l2x0_init(l2cache_base, 0x0e05, 0xcfff);
+ aux_ctrl |= 0x2 L2X0_AUX_CTRL_WAY_SIZE_SHIFT;
else
- l2x0_init(l2cache_base, 0x0e07, 0xcfff);
+ aux_ctrl |= 0x3 L2X0_AUX_CTRL_WAY_SIZE_SHIFT;
+
+ l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
/*
* Override default outer_cache.disable with a OMAP4
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] omap4: l2x0: Construct the AUXCTRL value using defines
Kevin Hilman khil...@deeprootsystems.com writes: Santosh Shilimkar santosh.shilim...@ti.com writes: This patch removes the hardcoded value of auxctrl value and construct it using bitfields Bit 25 is reserved and is always set to 1. Same value of this bit is retained in this patch Is this OMAP specific, or is this ARM generic? The bit fields are generic PL310. It has to be set from OMAP code due to the ROM call. -- Måns Rullgård m...@mansr.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
Re: DSP Bridge video decode of above VGA videos
James, On Mon, Nov 22, 2010 at 11:12 AM, James Adams james.r.ad...@gmail.com wrote: Hi Rene, We have got the watchdog timer enabled at the moment (interval 5 seconds). The code does indeed point to the line as you say. I tried using dump_stack and it was getting triggered by an interrupt calling handle_hibernation_fromDSP which then called functions eventually triggering the SYNC_entercs (via DEV_getfirst if I remember right) I certainly don't understand why this should happen, but it seems to happen quite a lot (probably every 5 seconds...) and the lower resolution videos didn't seem to mind so I have been ignoring it. Looking at the drivers/dsp/bridge/wmd/tiomap3430_pwr.c file tagged with L25.12 release at [1] I don't see feasible the path to have handle_hibernation_fromDSP() to get to SYNC_entercs(), so probably you have a newer or older version of the file. Basically what i was looking with those assertions is to see if those could be because of a DSP WDT overflow. Also those assertions can fail because of the calling of IO_DispatchMsg by io_dpc(), if that's the case there should not be a problem. On the other hand if there is a WDT overflow those assertions could also fail. Can you double check by printing the call stack again when the assertion fails, just to see why for your case handle_hibernation_fromDSP() is failing in the assertion? Is it a bad idea to use WDT? No, it is ok to use it. Regards, Rene Sapiens -- [1] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/dsp/bridge/wmd/tiomap3430_pwr.c;h=f698b4475584e92467e03ecec96bc887948275f9;hb=64b404e9f457f19537972e7f2424f4c73a8a7789#l116 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set
Paul Walmsley p...@pwsan.com writes: On Tue, 16 Nov 2010, Paul Walmsley wrote: This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. Just FYI, this branch 'hwmod_a_2.6.38' is available at git://git.pwsan.com/linux-2.6 Warning: it's based on Tony's tree, not the mainline, due to the recent board file changes. Looks like Tony has collected the board file changes into his devel-board branch. Can this rebased there? That way, I can included it as part of the PM branch testing without having to pull in master. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: disable idle during the entire suspend/resume sequence
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Idle path should be disabled during the entire suspend/resume sequence.
Currently it is disabled in -prepare() and re-enabled in -finish(),
but the suspend sequence starts with -begin() and ends with -end(),
leaving windows where the suspend/resume sequence is still underway and
idle code could execute.
The fix is to move the idle disable (disable_hlt) and enable (enable_hlt)
into -begin() and -end() respectively to ensure that the idle path
is disabled for the entire suspend/resume sequence.
Remvoving omap3_pm_prepare and omap3_pm_finish since there are now empty.
Tested with RET and OFF on Beagle and OMAP3EVM.
Signed-off-by: Jean Pihet j-pi...@ti.com
Comment rework suggested by Kevin.
Cc: Kevin Hilman khil...@deeprootsystems.com
Thanks,
Unless there are any objections, I'll queue for .38 instead of .37-rc
since this isn't technically a regression.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 15 ++-
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..2e0621e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -506,12 +506,6 @@ out:
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state;
-static int omap3_pm_prepare(void)
-{
- disable_hlt();
- return 0;
-}
-
static int omap3_pm_suspend(void)
{
struct power_state *pwrst;
@@ -574,14 +568,10 @@ static int omap3_pm_enter(suspend_state_t unused)
return ret;
}
-static void omap3_pm_finish(void)
-{
- enable_hlt();
-}
-
/* Hooks to enable / disable UART interrupts during suspend */
static int omap3_pm_begin(suspend_state_t state)
{
+ disable_hlt();
suspend_state = state;
omap_uart_enable_irqs(0);
return 0;
@@ -591,15 +581,14 @@ static void omap3_pm_end(void)
{
suspend_state = PM_SUSPEND_ON;
omap_uart_enable_irqs(1);
+ enable_hlt();
return;
}
static struct platform_suspend_ops omap_pm_ops = {
.begin = omap3_pm_begin,
.end= omap3_pm_end,
- .prepare= omap3_pm_prepare,
.enter = omap3_pm_enter,
- .finish = omap3_pm_finish,
.valid = suspend_valid_only_mem,
};
#endif /* CONFIG_SUSPEND */
--
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 v4 1/3] omap: opp: add OMAP3 OPP table data and common init
Nishanth Menon n...@ti.com writes:
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
Some minor comments below...
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP3 in the Kconfig
v4:
Comments from Thomas addressed:
* Data switched to .c file and the c file included in opp.c
* init_table will fail with -EEXIST if already called
* minor comment improvements
Not addressed:
* request for board files to explicitly call init table
as discussed http://marc.info/?l=linux-omapm=128992417530385w=2
v3: http://marc.info/?t=12898493916r=1w=2
* added documentation for custom opp modification
by board files
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266911/
Documentation/arm/OMAP/omap_pm | 26 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/opp.c | 134
arch/arm/mach-omap2/opp3xxx_data.c | 98 ++
arch/arm/mach-omap2/pm.h |9 +++
6 files changed, 270 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp.c
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..88341f0 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,29 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+Customizing OPP for platform
+
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+ could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+ #include pm.h
+
+ static void __init omap_xyz_init_irq(void)
+ {
+
+ /* Initialize the default table */
+ omapx_opp_init();
+ /* Do customization to the defaults */
+
+ }
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
+
new blank line at EOF (reported by git-apply)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..93a91ff 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,6 +35,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+ select PM_OPP if PM
spaces before tab here (reported by git-apply)
config ARCH_OMAP4
bool TI OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..1650a62 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,6 +64,8 @@ endif
endif
+obj-$(CONFIG_PM_OPP) += opp.o
+
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
new file mode 100644
index 000..66e12be
--- /dev/null
+++ b/arch/arm/mach-omap2/opp.c
@@ -0,0 +1,134 @@
+/*
+ * OMAP SoC specific OPP wrapper function
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * 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/module.h
+#include linux/err.h
+#include linux/opp.h
+
+#include plat/cpu.h
+#include plat/omap_device.h
+
+#include pm.h
+
+/**
+ * struct omap_opp_def - OMAP OPP Definition
+ * @hwmod_name: Name of the hwmod for this domain
+ * @freq:Frequency in hertz corresponding to this OPP
+ * @u_volt: Nominal voltage in microvolts corresponding to this OPP
+ * @enabled: True/false - is this OPP enabled/disabled by default
+ *
+ * OMAP SOCs have
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Nishanth Menon n...@ti.com writes:
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP4 in Kconfig
V4: switched data to .c file
v3: http://marc.info/?l=linux-omapm=128984926712794w=2
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266921/
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/opp.c |3 +-
arch/arm/mach-omap2/opp4xxx_data.c | 49
arch/arm/mach-omap2/pm.h |5 +++
4 files changed, 57 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 93a91ff..0f1855a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -45,6 +45,7 @@ config ARCH_OMAP4
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
+ select PM_OPP if PM
spaces before tab (reported by git-apply)
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 66e12be..48a553f 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
/* omap3 opps */
#include opp3xxx_data.c
-
+/* omap4 opps */
+#include opp4xxx_data.c
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
new file mode 100644
index 000..6271774
--- /dev/null
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -0,0 +1,49 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ * Copyright (C) 2010 Texas Instruments Incorporated.
+ * Thara Gopinath
+ *
+ * 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.
+ */
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+ /* MPU OPP1 - OPP50 */
+ OPP_INITIALIZER(mpu, true, 3, 110),
+ /* MPU OPP2 - OPP100 */
+ OPP_INITIALIZER(mpu, true, 6, 120),
+ /* MPU OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(mpu, false, 8, 126),
+ /* MPU OPP4 - OPP-SB */
+ OPP_INITIALIZER(mpu, false, 100800, 135),
+ /* L3 OPP1 - OPP50 */
+ OPP_INITIALIZER(l3_main_1, true, 1, 93),
+ /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OPP_INITIALIZER(l3_main_1, true, 2, 110),
+ /* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+int __init omap4_opp_init(void)
+{
+ int r = -ENODEV;
+
+ if (!cpu_is_omap44xx())
+ return r;
+
+ r = omap_init_opp_table(omap44xx_opp_def_list,
+ ARRAY_SIZE(omap44xx_opp_def_list));
+
+ return r;
+}
+device_initcall(omap4_opp_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2031f15..a43e069 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
#else
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+ return -EINVAL;
+}
#endif
Now that these are device_initcalls, seems like they can be made static
and not callable externally.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Kevin Hilman wrote, on 11/22/2010 04:45 PM:
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+ return -EINVAL;
+}
#endif
Now that these are device_initcalls, seems like they can be made static
and not callable externally.
how do we handle boards that need custom opp table modifications?
--
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 ver. 2] PM: add synchronous runtime interface for interrupt handlers
On Monday, November 22, 2010, Alan Stern wrote: On Mon, 22 Nov 2010, Rafael J. Wysocki wrote: I didn't like this change before and I still don't like it. Quite frankly, I'm not sure I can convince Linus to pull it. :-) Why don't we simply execute the callback under the spinlock in the IRQ safe case? Because it wouldn't work. The job of the runtime_idle callback is to call pm_runtime_suspend when needed. But if the callback runs under the spinlock then pm_runtime_suspend would hang when it tries to grab the lock. Yes, in the _idle case. I actually should have put my comment under the change in rpm_callback(), which is what I really meant. But the new rpm_callback() _does_ simply execute the callback under the spinlock in the irq-safe case. So I don't understand what you mean here. OK, sorry, I confused things. I have no objections to this part, then, let's focus on the _idle case. Moreover, I'm not sure if we need an IRQ safe version of _idle. Why do we need it, exactly? Because pm_runtime_put_sync() calls rpm_idle(). If there were no irq-safe version of rpm_idle() then drivers wouldn't be able to call pm_runtime_put_sync() from within an interrupt handler. Right. Which they can't do now, can they? Why do you think we should allow them to do that? The problem I have with this change is that switching interrupts off really is a part of the locking operation, so using spin_unlock() after spin_lock_irq...() is kind of like releasing the lock partially, which I don't think is valid (even if we're going to reacquire the lock immediately). On the contrary; spin_unlock() after spin_lock_irq() doesn't partially release the lock -- it releases the lock _entirely_! :-) Well, not really, as far as I understand it. The semantics of spin_lock_irq() is turn interrupts off to prevent interrupt handlers running on _this_ CPU from racing with us and acquire the lock to prevent _other_ CPUs from racing with us. If you build the code for non-SMP it becomes the first part only. So IMO the turn interrupts on/off thing is a part of the full synchronization mechanism in this case. Anyway, though, if the only reason of doing this is to allow interrupt handlers to call pm_runtime_put_sync(), then I rather wouldn't do it at all. Thanks, Rafael -- 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 1/1] serial: omap-serial: Add support for kernel debugger
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch also changes the initialization order because the
kgdb will check at the very beginning, if there is a valid serial
driver.
Signed-off-by: Cosmin Cojocar cosmin.cojo...@gmail.com
---
drivers/serial/Makefile |2 +-
drivers/serial/omap-serial.c | 44 -
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c570576..ad86113 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
+obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE)+= timbuart.o
@@ -88,4 +89,3 @@ obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
obj-$(CONFIG_SERIAL_MRST_MAX3110) += mrst_max3110.o
obj-$(CONFIG_SERIAL_MFD_HSU) += mfd.o
-obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 03a96db..f18b73d 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -866,12 +866,6 @@ serial_omap_type(struct uart_port *port)
return up-name;
}
-#ifdef CONFIG_SERIAL_OMAP_CONSOLE
-
-static struct uart_omap_port *serial_omap_console_ports[4];
-
-static struct uart_driver serial_omap_reg;
-
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
static inline void wait_for_xmitr(struct uart_omap_port *up)
@@ -905,6 +899,40 @@ static inline void wait_for_xmitr(struct uart_omap_port
*up)
}
}
+#ifdef CONFIG_CONSOLE_POLL
+
+static void serial_omap_poll_put_char(struct uart_port *port, unsigned char ch)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+ unsigned int status;
+
+ do {
+ status = serial_in(up, UART_LSR);
+ udelay(1);
+ } while ((status BOTH_EMPTY) != BOTH_EMPTY);
+
+ serial_out(up, UART_TX, ch);
+}
+
+static int serial_omap_poll_get_char(struct uart_port *port)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+ unsigned int status = serial_in(up, UART_LSR);
+
+ if (!(status UART_LSR_DR))
+ return NO_POLL_CHAR;
+
+ return serial_in(up, UART_RX);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+
+static struct uart_omap_port *serial_omap_console_ports[4];
+
+static struct uart_driver serial_omap_reg;
+
static void serial_omap_console_putchar(struct uart_port *port, int ch)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -1022,6 +1050,10 @@ static struct uart_ops serial_omap_pops = {
.request_port = serial_omap_request_port,
.config_port= serial_omap_config_port,
.verify_port= serial_omap_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_put_char = serial_omap_poll_put_char,
+ .poll_get_char = serial_omap_poll_get_char,
+#endif
};
static struct uart_driver serial_omap_reg = {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Nishanth Menon n...@ti.com writes:
Kevin Hilman wrote, on 11/22/2010 04:45 PM:
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+return -EINVAL;
+}
#endif
Now that these are device_initcalls, seems like they can be made static
and not callable externally.
how do we handle boards that need custom opp table modifications?
um..., er... ok, I was just testing to see if you were awake today. :/
Clearly I'm not remembering even my own feature suggestions. Sorry for
the noise. Guess I'm trying to review too many different series today.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Nishanth Menon n...@ti.com writes: This patch adds OPP tables for OMAP4. New file has been added to keep the OMAP4 opp tables and the registration of these tables with the generic opp framework by OMAP SoC OPP interface. [...] diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c index 66e12be..48a553f 100644 --- a/arch/arm/mach-omap2/opp.c +++ b/arch/arm/mach-omap2/opp.c @@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def *opp_def, /* omap3 opps */ #include opp3xxx_data.c - +/* omap4 opps */ +#include opp4xxx_data.c I'm not sure I like the including of C files. Any reason you prefer this to just adding them to the Makefile? e.g. opp24xx_dta.c are compiled in via Makefile and these two are included. I vote for consistency. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] serial: omap-serial: Add support for kernel debugger
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch also changes the initialization order because the
kgdb will check at the very beginning, if there is a valid serial
driver.
Signed-off-by: Cosmin Cojocar cosmin.cojo...@gmail.com
---
drivers/serial/Makefile |2 +-
drivers/serial/omap-serial.c | 38 --
2 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index c570576..ad86113 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
+obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE)+= timbuart.o
@@ -88,4 +89,3 @@ obj-$(CONFIG_SERIAL_ALTERA_JTAGUART) += altera_jtaguart.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
obj-$(CONFIG_SERIAL_MRST_MAX3110) += mrst_max3110.o
obj-$(CONFIG_SERIAL_MFD_HSU) += mfd.o
-obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 03a96db..552759e 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -866,12 +866,6 @@ serial_omap_type(struct uart_port *port)
return up-name;
}
-#ifdef CONFIG_SERIAL_OMAP_CONSOLE
-
-static struct uart_omap_port *serial_omap_console_ports[4];
-
-static struct uart_driver serial_omap_reg;
-
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
static inline void wait_for_xmitr(struct uart_omap_port *up)
@@ -905,6 +899,34 @@ static inline void wait_for_xmitr(struct uart_omap_port
*up)
}
}
+#ifdef CONFIG_CONSOLE_POLL
+
+static void serial_omap_poll_put_char(struct uart_port *port, unsigned char ch)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+ wait_for_xmitr(up);
+ serial_out(up, UART_TX, ch);
+}
+
+static int serial_omap_poll_get_char(struct uart_port *port)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+ unsigned int status = serial_in(up, UART_LSR);
+
+ if (!(status UART_LSR_DR))
+ return NO_POLL_CHAR;
+
+ return serial_in(up, UART_RX);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+
+static struct uart_omap_port *serial_omap_console_ports[4];
+
+static struct uart_driver serial_omap_reg;
+
static void serial_omap_console_putchar(struct uart_port *port, int ch)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -1022,6 +1044,10 @@ static struct uart_ops serial_omap_pops = {
.request_port = serial_omap_request_port,
.config_port= serial_omap_config_port,
.verify_port= serial_omap_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_put_char = serial_omap_poll_put_char,
+ .poll_get_char = serial_omap_poll_get_char,
+#endif
};
static struct uart_driver serial_omap_reg = {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] omap4: opp: add OPP table data
Kevin Hilman wrote, on 11/22/2010 05:19 PM: Nishanth Menonn...@ti.com writes: This patch adds OPP tables for OMAP4. New file has been added to keep the OMAP4 opp tables and the registration of these tables with the generic opp framework by OMAP SoC OPP interface. [...] diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c index 66e12be..48a553f 100644 --- a/arch/arm/mach-omap2/opp.c +++ b/arch/arm/mach-omap2/opp.c @@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def *opp_def, /* omap3 opps */ #include opp3xxx_data.c - +/* omap4 opps */ +#include opp4xxx_data.c I'm not sure I like the including of C files. Any reason you prefer this to just adding them to the Makefile? e.g. opp24xx_dta.c are compiled in via Makefile and these two are included. I dont buy it. I am seeing us go around in circles for this: http://marc.info/?l=linux-omapm=128986880406272w=2 a) we dont want others to use specifics implemented in opp.c in other files (e.g. board files) b) we have many similar usage in linux kernel - so this usage is not first time. c) opp2xx usage is very different from opp3/4 usage -- 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 v4 2/3] omap4: opp: add OPP table data
Nishanth Menon n...@ti.com writes: Kevin Hilman wrote, on 11/22/2010 05:19 PM: Nishanth Menonn...@ti.com writes: This patch adds OPP tables for OMAP4. New file has been added to keep the OMAP4 opp tables and the registration of these tables with the generic opp framework by OMAP SoC OPP interface. [...] diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c index 66e12be..48a553f 100644 --- a/arch/arm/mach-omap2/opp.c +++ b/arch/arm/mach-omap2/opp.c @@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def *opp_def, /* omap3 opps */ #include opp3xxx_data.c - +/* omap4 opps */ +#include opp4xxx_data.c I'm not sure I like the including of C files. Any reason you prefer this to just adding them to the Makefile? e.g. opp24xx_dta.c are compiled in via Makefile and these two are included. I dont buy it. I am seeing us go around in circles for this: http://marc.info/?l=linux-omapm=128986880406272w=2 a) we dont want others to use specifics implemented in opp.c in other files (e.g. board files) not sure how this is prevented. b) we have many similar usage in linux kernel - so this usage is not first time. c) opp2xx usage is very different from opp3/4 usage I'm not going to insist on one way or the other, just stating my preference for not including C files from C files without good justification. You've stated your reasons, I guess Tony can decide. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] serial: omap-serial: Add support for kernel debugger
On Tue, Nov 23, 2010 at 12:24:12AM +0100, Cosmin Cojocar wrote: The kgdb invokes the poll_put_char and poll_get_char when communicating with the host. This patch also changes the initialization order because the kgdb will check at the very beginning, if there is a valid serial driver. What was the difference between v2 and v3? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set
On Mon, 22 Nov 2010, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Tue, 16 Nov 2010, Paul Walmsley wrote: This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. Just FYI, this branch 'hwmod_a_2.6.38' is available at git://git.pwsan.com/linux-2.6 Warning: it's based on Tony's tree, not the mainline, due to the recent board file changes. Looks like Tony has collected the board file changes into his devel-board branch. Can this rebased there? That way, I can included it as part of the PM branch testing without having to pull in master. hwmod_a_2.6.38 is now based on devel-board and wdt_2.6.38 is now rebased on the updated hwmod_a_2.6.38. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] serial: omap-serial: Add support for kernel debugger
The v2 was a intermediate testing version which I sent it out by mistake. The difference between the tow is that the v2 uses a infinite loop to wait for data to be transfered out form buffer, whereas the v3 relies on existing wait_form_xmitr function. Regards, Cosmin Greg KH wrote: On Tue, Nov 23, 2010 at 12:24:12AM +0100, Cosmin Cojocar wrote: The kgdb invokes the poll_put_char and poll_get_char when communicating with the host. This patch also changes the initialization order because the kgdb will check at the very beginning, if there is a valid serial driver. What was the difference between v2 and v3? -- 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 v3 1/1] serial: omap-serial: Add support for kernel debugger
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Nov 23, 2010 at 01:18:51AM +0100, Cosmin Cojocar wrote: The v2 was a intermediate testing version which I sent it out by mistake. The difference between the tow is that the v2 uses a infinite loop to wait for data to be transfered out form buffer, whereas the v3 relies on existing wait_form_xmitr function. In the future, please say this in the comment section in the patch (i.e. below the --- line.) 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 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
Hello Janusz, Mark,
On Tue, 2 Nov 2010, Janusz Krzysztofik wrote:
In the new code introduced with commit
cf4c87abe238ec17cd0255b4e21abd949d7f811e,
OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via
mach-omap2/mcbsp.c,
the way omap1 build is supposed to bypass omap2 specific functionality
doesn't
optimize out all omap2 specific stuff. This breaks linking phase for omap1
machines, giving undefined reference to `omap2_mcbsp1_mux_clkr_src'
and undefined reference to `omap2_mcbsp1_mux_fsr_src' errors. Fix it.
Created and tested against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Thanks for fixing this. What do you think about the following patch
instead? It should avoid any compiler issues.
- Paul
From: Paul Walmsley p...@pwsan.com
Subject: [PATCH] ASoC: OMAP: McBSP: fix build breakage on OMAP1
After commits d13586574d373ef40acd4725c9a269daa355e412 (OMAP: McBSP:
implement functional clock switching via clock framework) and
cf4c87abe238ec17cd0255b4e21abd949d7f811e (OMAP: McBSP: implement
McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c), any OMAP1
board (such as the AMS Delta) that uses the ASoC McBSP driver will no
longer build:
sound/built-in.o: In function `omap_mcbsp_dai_set_dai_sysclk':
last.c:(.text+0x24ff8): undefined reference to `omap2_mcbsp1_mux_clkr_src'
last.c:(.text+0x2500c): undefined reference to `omap2_mcbsp1_mux_fsr_src'
make: *** [vmlinux] Error 1
Fix by defining three OMAP1-only dummy functions for
omap2_mcbsp1_mux_clkr_src(), omap2_mcbsp1_mux_fsr_src(), and
omap2_mcbsp_set_clks_src().
Normally, code that is OMAP SoC-revision-specific like this should go
under the arch/arm/*omap* directories, and get abstracted away from
drivers via struct platform_data function pointers. This doesn't work
in this case since there doesn't appear to be any convenient way to access
struct platform_data (or something like it) in the current design of
the sound/soc/omap/omap-mcbsp.c driver.
Reported by Janusz Krzysztofik jkrzy...@tis.icnet.pl and Tony Lindgren
t...@atomide.com. Janusz also posted a patch to fix this at:
http://www.spinics.net/lists/linux-omap/msg39560.html
(among other places), but the following approach seems less dependent
on compiler behavior.
This patch passes build tests for ams_delta_defconfig and omap2plus_defconfig,
but since I don't have an AMS Delta here, I can't boot test it on that
platform.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@slimlogic.co.uk
---
arch/arm/plat-omap/mcbsp.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index fdecd33..1fbfcf3 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1466,6 +1466,33 @@ void omap_mcbsp_set_spi_mode(unsigned int id,
}
EXPORT_SYMBOL(omap_mcbsp_set_spi_mode);
+/*
+ * The following functions are only required on an OMAP1-only build.
+ * mach-omap2/mcbsp.c contains the real functions
+ */
+#ifndef CONFIG_ARCH_OMAP2PLUS
+int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
+{
+ WARN(1, %s: should never be called on an OMAP1-only kernel\n,
+__func__);
+ return -EINVAL;
+}
+
+void omap2_mcbsp1_mux_clkr_src(u8 mux)
+{
+ WARN(1, %s: should never be called on an OMAP1-only kernel\n,
+__func__);
+ return;
+}
+
+void omap2_mcbsp1_mux_fsr_src(u8 mux)
+{
+ WARN(1, %s: should never be called on an OMAP1-only kernel\n,
+__func__);
+ return;
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP3
#define max_thres(m) (mcbsp-pdata-buffer_size)
#define valid_threshold(m, val)((val) = max_thres(m))
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Trouble getting Logic OMAp35x modules to boot
I've pulled the latest linux-2.6.37-rc3 kernel from kernel.org, and using the arch/arm/configs/omap3plus_defconfig as .config, and turning on: CONFIG_MACH_OMAP35CONFIG_MACH_OMAP3530_LV_SOM=y CONFIG_MACH_OMAP3_TORPEDO=y to run on the Logic OMAP35x boards, it failed to boot (no output from the serial console). I added: CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y to turn on early debigging (and adding earlyprintk to the command line), and see all looks fine up to the end of: Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.37-rc3-svn12998 (pe...@blitz) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #5 SMP Mon Nov 22 17:09:07 EST 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Logic OMAP3 Torpedo board debug: ignoring loglevel setting. bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c05450a0, node_mem_map c0579000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65024 pages, LIFO batch:15 PERCPU: Embedded 7 pages/cpu @c077c000 s4928 r8192 d15552 u32768 pcpu-alloc: s4928 r8192 d15552 u32768 alloc=8*4096 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: display=15 console=ttyS0,115200 root=/dev/nfs rw nfsroot=19 2.168.3.5:/opt/nfs-exports/ltib-omap,wsize=1500,rsize=1500 ip=dhcp no_console_su spend ignore_loglevel earlyprintk PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256MB = 256MB total Memory: 254252k/254252k available, 7892k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xd080 - 0xf800 ( 632 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0048000 ( 256 kB) .text : 0xc0048000 - 0xc04e9c50 (4744 kB) .data : 0xc04ea000 - 0xc0545880 ( 367 kB) Hierarchical RCU implementation. NR_IRQS:402 Clocking rate (Crystal/Core/MPU): 26.0/166/500 MHz Reprogramming SDRC clock to 16600 Hz dpll3_m2_clk rate change failed: -22 GPMC revision 5.0 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller Could not get gpios_ick Could not get gpios_fck OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Brought up 1 CPUs SMP: Total of 1 processors activated (499.92 BogoMIPS). regulator: core version 0.5 regulator: dummy: NET: Registered protocol family 16 mux: Setting signal sdmmc1_dat5.gpio_127 0x0118 - 0x0004 mux: Setting signal sdmmc1_dat5.gpio127 0x0004 - 0x011c mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x0018 - 0x0118 mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x0118 - 0x0118 mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0118 - 0x0118 mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0118 - 0x0118 mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0118 - 0x0118 mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0118 - 0x0118 mux: Setting signal sdmmc1_dat7.gpio_129 0x0118 - 0x0104 mux: Setting signal sdrc_cke0.sdrc_cke0 0x0118 - 0x mux: Setting signal sdrc_cke1.sdrc_cke1 0x0118 - 0x hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 regulator: VMMC1: 1850 -- 3150 mV at 3000 mV normal standby Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered UDP hash table entries: 128 (order: 0, 4096 bytes) UDP-Lite hash table entries: 128 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp
Re: [PATCH ver. 2] PM: add synchronous runtime interface for interrupt handlers
On Tue, 23 Nov 2010, Rafael J. Wysocki wrote: Moreover, I'm not sure if we need an IRQ safe version of _idle. Why do we need it, exactly? Because pm_runtime_put_sync() calls rpm_idle(). If there were no irq-safe version of rpm_idle() then drivers wouldn't be able to call pm_runtime_put_sync() from within an interrupt handler. Right. Which they can't do now, can they? True. That was the point of this patch -- to allow interrupt handlers to do runtime PM, which they can't do now. Why do you think we should allow them to do that? Are you suggesting that interrupt handlers stick to pm_runtime_suspend and pm_runtime_resume, and ignore pm_runtime_get_sync and pm_runtime_put_sync? Recall that after probing is finished, the driver core does a pm_runtime_put_sync. That might happen while an interrupt handler is running on another CPU. If the interrupt handler didn't increment the usage_count, the driver core could cause the device to suspend while the interrupt handler was still using it. Or are you suggesting that interrupt handlers use pm_runtime_get_sync and implement a poor-man's version of pm_runtime_put_sync by doing: pm_runtime_put_no_idle(); pm_runtime_suspend(); Is there some particular reason for denying interrupt handlers the ability to use pm_runtime_put_sync? It seems odd to disallow that while allowing pm_runtime_get_sync. Or maybe you think that when pm_runtime_put_sync detects the usage_count has decremented to 0 and the device is irq-safe, it should call rpm_suspend directly instead of calling rpm_idle? In short, I don't see any reason not to present the same API to interrupt handlers for irq-safe devices as we present to process-context drivers for ordinary devices. Anyway, though, if the only reason of doing this is to allow interrupt handlers to call pm_runtime_put_sync(), then I rather wouldn't do it at all. Why not? Alan Stern -- 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: hwmod, iclks, auto-idle and autodeps
Hi Kevin and I discussed this privately, this is just to summarize for everyone else. On Wed, 17 Nov 2010, Kevin Hilman wrote: There have been a few discussions over the few months about how to properly use omap_hwmod to manage certain IPs that have the interface clock as the functional clock (e.g. OMAP3 GPIOs.) The goal of this RFC is to come to a conclusion about what should be done, and how to go about implementing it. In the initial conversion of the GPIO core to omap_hwmod, main_clk was left NULL so that hwmod was not managing the clock on every hwmod enable/disable. Since GPIO has a register target, main_clk cannot be null. There's an erroneous comment in plat/omap_hwmod.h about this; I'll add it to my list of things to fix. This behavior matched current mainline GPIO code, which does not dynamically disable/enable GPIO iclks after init time. Instead, it relies on the module-level auto idle feature in HW. However, without dynamically managing the clock in hwmod, this meant that there were no autodeps tracked for GPIO and thus the PER powerdomain could transition independently of MPU/CORE. The current GPIO driver works only because it exploits some incidental properties of the OMAP core code. It implicitly relies on CM_AUTOIDLE = 1 on its iclk for power management to work, since the driver never disables its iclk. The driver also relies on the addition of MPU/IVA2 autodeps to avoid losing logic context once all devices in PER go idle. And by never explicitly disabling its iclk, the driver avoids dealing with the various GPIO wakeup/interrupt modes, causing its context save/restore to be implemented as a weird hack in pm34xx.c. That said, there definitely is one real limitation/bug in the OMAP PM core code that the GPIO driver has to work around. The current core code doesn't try to keep a powerdomain powered when an IP block inside the powerdomain is still considered to be in use but all its system-sourced clocks are cut. This can result in unexpected context loss and malfunction in some GPIO and McBSP cases, possibly some other modules also that can be externally clocked and contain FIFOs/buffers, or that can generate asynchronous wakeups. There's a patch in the works here that will require a powerdomain to stay on as long as a hwmod in that powerdomain is enabled. Once omap_hwmod_idle() is called for that hwmod, the lower-bound on the power state of the powerdomain is removed. So in the context of the PM runtime conversion of the GPIO driver, the thing to do is to only do a pm_runtime_put*() once the GPIO module is really ready to be powered down. After that call, the GPIO block may lose its logic context, and it may not be able to generate interrupts or wakeups. We may enforce the latter in the hwmod code for debugging purposes by forcing the module into idle and instructing the PRCM to ignore wakeups from the module in omap_hwmod_idle(). IO ring/chain wakeups may still occur, but these are independent of the GPIO block. The rest of the time, if the GPIO driver wants to use idle-mode wakeups (presumably higher wakeup latency, but lower power consumption), it should just clk_disable() its clocks, but not call pm_runtime_put*(). After the previously-mentioned improvement to the powerdomain/hwmod code is completed and applied, that should result in the powerdomain staying powered, but all clocks being disabled. Otherwise, if the GPIO driver wants to use active-mode interrupts (presumably lower wakeup latency, but higher power consumption), then the driver should just leave its clocks enabled and never call pm_runtime_put*(). Both of these latter modes will block some low-power states. At some point, the selection of the interrupt/wakeup mode -- GPIO active, GPIO idle, IO ring/chain -- should be made based on the required wakeup latency of the GPIO user. Multiple modes may need to used simultaneously, since individual modes are restricted to certain power states (e.g. IO ring is only available in CORE off, IO chain is only available in CORE/PER retention) The initial solution to this was to set the iclk to be the main_clk of the hwmod, such that autodeps were managed dynamically as well. This led to a change in functionality in current code, since the iclk was now being manually enabled/disabled at runtime instead of being left for HW to manage by module autoidle. It also led to problems in correctly handling asynchronous GPIO wakeups. If idle-mode wakeup is used, then the PRCM ISR code that notes the GPIO wakeup event either needs to enable the GPIO main clock before calling its ISR, or the GPIO ISR needs to enable its main clock first thing. If active-mode interrupts are used, then the GPIO ISR doesn't need to enable its main clock since it is already running at that point. Alternatively, would it make sense to do something different with autodeps, such that modules like this that don't
Re: Trouble getting Logic OMAp35x modules to boot
On Tue, Nov 23, 2010 at 7:50 AM, Peter Barada pet...@logicpd.com wrote: I've pulled the latest linux-2.6.37-rc3 kernel from kernel.org, and using the arch/arm/configs/omap3plus_defconfig as .config, and turning on: CONFIG_MACH_OMAP35CONFIG_MACH_OMAP3530_LV_SOM=y CONFIG_MACH_OMAP3_TORPEDO=y to run on the Logic OMAP35x boards, it failed to boot (no output from the serial console). I added: CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y to turn on early debigging (and adding earlyprintk to the command line), and see all looks fine up to the end of: Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.37-rc3-svn12998 (pe...@blitz) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #5 SMP Mon Nov 22 17:09:07 EST 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Logic OMAP3 Torpedo board debug: ignoring loglevel setting. bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c05450a0, node_mem_map c0579000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65024 pages, LIFO batch:15 PERCPU: Embedded 7 pages/cpu @c077c000 s4928 r8192 d15552 u32768 pcpu-alloc: s4928 r8192 d15552 u32768 alloc=8*4096 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: display=15 console=ttyS0,115200 root=/dev/nfs rw nfsroot=19 2.168.3.5:/opt/nfs-exports/ltib-omap,wsize=1500,rsize=1500 ip=dhcp no_console_su ... io scheduler noop registered io scheduler deadline registered where the output turns to trash on the serial console. 1) Is omap2plus_defconfig the default kernel configuration I should use for the Logic OMAP35x boards? 2) If so, any suggestions on where/why the console serial port is going south? If you have CONFIG_SERIAL_OMAP enabled (which should be enabled with the omap2plus_defconfig, then the serial port would now be ttyO0 instead of ttyS0. Try changing this. - 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: Trouble getting Logic OMAp35x modules to boot
On 11/23/2010 12:05 AM, Gadiyar, Anand wrote: On Tue, Nov 23, 2010 at 7:50 AM, Peter Baradapet...@logicpd.com wrote: I've pulled the latest linux-2.6.37-rc3 kernel from kernel.org, and using the arch/arm/configs/omap3plus_defconfig as .config, and turning on: CONFIG_MACH_OMAP35CONFIG_MACH_OMAP3530_LV_SOM=y CONFIG_MACH_OMAP3_TORPEDO=y to run on the Logic OMAP35x boards, it failed to boot (no output from the serial console). I added: CONFIG_DEBUG_LL=y CONFIG_EARLY_PRINTK=y to turn on early debigging (and adding earlyprintk to the command line), and see all looks fine up to the end of: Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.37-rc3-svn12998 (pe...@blitz) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #5 SMP Mon Nov 22 17:09:07 EST 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Logic OMAP3 Torpedo board debug: ignoring loglevel setting. bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c05450a0, node_mem_map c0579000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65024 pages, LIFO batch:15 PERCPU: Embedded 7 pages/cpu @c077c000 s4928 r8192 d15552 u32768 pcpu-alloc: s4928 r8192 d15552 u32768 alloc=8*4096 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: display=15 console=ttyS0,115200 root=/dev/nfs rw nfsroot=19 2.168.3.5:/opt/nfs-exports/ltib-omap,wsize=1500,rsize=1500 ip=dhcp no_console_su ... io scheduler noop registered io scheduler deadline registered where the output turns to trash on the serial console. 1) Is omap2plus_defconfig the default kernel configuration I should use for the Logic OMAP35x boards? 2) If so, any suggestions on where/why the console serial port is going south? If you have CONFIG_SERIAL_OMAP enabled (which should be enabled with the omap2plus_defconfig, then the serial port would now be ttyO0 instead of ttyS0. Try changing this. That worked a lot better, things came up to the point I was able to SSH into the board and do my testing; I need to fixup my /etc/inittab, etc. to use /dev/ttyOx instead of /dev/ttyOx... However, I'm seeing the same corruption on UART3 at 115200 I mentioned previously in: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38861.html (and why I'm investigating 2.6.32-rc7). Any ideas why 2.6.37-rc3 exhibits the same behavior? Also, where in the kernel is the mux setup for the UARTs done? I'd like to use UART2 and am not sure how to wire it into the kernel(i.e. setup the mux for it as those pins are in mode 7) and want to follow the same style as that for UART1/3.. Thanks in advance! - Anand -- Peter Barada pet...@logicpd.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
Re: [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
On Mon, 22 Nov 2010 17:48:24 -0700 (MST)
Paul Walmsley p...@pwsan.com wrote:
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Thanks for fixing this. What do you think about the following patch
instead? It should avoid any compiler issues.
Hmm.. looks like Janusz's patch is still in Liam's for-2.6.37
branch only.
+/*
+ * The following functions are only required on an OMAP1-only build.
+ * mach-omap2/mcbsp.c contains the real functions
+ */
+#ifndef CONFIG_ARCH_OMAP2PLUS
+int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
+{
Would that create a new problem if we are able to compile some day
omap1 and omap2 support into same kernel? I agree with you that passing
these via platform_data sounds the right solution.
--
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
On Mon, 22 Nov 2010 17:50:54 -0700 (MST) Paul Walmsley p...@pwsan.com wrote: By the way, ASoC and OMAP audio-hackers, I deeply regret how much trouble that SCM cleanup series has caused. It does not meet my personal standards for a patch-series... Hey, small compile breaks happens to everyone and word trouble doesn't come to my mind when speaking about your set. Your set actually did one major step forward with ASoC OMAP drivers - now it's possible to have modular build with them so your work has lot of benefits to developers and distro builders. -- Jarkko -- 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
