Re: [PATCH 4/6] OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter
On Wednesday 18 April 2012 08:28 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: DISPC manager size and DISPC manager blanking parameters(for LCD managers) follow the shadow register programming model. Currently, they are programmed directly by the interface drivers. Make timings(omap_video_timing struct) an overlay_manager_info member, they are now programmed via the apply mechanism used for programming shadow registers. The interface driver now call the function dss_mgr_set_timings() which applies the new timing parameters, rather than directly writing to DISPC registers. I don't think that works correctly. The omap_overlay_manager_info is supposed to be set with set_manager_info() by the user of omapdss, to configure the manager's features. The timings are not supposed to be set via that mechanism, but with dssdev-set_timings(). This is similar to the info and extra_info for overlay. info has stuff that omapdss doesn't change, it just uses what the user gives. extra_info, on the other hand, has omapdss private stuff that the user does not see. Timings are clearly private stuff in this sense, because they are set via dssdev-set_timings(). One reason for this is the programming model we use. If the user of omapdss does get_info() for two overlays, changes the infos, and then calls set_info() for both overlays and finally apply() for the manager, we don't do any locking there because omapdss presumes the info is handled by one user. If, say, the dpi.c would change the info and call apply at the same time, the configuration could go badly wrong. I think I get your point. So even though get_info() and set_info() fn's are spinlock protected, if there are 2 users setting the info, it doesn't mean that the info they finally written is correct. Is this example the same thing as what you mean ? : In order of time: -user 1 gets an overlay's info -user 2 gets an overlay's info -user 1 modifies and sets overlay info -user 2 sets overlay info without the knowledge of what user 1 did. So even though we ensure these events happen sequentially, we don't protect the info across multiple users. So I think what should be done is to add similar extra flags and code to mgr_priv_data that we have for ovl_priv_data, and add omap_video_timings to mgr_priv_data (the same way as we have, say, fifo_low for ovl_priv_data). And then add similar function to dss_ovl_write_regs_extra() for manager, and a function like dss_apply_ovl_fifo_thresholds() for timings. And finally a non-static function to set the timings (used by dpi.c etc), which calls the similar function to dss_apply_ovl_fifo_thresholds(), and dss_write_regs() and dss_set_go_bits(). Okay, I'll work on it along these lines. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter
On Thu, 2012-04-19 at 11:43 +0530, Archit Taneja wrote: On Wednesday 18 April 2012 08:28 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: DISPC manager size and DISPC manager blanking parameters(for LCD managers) follow the shadow register programming model. Currently, they are programmed directly by the interface drivers. Make timings(omap_video_timing struct) an overlay_manager_info member, they are now programmed via the apply mechanism used for programming shadow registers. The interface driver now call the function dss_mgr_set_timings() which applies the new timing parameters, rather than directly writing to DISPC registers. I don't think that works correctly. The omap_overlay_manager_info is supposed to be set with set_manager_info() by the user of omapdss, to configure the manager's features. The timings are not supposed to be set via that mechanism, but with dssdev-set_timings(). This is similar to the info and extra_info for overlay. info has stuff that omapdss doesn't change, it just uses what the user gives. extra_info, on the other hand, has omapdss private stuff that the user does not see. Timings are clearly private stuff in this sense, because they are set via dssdev-set_timings(). One reason for this is the programming model we use. If the user of omapdss does get_info() for two overlays, changes the infos, and then calls set_info() for both overlays and finally apply() for the manager, we don't do any locking there because omapdss presumes the info is handled by one user. If, say, the dpi.c would change the info and call apply at the same time, the configuration could go badly wrong. I think I get your point. So even though get_info() and set_info() fn's are spinlock protected, if there are 2 users setting the info, it doesn't mean that the info they finally written is correct. Is this example the same thing as what you mean ? : In order of time: -user 1 gets an overlay's info -user 2 gets an overlay's info -user 1 modifies and sets overlay info -user 2 sets overlay info without the knowledge of what user 1 did. So even though we ensure these events happen sequentially, we don't protect the info across multiple users. Yes. The spinlocks ensure that the info is whole, so we don't get a few fields from user1 and a few fields from user2. But they don't protect us from the case you described above. For that we would need a dss lock that the user would acquire before using get_info and set_info. But I don't want to go to that direction, because we really only support one user anyway. The problem in this particular case is that omapdss itself becomes another user if it uses get_info set_info. And that can be easily avoided by splitting the configuration into public (the info) and internal (extra_info). The users of omapdss never touch the extra_info, and omapdss never touches the info. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
Hi Benoît, On Mon, 27 Feb 2012, Paul Walmsley wrote: Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. I took another look at this patch, and upon further thought, there are some aspects of this design that really don't make sense. diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 5b368ee..db4ad41 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -805,6 +805,9 @@ static int _omap4_disable_module(struct omap_hwmod *oh) oh-clkdm-clkdm_offs, oh-prcm.omap4.clkctrl_offs); + if (oh-rst_lines_cnt = 0) + return 0; This change prevents any IP block from waiting for the target to disable -- which is not what we want. The naïve fix would be to only skip the disable-wait if oh-rst_lines_cnt is greater than zero. But if there are no hardreset lines asserted, then we should probably wait for the disable in that case. v = _omap4_wait_target_disable(oh); if (v) pr_warn(omap_hwmod: %s: _wait_target_disable failed\n, [...] @@ -1575,7 +1568,19 @@ static int _enable(struct omap_hwmod *oh) _enable_clocks(oh); _enable_module(oh); - r = _wait_target_ready(oh); + /* + * If an IP contains HW reset lines, we leave them + * asserted. But this will block the module's idle state + * transition - the PRCM will return Intransition status. So + * we need to avoid the target ready-wait in this case. XXX + * We also need to give the drivers a way to wait for the + * target to become ready once they decide to deassert some + * hardreset lines. XXX Is this strategy going to break PM + * because the clockdomain may not be able to enter idle while + * the module's idle status is in-transition? We may just need + * custom reset blocks for all IPs with hardreset lines. + */ + r = (oh-rst_lines_cnt == 0) ? _wait_target_ready(oh) : 1; And this part is at odds with the patch description. If there are hardreset lines associated with an IP block, then this code will cause the following code to unconditionally disable the module clocks. Considering that this is the _enable() function, this seems counterproductive. I looked into changing this code to align with the original semantics we discussed. It seems quite challenging. With the current codebase, we'd have to bail out in the middle of the enable sequence. Then we'd lose the clockdomain state (the 'hwsup' variable). So I've updated the patch to essentially bail out early from all hwmod enable, idle, and shutdown code, if any hardreset lines associated with the IP block are asserted. It will then be the driver integration code's responsibility for enabling the IP block when the hardreset lines are asserted. When the hardreset lines are deasserted, the usual hwmod code will be executed -- I'd assume this would be the case during normal operation of the device. I think this is probably the best we can do until we actually hear back from the people responsible for drivers for these special IP blocks. A revised patch is below. Care to take a look and see if it makes sense to you? regards, - Paul From: Paul Walmsley p...@pwsan.com Date: Wed, 18 Apr 2012 19:10:04 -0600 Subject: [PATCH] ARM: OMAP2+: hwmod: revise hardreset behavior Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. The semantics implemented by this patch are as follows: - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all associated hardreset lines during IP block setup. This is intended to place the IP blocks into a known state that will not interfere with other devices during kernel boot. - IP blocks with hardreset lines
Re: [PATCH] OMAP4: Adding ID for OMAP4460 ES1.1
Hi,
On 04/18/2012 07:50 PM, Tony Lindgren wrote:
Hi,
* Roger Quadros rog...@ti.com [120403 02:50]:
Hi Tony,
Could you please take this patch for the next merge? Thanks.
Yes, it seems that this is not needed as a fix for the -rc cycle?
Right, it is not needed for this -rc cycle.
If it's needed as a fix, please let me know and also describe
what breaks.
It does not fix anything but is just for the sake of correctness.
regards,
-roger
On 04/02/2012 11:59 AM, Roger Quadros wrote:
From: Chris Lalancette clalance...@gmail.com
Signed-off-by: Chris Lalancette clalance...@gmail.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/id.c |5 -
arch/arm/plat-omap/include/plat/cpu.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..f139817 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -478,9 +478,12 @@ void __init omap4xxx_check_revision(void)
case 0xb94e:
switch (rev) {
case 0:
- default:
omap_revision = OMAP4460_REV_ES1_0;
break;
+ case 2:
+ default:
+ omap_revision = OMAP4460_REV_ES1_1;
+ break;
}
break;
case 0xb975:
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index dc6a86b..4bdf14e 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -445,6 +445,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP446X_CLASS 0x44600044
#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8))
+#define OMAP4460_REV_ES1_1 (OMAP446X_CLASS | (0x11 8))
#define OMAP447X_CLASS 0x44700044
#define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 8))
--
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: AM3517 boot failure
On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? Thanks -- Regards, Igor. -- 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 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process
Hi
On Mon, 27 Feb 2012, Paul Walmsley wrote:
Reorganize the code involved in initializing and configuring an IP
block to make it easier to read and maintain. This involves improving
documentation, splitting some large functions up into smaller ones to
better conform with Documentation/CodingStyle, and removing some
unnecessary code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
A few changes have been made to this patch:
- The reset changes have been consolidated with the changes in patch 5.
- The changes to the _init function have been split into a separate patch
to make it easier to debug.
The updated patch follows.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Wed, 18 Apr 2012 19:10:03 -0600
Subject: [PATCH 3/3] ARM: OMAP2+: hwmod: reorganize and document the reset
and configuration process
Reorganize the code involved in resetting and configuring an IP block
to make it easier to read and maintain. This involves improving
documentation, splitting some large functions up into smaller ones to
better conform with Documentation/CodingStyle, and removing some
unnecessary code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 152 ++
1 file changed, 120 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 253e942..0afbebc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1534,10 +1534,9 @@ static int _enable(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: enabling\n, oh-name);
/*
-* hwmods with HWMOD_INIT_NO_IDLE flag set are left
-* in enabled state at init.
-* Now that someone is really trying to enable them,
-* just ensure that the hwmod mux is set.
+* hwmods with HWMOD_INIT_NO_IDLE flag set are left in enabled
+* state at init. Now that someone is really trying to enable
+* them, just ensure that the hwmod mux is set.
*/
if (oh-_int_flags _HWMOD_SKIP_ENABLE) {
/*
@@ -1819,46 +1818,60 @@ static int __init _init(struct omap_hwmod *oh, void *n)
}
/**
- * _setup - do initial configuration of omap_hwmod
+ * _setup_iclk_autoidle - configure an IP block's interface clocks
* @oh: struct omap_hwmod *
*
- * Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register. Returns 0.
+ * Set up the module's interface clocks. XXX This function is still mostly
+ * a stub; implementing this properly requires iclk autoidle usecounting in
+ * the clock code. No return value.
*/
-static int _setup(struct omap_hwmod *oh, void *data)
+static void __init _setup_iclk_autoidle(struct omap_hwmod *oh)
{
- int i, r;
- u8 postsetup_state;
+ int i;
if (oh-_state != _HWMOD_STATE_INITIALIZED)
- return 0;
+ return;
- /* Set iclk autoidle mode */
- if (oh-slaves_cnt 0) {
- for (i = 0; i oh-slaves_cnt; i++) {
- struct omap_hwmod_ocp_if *os = oh-slaves[i];
- struct clk *c = os-_clk;
+ for (i = 0; i oh-slaves_cnt; i++) {
+ struct omap_hwmod_ocp_if *os = oh-slaves[i];
+ struct clk *c = os-_clk;
- if (!c)
- continue;
+ if (!c)
+ continue;
- if (os-flags OCPIF_SWSUP_IDLE) {
- /* XXX omap_iclk_deny_idle(c); */
- } else {
- /* XXX omap_iclk_allow_idle(c); */
- clk_enable(c);
- }
+ if (os-flags OCPIF_SWSUP_IDLE) {
+ /* XXX omap_iclk_deny_idle(c); */
+ } else {
+ /* XXX omap_iclk_allow_idle(c); */
+ clk_enable(c);
}
}
- oh-_state = _HWMOD_STATE_INITIALIZED;
+ return;
+}
+
+/**
+ * _setup_reset - reset an IP block during the setup process
+ * @oh: struct omap_hwmod *
+ *
+ * Reset the IP block corresponding to the hwmod @oh during the setup
+ * process. The IP block is first enabled so it can be successfully
+ * reset. Returns 0 upon success or a negative error code upon
+ * failure.
+ */
+static int __init _setup_reset(struct omap_hwmod *oh)
+{
+ int r;
+
+ if (oh-_state != _HWMOD_STATE_INITIALIZED)
+ return -EINVAL;
/*
* In the case of hwmod with hardreset that should not be
* de-assert at boot time, we have to keep the module
* initialized, because we cannot enable it properly with the
-* reset asserted. Exit without warning because that behavior is
-* expected.
+* reset asserted. Exit without warning because
Re: [PATCH v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process
Hi
On Thu, 19 Apr 2012, Paul Walmsley wrote:
- The changes to the _init function have been split into a separate patch
to make it easier to debug.
Here is the patch that deals specifically with _init(). It's the same
code that was originally part of the patch mentioned in the subject line,
split into a new patch for clarity.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Thu, 19 Apr 2012 00:58:22 -0600
Subject: [PATCH 2/3] ARM: OMAP2+: hwmod: reorganize and document the
initialization process
Reorganize the code involved in initializing the internal data for
each hwmod to make it easier to read and maintain. This involves
improving documentation and removing some duplicated and unnecessary
code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 137 ++
1 file changed, 80 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5b07ad0..253e942 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1769,6 +1769,56 @@ static int _shutdown(struct omap_hwmod *oh)
}
/**
+ * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * @oh: struct omap_hwmod * to locate the virtual address
+ *
+ * Cache the virtual address used by the MPU to access this IP block's
+ * registers. This address is needed early so the OCP registers that
+ * are part of the device's address space can be ioremapped properly.
+ * No return value.
+ */
+static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
+{
+ if (oh-_int_flags _HWMOD_NO_MPU_PORT)
+ return;
+
+ oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
+}
+
+/**
+ * _init - initialize internal data for the hwmod @oh
+ * @oh: struct omap_hwmod *
+ * @n: (unused)
+ *
+ * Look up the clocks and the address space used by the MPU to access
+ * registers belonging to the hwmod @oh. @oh must already be
+ * registered at this point. This is the first of two phases for
+ * hwmod initialization. Code called here does not touch any hardware
+ * registers, it simply prepares internal data structures. Returns 0
+ * upon success or if the hwmod isn't registered, or -EINVAL upon
+ * failure.
+ */
+static int __init _init(struct omap_hwmod *oh, void *n)
+{
+ int r;
+
+ if (oh-_state != _HWMOD_STATE_REGISTERED)
+ return 0;
+
+ _init_mpu_rt_base(oh, NULL);
+
+ r = _init_clocks(oh, NULL);
+ if (IS_ERR_VALUE(r)) {
+ WARN(1, omap_hwmod: %s: couldn't init clocks\n, oh-name);
+ return -EINVAL;
+ }
+
+ oh-_state = _HWMOD_STATE_INITIALIZED;
+
+ return 0;
+}
+
+/**
* _setup - do initial configuration of omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1780,7 +1830,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
int i, r;
u8 postsetup_state;
- if (oh-_state != _HWMOD_STATE_CLKS_INITED)
+ if (oh-_state != _HWMOD_STATE_INITIALIZED)
return 0;
/* Set iclk autoidle mode */
@@ -2052,96 +2102,69 @@ int __init omap_hwmod_register(struct omap_hwmod **ohs)
return 0;
}
-/*
- * _populate_mpu_rt_base - populate the virtual address for a hwmod
+/**
+ * _ensure_mpu_hwmod_is_setup - ensure the MPU SS hwmod is init'ed and set up
+ * @oh: pointer to the hwmod currently being set up (usually not the MPU)
*
- * Must be called only from omap_hwmod_setup_*() so ioremap works properly.
- * Assumes the caller takes care of locking if needed.
+ * If the hwmod data corresponding to the MPU subsystem IP block
+ * hasn't been initialized and set up yet, do so now. This must be
+ * done first since sleep dependencies may be added from other hwmods
+ * to the MPU. Intended to be called only by omap_hwmod_setup*(). No
+ * return value.
*/
-static int __init _populate_mpu_rt_base(struct omap_hwmod *oh, void *data)
+static void __init _ensure_mpu_hwmod_is_setup(struct omap_hwmod *oh)
{
- if (oh-_state != _HWMOD_STATE_REGISTERED)
- return 0;
-
- if (oh-_int_flags _HWMOD_NO_MPU_PORT)
- return 0;
-
- oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
-
- return 0;
+ if (!mpu_oh || mpu_oh-_state == _HWMOD_STATE_UNKNOWN)
+ pr_err(omap_hwmod: %s: MPU initiator hwmod %s not yet
registered\n,
+ __func__, MPU_INITIATOR_NAME);
+ else if (mpu_oh-_state == _HWMOD_STATE_REGISTERED oh != mpu_oh)
+ omap_hwmod_setup_one(MPU_INITIATOR_NAME);
}
/**
* omap_hwmod_setup_one - set up a single hwmod
* @oh_name: const char * name of the already-registered hwmod to set up
*
- * Must be called after omap2_clk_init(). Resolves the struct clk
- * names to struct clk pointers for each registered omap_hwmod. Also
- * calls _setup() on each hwmod. Returns -EINVAL upon error or
Re: [PATCH v2 5/8] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset
Hi
On Mon, 27 Feb 2012, Paul Walmsley wrote:
Move the code that reprograms the OCP_SYSCONFIG bits into the _reset()
function to ensure that it is called after every reset. The code was
previously in the _setup() function. So, before this patch, if
_reset() was called from another function, the SYSCONFIG register
won't be reprogrammed.
As mentioned earlier, the _reset() changes previously in patch 3 have been
rolled into this patch, as follows.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Thu, 19 Apr 2012 00:49:09 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod: revise the IP block reset process
Revise the IP block reset process. This patch ensures that the
OCP_SYSCONFIG registers are reloaded after a custom reset. Since
OCP_SYSCONFIG bits are cleared during reset, they should be
reprogrammed unless the IP block is being left in reset. (The only IP
blocks that are left in reset are IP blocks with hardreset lines and
no custom reset function.) If the IP block is left in reset, then it
is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
register will cause an abort.
This version incorporates comments from Omar Ramirez Luna
omar.rami...@ti.com to skip the OCP_SYSCONFIG access after asserting
hardreset lines. This allows the MMU (IOMMU) IP block, which has
both hardreset lines and an OCP_SYSCONFIG register.
Also, ignore _ocp_softreset() errors if the IP block doesn't include a
softreset bit. This is needed since a subsequent patch will start
taking the return value of the _reset() function seriously.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 69 +-
1 file changed, 46 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4997c1a..5b07ad0 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2,7 +2,7 @@
* omap_hwmod implementation for OMAP2/3/4
*
* Copyright (C) 2009-2011 Nokia Corporation
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
*
* Paul Walmsley, Benoît Cousson, Kevin Hilman
*
@@ -1382,9 +1382,9 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
* @oh: struct omap_hwmod *
*
* Resets an omap_hwmod @oh via the OCP_SYSCONFIG bit. hwmod must be
- * enabled for this to work. Returns -EINVAL if the hwmod cannot be
- * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
- * the module did not reset in time, or 0 upon success.
+ * enabled for this to work. Returns -ENOENT if the hwmod cannot be
+ * reset this way, -EINVAL if the hwmod is in the wrong state,
+ * -ETIMEDOUT if the module did not reset in time, or 0 upon success.
*
* In OMAP3 a specific SYSSTATUS register is used to get the reset status.
* Starting in OMAP4, some IPs do not have SYSSTATUS registers and instead
@@ -1401,7 +1401,7 @@ static int _ocp_softreset(struct omap_hwmod *oh)
if (!oh-class-sysc ||
!(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET))
- return -EINVAL;
+ return -ENOENT;
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
@@ -1462,37 +1462,60 @@ dis_opt_clks:
* _reset - reset an omap_hwmod
* @oh: struct omap_hwmod *
*
- * Resets an omap_hwmod @oh. The default software reset mechanism for
- * most OMAP IP blocks is triggered via the OCP_SYSCONFIG.SOFTRESET
- * bit. However, some hwmods cannot be reset via this method: some
- * are not targets and therefore have no OCP header registers to
- * access; others (like the IVA) have idiosyncratic reset sequences.
- * So for these relatively rare cases, custom reset code can be
- * supplied in the struct omap_hwmod_class .reset function pointer.
- * Passes along the return value from either _reset() or the custom
- * reset function - these must return -EINVAL if the hwmod cannot be
- * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
- * the module did not reset in time, or 0 upon success.
+ * Resets an omap_hwmod @oh. If the module has a custom reset
+ * function pointer defined, then call it to reset the IP block, and
+ * pass along its return value to the caller. Otherwise, if the IP
+ * block has an OCP_SYSCONFIG register with a SOFTRESET bitfield
+ * associated with it, call a function to reset the IP block via that
+ * method, and pass along the return value to the caller. Finally, if
+ * the IP block has some hardreset lines associated with it, assert
+ * all of those, but do _not_ deassert them. (This is because driver
+ * authors have expressed an apparent requirement to control the
+ * deassertion of the hardreset lines themselves.)
+ *
+ * The default software reset mechanism for most OMAP IP blocks is
+ * triggered via the OCP_SYSCONFIG.SOFTRESET bit.
Re: [PATCH v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process
Hi Paul,
On 4/19/2012 10:17 AM, Paul Walmsley wrote:
...
static int __init omap_hwmod_setup_all(void)
{
- int r;
-
- if (!mpu_oh) {
- pr_err(omap_hwmod: %s: MPU initiator hwmod %s not yet
registered\n,
- __func__, MPU_INITIATOR_NAME);
- return -EINVAL;
- }
-
- r = omap_hwmod_for_each(_populate_mpu_rt_base, NULL);
-
- r = omap_hwmod_for_each(_init_clocks, NULL);
- WARN(IS_ERR_VALUE(r),
-omap_hwmod: %s: _init_clocks failed\n, __func__);
+ _ensure_mpu_hwmod_is_setup(NULL);
+ omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
Does it make sense to iterate twice? Cannot we just iterate over a _init
+ _setup single call?
Regards,
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 12/12] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
Hi
On Wed, 7 Mar 2012, Paul Walmsley wrote:
N800 logs this message on boot:
[0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430. There is still more information to be added, but
this should resolve the immediate issue.
Signed-off-by: Paul Walmsley p...@pwsan.com
Tony tested this on his 2430SDP while my board was down and discovered
that it didn't boot on that platform. Turns out that one of the hwmods
was using an incorrect clock name. Fixed in the updated patch, below.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Thu, 19 Apr 2012 03:00:02 -0600
Subject: [PATCH] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and
DSP
N800 logs this message on boot:
[0.182281] omap_hwmod: iva: cannot be enabled for reset (3)
Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430. There is still more information to be added, but
this should resolve the immediate issue.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 46 ++--
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 ++-
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b01b66a..2c087ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -43,10 +43,41 @@
* IP blocks
*/
-/* IVA2 (IVA2) */
+/* IVA1 (IVA1) */
+static struct omap_hwmod_class iva1_hwmod_class = {
+ .name = iva1,
+};
+
+static struct omap_hwmod_rst_info omap2420_iva_resets[] = {
+ { .name = iva, .rst_shift = 8 },
+};
+
static struct omap_hwmod omap2420_iva_hwmod = {
.name = iva,
- .class = iva_hwmod_class,
+ .class = iva1_hwmod_class,
+ .clkdm_name = iva1_clkdm,
+ .rst_lines = omap2420_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2420_iva_resets),
+ .main_clk = iva1_ifck,
+};
+
+/* DSP */
+static struct omap_hwmod_class dsp_hwmod_class = {
+ .name = dsp,
+};
+
+static struct omap_hwmod_rst_info omap2420_dsp_resets[] = {
+ { .name = logic, .rst_shift = 0 },
+ { .name = mmu, .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap2420_dsp_hwmod = {
+ .name = dsp,
+ .class = dsp_hwmod_class,
+ .clkdm_name = dsp_clkdm,
+ .rst_lines = omap2420_dsp_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2420_dsp_resets),
+ .main_clk = dsp_fck,
};
/* I2C common */
@@ -234,7 +265,15 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__i2c2 = {
static struct omap_hwmod_ocp_if omap2420_l3__iva = {
.master = omap2xxx_l3_main_hwmod,
.slave = omap2420_iva_hwmod,
- .clk= iva1_ifck,
+ .clk= core_l3_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* DSP - L3 interface */
+static struct omap_hwmod_ocp_if omap2420_l3__dsp = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2420_dsp_hwmod,
+ .clk= dsp_ick,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -402,6 +441,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__i2c1,
omap2420_l4_core__i2c2,
omap2420_l3__iva,
+ omap2420_l3__dsp,
omap2420_l4_wkup__timer1,
omap2xxx_l4_core__timer2,
omap2xxx_l4_core__timer3,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 23ca551..71d9f88 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -45,9 +45,18 @@
*/
/* IVA2 (IVA2) */
+static struct omap_hwmod_rst_info omap2430_iva_resets[] = {
+ { .name = logic, .rst_shift = 0 },
+ { .name = mmu, .rst_shift = 1 },
+};
+
static struct omap_hwmod omap2430_iva_hwmod = {
.name = iva,
.class = iva_hwmod_class,
+ .clkdm_name = dsp_clkdm,
+ .rst_lines = omap2430_iva_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap2430_iva_resets),
+ .main_clk = dsp_fck,
};
/* I2C common */
@@ -599,7 +608,7 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi3 = {
static struct omap_hwmod_ocp_if omap2430_l3__iva = {
.master = omap2xxx_l3_main_hwmod,
.slave = omap2430_iva_hwmod,
- .clk= dsp_fck,
+ .clk= core_l3_ck,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
On Thu, Apr 19, 2012 at 03:18:27AM -0600, Paul Walmsley wrote: N800 logs this message on boot: [0.182281] omap_hwmod: iva: cannot be enabled for reset (3) Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2 hwmod for OMAP2430. There is still more information to be added, but this should resolve the immediate issue. FYI, I'm also seeing omap_hwmod errors on boot: 3430ldp: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=133 omap_hwmod: i2c1: softreset failed (waited 1 usec) omap_hwmod: i2c2: softreset failed (waited 1 usec) omap_hwmod: i2c3: softreset failed (waited 1 usec) 4430sdp: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=134 omap_hwmod: i2c1: softreset failed (waited 1 usec) omap_hwmod: i2c2: softreset failed (waited 1 usec) omap_hwmod: i2c3: softreset failed (waited 1 usec) omap_hwmod: i2c4: softreset failed (waited 1 usec) omap_hwmod: ipu: failed to hardreset -- 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] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
On Wed, Apr 18, 2012 at 01:43:46PM +0530, Archit Taneja wrote: On Wednesday 18 April 2012 01:36 PM, Tomi Valkeinen wrote: Hi, On Mon, 2012-04-09 at 12:41 +0530, Archit Taneja wrote: This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Are we sure the bits are the same for all OMAP4 versions? I'm just wondering why the change was made to TRM... I've tried on OMAP4430 ES2.1 and OMAP4460 ES1.1. I can try on a couple more revisions. As far as why the change was made in the TRM, it's a bit hard to find the right people, or get response from them :), I'll give that a try again. If we do conclude that this revert patch is needed, it might probably be a candidate for the 3.2 and 3.3 stable kernels, just wanted to point that out. I was just going to ask about this, as I haven't noticed any improvement in mainline kernels since I reported the original failure... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
On Thu, 19 Apr 2012, Russell King - ARM Linux wrote: FYI, I'm also seeing omap_hwmod errors on boot: 3430ldp: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=133 omap_hwmod: i2c1: softreset failed (waited 1 usec) omap_hwmod: i2c2: softreset failed (waited 1 usec) omap_hwmod: i2c3: softreset failed (waited 1 usec) 4430sdp: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=134 omap_hwmod: i2c1: softreset failed (waited 1 usec) omap_hwmod: i2c2: softreset failed (waited 1 usec) omap_hwmod: i2c3: softreset failed (waited 1 usec) omap_hwmod: i2c4: softreset failed (waited 1 usec) omap_hwmod: ipu: failed to hardreset Thanks for the report. Those should be resolved by: ARM: OMAP2+: hwmod: Revert ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status which was sent upstream to Tony as part of http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=commit;h=3c55c1baffa5f719eb2ae9729088bc867f972f53 Hopefully it will go into the next v3.4-rc kernel. - 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 12/12] ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP
On Thu, 19 Apr 2012, Paul Walmsley wrote: Thanks for the report. Those should be resolved by: ARM: OMAP2+: hwmod: Revert ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status which was sent upstream to Tony as part of http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=commit;h=3c55c1baffa5f719eb2ae9729088bc867f972f53 Sorry about that, meant to send a link to the tag: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=bb3fbe167596650383f423e0a495971086e5c069 - 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 v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process
Hi Benoît,
On Thu, 19 Apr 2012, Cousson, Benoit wrote:
On 4/19/2012 10:17 AM, Paul Walmsley wrote:
static int __init omap_hwmod_setup_all(void)
{
- int r;
-
- if (!mpu_oh) {
- pr_err(omap_hwmod: %s: MPU initiator hwmod %s not yet
registered\n,
- __func__, MPU_INITIATOR_NAME);
- return -EINVAL;
- }
-
- r = omap_hwmod_for_each(_populate_mpu_rt_base, NULL);
-
- r = omap_hwmod_for_each(_init_clocks, NULL);
- WARN(IS_ERR_VALUE(r),
-omap_hwmod: %s: _init_clocks failed\n, __func__);
+ _ensure_mpu_hwmod_is_setup(NULL);
+ omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
Does it make sense to iterate twice? Cannot we just iterate over a _init +
_setup single call?
It's a good idea but I don't think we can do that until we add the code to
walk the hwmod data in dependency order. The DSS custom reset function
accesses registers in another hwmod, which won't have its clocks
initialized yet if _init() and setup() are combined.
- Paul
Re: [PATCH 4/6] OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter
On Thursday 19 April 2012 12:07 PM, Tomi Valkeinen wrote: On Thu, 2012-04-19 at 11:43 +0530, Archit Taneja wrote: On Wednesday 18 April 2012 08:28 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: DISPC manager size and DISPC manager blanking parameters(for LCD managers) follow the shadow register programming model. Currently, they are programmed directly by the interface drivers. Make timings(omap_video_timing struct) an overlay_manager_info member, they are now programmed via the apply mechanism used for programming shadow registers. The interface driver now call the function dss_mgr_set_timings() which applies the new timing parameters, rather than directly writing to DISPC registers. I don't think that works correctly. The omap_overlay_manager_info is supposed to be set with set_manager_info() by the user of omapdss, to configure the manager's features. The timings are not supposed to be set via that mechanism, but with dssdev-set_timings(). This is similar to the info and extra_info for overlay. info has stuff that omapdss doesn't change, it just uses what the user gives. extra_info, on the other hand, has omapdss private stuff that the user does not see. Timings are clearly private stuff in this sense, because they are set via dssdev-set_timings(). One reason for this is the programming model we use. If the user of omapdss does get_info() for two overlays, changes the infos, and then calls set_info() for both overlays and finally apply() for the manager, we don't do any locking there because omapdss presumes the info is handled by one user. If, say, the dpi.c would change the info and call apply at the same time, the configuration could go badly wrong. I think I get your point. So even though get_info() and set_info() fn's are spinlock protected, if there are 2 users setting the info, it doesn't mean that the info they finally written is correct. Is this example the same thing as what you mean ? : In order of time: -user 1 gets an overlay's info -user 2 gets an overlay's info -user 1 modifies and sets overlay info -user 2 sets overlay info without the knowledge of what user 1 did. So even though we ensure these events happen sequentially, we don't protect the info across multiple users. Yes. The spinlocks ensure that the info is whole, so we don't get a few fields from user1 and a few fields from user2. But they don't protect us from the case you described above. For that we would need a dss lock that the user would acquire before using get_info and set_info. But I don't want to go to that direction, because we really only support one user anyway. The problem in this particular case is that omapdss itself becomes another user if it uses get_info set_info. And that can be easily avoided by splitting the configuration into public (the info) and internal (extra_info). The users of omapdss never touch the extra_info, and omapdss never touches the info. omapdss touches info via sysfs, so if we use sysfs(in a fast way, using a it in scripts, for example) while fb uses DSS2, then we might hit this issue. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: cm-t35: add support for power off
ping!
Tony, can this please, go into 3.5?
On 03/28/12 11:51, Igor Grinberg wrote:
Enable the power off feature of the TPS65930 on-board PMIC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 8770be1..46275c6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -499,6 +499,10 @@ static struct twl4030_gpio_platform_data
cm_t35_gpio_data = {
.setup = cm_t35_twl_gpio_setup,
};
+static struct twl4030_power_data cm_t35_power_data = {
+ .use_poweroff = true,
+};
+
static struct twl4030_platform_data cm_t35_twldata = {
/* platform_data for children goes here */
.keypad = cm_t35_kp_data,
@@ -506,6 +510,7 @@ static struct twl4030_platform_data cm_t35_twldata = {
.vmmc1 = cm_t35_vmmc1,
.vsim = cm_t35_vsim,
.vio= cm_t35_vio,
+ .power = cm_t35_power_data,
};
static void __init cm_t35_init_i2c(void)
--
Regards,
Igor.
--
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] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
On Thu, 2012-04-19 at 10:31 +0100, Russell King - ARM Linux wrote: On Wed, Apr 18, 2012 at 01:43:46PM +0530, Archit Taneja wrote: On Wednesday 18 April 2012 01:36 PM, Tomi Valkeinen wrote: Hi, On Mon, 2012-04-09 at 12:41 +0530, Archit Taneja wrote: This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Are we sure the bits are the same for all OMAP4 versions? I'm just wondering why the change was made to TRM... I've tried on OMAP4430 ES2.1 and OMAP4460 ES1.1. I can try on a couple more revisions. As far as why the change was made in the TRM, it's a bit hard to find the right people, or get response from them :), I'll give that a try again. If we do conclude that this revert patch is needed, it might probably be a candidate for the 3.2 and 3.3 stable kernels, just wanted to point that out. I was just going to ask about this, as I haven't noticed any improvement in mainline kernels since I reported the original failure... It seems to be very difficult to find out why the TRM change was done, and what the HW actually does. But as the boards out there are clearly fixed by reverting the original patch, I think it's best if we just apply the revert. Archit, can you resend the patch with my ack, and cc sta...@vger.kernel.org (see Documentation/stable_kernel_rules.txt). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv2] Input: omap-keypad: dynamically handle register offsets
Hi Dmitry,
Any comments on this?
~Sourav
On Thu, Apr 12, 2012 at 1:08 PM, Sourav Poddar sourav.pod...@ti.com wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc2.
Tested on omap5430evm with 3.1-custom kernel.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1:
- Fix Felipe's comment about getting rid
of one argument from irqstatus/irqenable api
- Fix Dmitry's comment:
- get rid of revision check in readl/writel
- Relace ENODEV with proper macro.
- Use switch statement
drivers/input/keyboard/Kconfig | 6 +-
drivers/input/keyboard/omap4-keypad.c | 115
++---
2 files changed, 95 insertions(+), 26 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..9a0e1a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -511,10 +511,10 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..8e46563 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,6 +68,11 @@
#define OMAP4_MASK_IRQSTATUSDISABLE 0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
@@ -76,11 +81,61 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
+ u32 reg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base + offset);
+}
+
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base +
keypad_data-irqstatus);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base +
keypad_data-irqenable);
+}
+
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32
value)
+{
+ __raw_writel(value, keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -EINVAL;
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +146,10 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
- keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +174,12 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base +
Re: [PATCH 4/6] OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter
On Thu, 2012-04-19 at 15:38 +0530, Archit Taneja wrote: On Thursday 19 April 2012 12:07 PM, Tomi Valkeinen wrote: On Thu, 2012-04-19 at 11:43 +0530, Archit Taneja wrote: On Wednesday 18 April 2012 08:28 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: DISPC manager size and DISPC manager blanking parameters(for LCD managers) follow the shadow register programming model. Currently, they are programmed directly by the interface drivers. Make timings(omap_video_timing struct) an overlay_manager_info member, they are now programmed via the apply mechanism used for programming shadow registers. The interface driver now call the function dss_mgr_set_timings() which applies the new timing parameters, rather than directly writing to DISPC registers. I don't think that works correctly. The omap_overlay_manager_info is supposed to be set with set_manager_info() by the user of omapdss, to configure the manager's features. The timings are not supposed to be set via that mechanism, but with dssdev-set_timings(). This is similar to the info and extra_info for overlay. info has stuff that omapdss doesn't change, it just uses what the user gives. extra_info, on the other hand, has omapdss private stuff that the user does not see. Timings are clearly private stuff in this sense, because they are set via dssdev-set_timings(). One reason for this is the programming model we use. If the user of omapdss does get_info() for two overlays, changes the infos, and then calls set_info() for both overlays and finally apply() for the manager, we don't do any locking there because omapdss presumes the info is handled by one user. If, say, the dpi.c would change the info and call apply at the same time, the configuration could go badly wrong. I think I get your point. So even though get_info() and set_info() fn's are spinlock protected, if there are 2 users setting the info, it doesn't mean that the info they finally written is correct. Is this example the same thing as what you mean ? : In order of time: -user 1 gets an overlay's info -user 2 gets an overlay's info -user 1 modifies and sets overlay info -user 2 sets overlay info without the knowledge of what user 1 did. So even though we ensure these events happen sequentially, we don't protect the info across multiple users. Yes. The spinlocks ensure that the info is whole, so we don't get a few fields from user1 and a few fields from user2. But they don't protect us from the case you described above. For that we would need a dss lock that the user would acquire before using get_info and set_info. But I don't want to go to that direction, because we really only support one user anyway. The problem in this particular case is that omapdss itself becomes another user if it uses get_info set_info. And that can be easily avoided by splitting the configuration into public (the info) and internal (extra_info). The users of omapdss never touch the extra_info, and omapdss never touches the info. omapdss touches info via sysfs, so if we use sysfs(in a fast way, using a it in scripts, for example) while fb uses DSS2, then we might hit this issue. The sysfs calls come from the user, so in that sense it's not omapdss that is doing the change. But it's true that with sysfs we may have two users for omapdss, for example the scripts using sysfs and omapfb. Hopefully we can deprecate the sysfs files at some point... Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/6] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings a manager_info parameter. The interface drivers now set the timings in manager_info instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Archit Taneja (6): OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size OMAPDSS: DISPC: Use a common function to set manager timings OMAPDSS: DISPC: Clean up manager timing/size functions OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter OMAPDSS: MANAGER: Check validity of manager timings OMAPDSS: APPLY: Remove display dependency from overlay and manager checks The patches 1, 2 and 3 in this series look like independent cleanups. Should I apply those, or do you think there may be changes required? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/6] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Thursday 19 April 2012 05:18 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings a manager_info parameter. The interface drivers now set the timings in manager_info instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Archit Taneja (6): OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size OMAPDSS: DISPC: Use a common function to set manager timings OMAPDSS: DISPC: Clean up manager timing/size functions OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter OMAPDSS: MANAGER: Check validity of manager timings OMAPDSS: APPLY: Remove display dependency from overlay and manager checks The patches 1, 2 and 3 in this series look like independent cleanups. Should I apply those, or do you think there may be changes required? I think you can pull these 3, they were sort of a prerequisite for the apply-manager-timings stuff. I don't think they need to change. I'll post another series for applying the manager timings correctly(i.e, the fixed version of the last 3 patches). Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
On Thu, 2012-04-19 at 17:28 +0530, Archit Taneja wrote: On Thursday 19 April 2012 05:18 PM, Tomi Valkeinen wrote: On Mon, 2012-04-16 at 12:53 +0530, Archit Taneja wrote: An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings a manager_info parameter. The interface drivers now set the timings in manager_info instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Archit Taneja (6): OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size OMAPDSS: DISPC: Use a common function to set manager timings OMAPDSS: DISPC: Clean up manager timing/size functions OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter OMAPDSS: MANAGER: Check validity of manager timings OMAPDSS: APPLY: Remove display dependency from overlay and manager checks The patches 1, 2 and 3 in this series look like independent cleanups. Should I apply those, or do you think there may be changes required? I think you can pull these 3, they were sort of a prerequisite for the apply-manager-timings stuff. I don't think they need to change. I'll post another series for applying the manager timings correctly(i.e, the fixed version of the last 3 patches). Ok, I applied the first three patches to my dev branch. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process
On 4/19/2012 11:49 AM, Paul Walmsley wrote:
Hi Benoît,
On Thu, 19 Apr 2012, Cousson, Benoit wrote:
On 4/19/2012 10:17 AM, Paul Walmsley wrote:
static int __init omap_hwmod_setup_all(void)
{
- int r;
-
- if (!mpu_oh) {
- pr_err(omap_hwmod: %s: MPU initiator hwmod %s not yet
registered\n,
- __func__, MPU_INITIATOR_NAME);
- return -EINVAL;
- }
-
- r = omap_hwmod_for_each(_populate_mpu_rt_base, NULL);
-
- r = omap_hwmod_for_each(_init_clocks, NULL);
- WARN(IS_ERR_VALUE(r),
-omap_hwmod: %s: _init_clocks failed\n, __func__);
+ _ensure_mpu_hwmod_is_setup(NULL);
+ omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
Does it make sense to iterate twice? Cannot we just iterate over a _init +
_setup single call?
It's a good idea but I don't think we can do that until we add the code to
walk the hwmod data in dependency order. The DSS custom reset function
accesses registers in another hwmod, which won't have its clocks
initialized yet if _init() and setup() are combined.
Outch, that's unfortunate!
I'm wondering if the whole automatic reset management at hwmod level
does make sense for such IP.
In the case of the DSS, having some reset support in the driver model
should allow potentially a reset done at parent level to be broadcasted
to every children.
Regards,
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 v2 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
+ Omar and Ohad, Salut Paul, On 4/19/2012 8:53 AM, Paul Walmsley wrote: Hi Benoît, On Mon, 27 Feb 2012, Paul Walmsley wrote: Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. I took another look at this patch, and upon further thought, there are some aspects of this design that really don't make sense. That's perfect timing, because I was struggling with some hardreset issue on OMAP5 yesterday, so I thought as well about that patch. This is just some more thoughts on that topic more than a pure comment on this patch :-) What I realized is that the main issue was due to the fake hwmods to control processor reset lines. So these one has to be removed, it was clearly a mistake. The other issue was due to the wrong association between the reset lines and the hwmod. In fact I was trying to create ipu dsp hwmods, whereas these subsystem do not have any direct connection with the main interconnect but only through their MMU. This is exactly what Omar raised when he tried to introduce the MMU hwmods. And in fact the new name used in OMAP5 are highlight that a little bit netter than on OMAP4 'ipu': 'rst_cpu0' 'rst_cpu1' 'rst_ipu_mmu_cache' 'dsp': 'rst_dsp' 'rst_dsp_mmu_cache' 'iva': 'rst_seq1' 'rst_seq2' 'rst_logic' The concern of the people doing SW in these embedded processors was mainly because we were releasing the reset of processor without loading any SW first and thus the processor was executing some random instructions. So if we consider a better hwmods definition, we can potentially fix the MMU case: 'mmu_ipu': 'rst_ipu_mmu_cache' 'mmu_dsp': 'rst_dsp_mmu_cache' 'iva_config': 'rst_logic' But then we do have the processor resets that have to be exposed somewhere. 'ipu': 'rst_cpu0' 'rst_cpu1' 'dsp': 'rst_dsp' 'iva': 'rst_seq1' 'rst_seq2' None of these one should be controlled automatically. diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 5b368ee..db4ad41 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -805,6 +805,9 @@ static int _omap4_disable_module(struct omap_hwmod *oh) oh-clkdm-clkdm_offs, oh-prcm.omap4.clkctrl_offs); + if (oh-rst_lines_cnt= 0) + return 0; This change prevents any IP block from waiting for the target to disable -- which is not what we want. The naïve fix would be to only skip the disable-wait if oh-rst_lines_cnt is greater than zero. But if there are no hardreset lines asserted, then we should probably wait for the disable in that case. v = _omap4_wait_target_disable(oh); if (v) pr_warn(omap_hwmod: %s: _wait_target_disable failed\n, [...] @@ -1575,7 +1568,19 @@ static int _enable(struct omap_hwmod *oh) _enable_clocks(oh); _enable_module(oh); - r = _wait_target_ready(oh); + /* +* If an IP contains HW reset lines, we leave them +* asserted. But this will block the module's idle state +* transition - the PRCM will return Intransition status. So +* we need to avoid the target ready-wait in this case. XXX +* We also need to give the drivers a way to wait for the +* target to become ready once they decide to deassert some +* hardreset lines. XXX Is this strategy going to break PM +* because the clockdomain may not be able to enter idle while +* the module's idle status is in-transition? We may just need +* custom reset blocks for all IPs with hardreset lines. +*/ + r = (oh-rst_lines_cnt == 0) ? _wait_target_ready(oh) : 1; And this part is at odds with the patch description. If there are hardreset lines associated with an IP block, then this code will cause the following code to unconditionally disable the module clocks. Considering that this is the _enable() function, this seems counterproductive. I looked into changing this code to align with the original semantics we discussed. It seems quite challenging. With the current codebase, we'd have to bail out in the middle of the enable sequence. Then we'd lose the clockdomain state (the 'hwsup' variable). So I've updated the
[PATCH RESEND] ARM: OMAP: Revert ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Cc: sta...@vger.kernel.org # v3.2+ Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- Note: Resend with stable kernel list added in cc .../include/mach/ctrl_module_pad_core_44xx.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h index 1e2d332..c88420d 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h @@ -941,10 +941,10 @@ #define OMAP4_DSI2_LANEENABLE_MASK (0x7 29) #define OMAP4_DSI1_LANEENABLE_SHIFT24 #define OMAP4_DSI1_LANEENABLE_MASK (0x1f 24) -#define OMAP4_DSI2_PIPD_SHIFT 19 -#define OMAP4_DSI2_PIPD_MASK (0x1f 19) -#define OMAP4_DSI1_PIPD_SHIFT 14 -#define OMAP4_DSI1_PIPD_MASK (0x1f 14) +#define OMAP4_DSI1_PIPD_SHIFT 19 +#define OMAP4_DSI1_PIPD_MASK (0x1f 19) +#define OMAP4_DSI2_PIPD_SHIFT 14 +#define OMAP4_DSI2_PIPD_MASK (0x1f 14) /* CONTROL_MCBSPLP */ #define OMAP4_ALBCTRLRX_FSX_SHIFT 31 -- 1.7.5.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 v2] iommu: OMAP: device detach on domain destroy
On Wed, Apr 18, 2012 at 01:09:41PM -0500, Omar Ramirez Luna wrote: 'domain_destroy with devices attached' case isn't yet handled, instead code assumes that the device was already detached. If the domain is destroyed the hardware still has access to invalid pointers to its page table and internal iommu object. In order to detach the users we need to track devices using the iommu, current use cases only have one user of iommu per instance. When required this can evolve to a list with the devices using the iommu_dev. Reported-by: Joerg Roedel j...@8bytes.org Reviewed-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- v2: rebased onto v3.4-rc2 Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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 3/3] OMAPDSS: DISPC: Correct DISPC functional clock usage
On Mon, 2012-04-02 at 20:43 +0530, Chandrabhanu Mahapatra wrote:
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 28 ++--
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 17ffa71..cfde674 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1813,6 +1813,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
const int max_decim_limit = 16;
unsigned long fclk = 0;
+ unsigned long dispc_core_clk = dispc_core_clk_rate(channel);
int decim_x, decim_y, error, min_factor;
u16 in_width, in_height, in_width_max = 0;
@@ -1855,7 +1856,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
error = (in_width maxsinglelinewidth || !fclk ||
- fclk dispc_fclk_rate());
+ fclk dispc_core_clk);
if (error) {
if (decim_x == decim_y) {
decim_x = min_factor;
@@ -1893,7 +1894,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
out_width, out_height);
error = (error || in_width maxsinglelinewidth * 2 ||
(in_width maxsinglelinewidth *five_taps) ||
- !fclk || fclk dispc_fclk_rate());
+ !fclk || fclk dispc_core_clk);
if (error) {
if (decim_x == decim_y) {
decim_x = min_factor;
@@ -1926,7 +1927,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} else {
int decim_x_min = decim_x;
in_height = DIV_ROUND_UP(height, decim_y);
- in_width_max = dispc_fclk_rate() /
+ in_width_max = dispc_core_clk /
DIV_ROUND_UP(dispc_mgr_pclk_rate(channel),
out_width);
decim_x = DIV_ROUND_UP(width, in_width_max);
@@ -1950,13 +1951,13 @@ static int dispc_ovl_calc_scaling(enum omap_plane
plane,
}
DSSDBG(required fclk rate = %lu Hz\n, fclk);
- DSSDBG(current fclk rate = %lu Hz\n, dispc_fclk_rate());
+ DSSDBG(current fclk rate = %lu Hz\n, dispc_core_clk);
- if (!fclk || fclk dispc_fclk_rate()) {
+ if (!fclk || fclk dispc_core_clk) {
DSSERR(failed to set up scaling,
required fclk rate = %lu Hz,
current fclk rate = %lu Hz\n,
- fclk, dispc_fclk_rate());
+ fclk, dispc_core_clk);
return -EINVAL;
}
@@ -2646,6 +2647,21 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel
channel)
}
}
+unsigned long dispc_core_clk_rate(enum omap_channel channel)
+{
+ int lcd = 1;
+ unsigned long r = dispc_fclk_rate();
+
+ if (dss_has_feature(FEAT_CORE_CLK_DIV)) {
+ lcd = REG_GET(DISPC_DIVISOR, 23, 16);
+ } else {
+ if (dispc_mgr_is_lcd(channel))
+ lcd = REG_GET(DISPC_DIVISORo(channel), 23, 16);
+ }
+
+ return r / lcd ;
+}
+
I wonder if this is correct. channel for dispc core clock doesn't make
sense, there's no channel related to that. At least on OMAP4.
If I'm not mistaken, in omap2/3 case (i.e.
dss_has_feature(FEAT_CORE_CLK_DIV) == false) we can just use channel 0
to get the lcd divisor. Although that would mean that LCD output's
divisor affects the tv-out's scaling calculations, which feels a bit
strange...
So... I don't know... Do we really have two different dispc core clocks
int omap2/3 (for lcd output and for tv output), but only one in omap4?
If so, then the above code is ok. Have you found explanations from TRM
which say what clock is required and where?
In any case, please remove the initialization of lcd variable, and add:
else
lcd = 1;
I think that's much clearer. And r variable is commonly used as a
return value. I would rename the variable to something else, say, fck.
Tomi
signature.asc
Description: This is a digitally signed message part
[PATCHv8 03/10] I2C: OMAP: Fix the interrupt clearing in OMAP4
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch ...
- Does not use the IRQENABLE_CLR register to clear as it is not mentioned
to be legacy register IRQENABLE_CLR helps in atomically
setting/clearing specific interrupts, instead use the OMAP_I2C_IE_REG as we
are clearing all interrupts.
Cc: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c851672..bf07ffd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1127,10 +1127,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
u16 iv;
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.7.5.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
[PATCHv8 09/10] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9323201..d12b319 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -732,7 +732,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -745,6 +744,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
return 0;
}
+ *err |= OMAP_I2C_STAT_XUDF;
return 0;
}
--
1.7.5.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
[PATCHv8 00/10] I2C fixes
This patch series seperates the fixes from other changes from [2] [2] http://www.spinics.net/lists/linux-omap/msg68056.html The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. The following changes since commit 592fe8980688e7cba46897685d014c7fb3018a67: Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2012-04-17 13:30:34 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-fixes Shubhrajyoti D (9): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 drivers/i2c/busses/i2c-omap.c | 132 + 1 files changed, 67 insertions(+), 65 deletions(-) -- 1.7.5.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
[PATCHv8 10/10] I2C: OMAP: Rename the 1p153 to the erratum id i462
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d12b319..f5094b1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -173,7 +173,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 0)
-#define I2C_OMAP3_1P153(1 1)
+#define I2C_OMAP_ERRATA_I462 (1 1)
struct omap_i2c_dev {
struct device *dev;
@@ -720,11 +720,11 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
#endif
/*
- * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * OMAP3430 Errata i462: When an XRDY/XDR is hit, wait for XUDF before writing
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_i462(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
unsigned long timeout = 1;
@@ -883,8 +883,8 @@ complete:
break;
}
- if ((dev-errata I2C_OMAP3_1P153)
- errata_omap3_1p153(dev, stat, err))
+ if ((dev-errata I2C_OMAP_ERRATA_I462)
+ errata_omap3_i462(dev, stat, err))
goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
@@ -1024,7 +1024,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-errata |= I2C_OMAP_ERRATA_I207;
if (dev-rev = OMAP_I2C_REV_ON_3430)
- dev-errata |= I2C_OMAP3_1P153;
+ dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
u16 s;
--
1.7.5.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
[PATCHv8 07/10] I2C: OMAP: Handle error check for pm runtime
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 44e8cfa..d555dcd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -585,7 +585,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
int i;
int r;
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, r);
+ return r;
+ }
r = omap_i2c_wait_for_bb(dev);
if (r 0)
@@ -1011,7 +1015,11 @@ omap_i2c_probe(struct platform_device *pdev)
dev-regs = (u8 *)reg_map_ip_v1;
pm_runtime_enable(dev-dev);
- pm_runtime_get_sync(dev-dev);
+ r = pm_runtime_get_sync(dev-dev);
+ if (r 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed:%d\n, r);
+ return r;
+ }
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
@@ -1103,12 +,17 @@ omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
+ int ret;
platform_set_drvdata(pdev, NULL);
free_irq(dev-irq, dev);
i2c_del_adapter(dev-adapter);
- pm_runtime_get_sync(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ dev_err(dev-dev, pm_runtime_get_sync failed %d\n, ret);
+ return ret;
+ }
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
--
1.7.5.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
[PATCHv8 04/10] I2C: OMAP: Fix the error handling
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto err_free_irq;
}
...
return 0;
err_free_irq:
free_irq(dev-irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
This may access the i2c registers without the clocks.
Attempting to fix the same by moving the pm_rintime_put after the error check.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index bf07ffd..1777d79 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1061,8 +1061,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id,
dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed);
- pm_runtime_put(dev-dev);
-
adap = dev-adapter;
i2c_set_adapdata(adap, dev);
adap-owner = THIS_MODULE;
@@ -1082,6 +1080,8 @@ omap_i2c_probe(struct platform_device *pdev)
of_i2c_register_devices(adap);
+ pm_runtime_put(dev-dev);
+
return 0;
err_free_irq:
--
1.7.5.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
[PATCHv8 08/10] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
From: Tasslehoff Kjappfot tasskj...@gmail.com i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d555dcd..9323201 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -427,11 +427,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1023,6 +1018,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.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
[PATCHv8 02/10] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 4f4188d..c851672 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1090,6 +1090,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1110,6 +,7 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.5.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
[PATCHv8 05/10] I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the wait_for_completion_timeout returns long.
Original patch is
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=ea02cece7bbc736e60c4188a11aaa74bc6e6
Cc : Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 1777d79..fec8d5c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -473,7 +473,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg, int stop)
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
- int r;
+ unsigned long timeout;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -541,12 +541,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ timeout = wait_for_completion_timeout(dev-cmd_complete,
+ OMAP_I2C_TIMEOUT);
dev-buf_len = 0;
- if (r 0)
- return r;
- if (r == 0) {
+ if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
return -ETIMEDOUT;
--
1.7.5.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
[PATCHv8 01/10] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..4f4188d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.5.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
[PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: sta...@vger.kernel.org Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fec8d5c..44e8cfa 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1108,7 +1108,9 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); -- 1.7.5.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 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
On Thursday 05 April 2012, Trilok Soni wrote: Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I would definitely prefer something under drivers/power, drivers/regulators or a new top-level directory under drivers. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. I don't understand much of these versions right now, but hopefully after going through all these docs. My only contention point is to not create any directory into the drivers/power, unless it is generic fwk and then build up client drivers on top of it. Meanwhile we could move this driver into above options as I have suggested. I think creating the directory in the place where we want the files to stay in the long run is ok, if the plan is to add more drivers and make the base code more generic. We don't have to wait until it's too late and we absolutely need a framework ;-) The part I don't understand is how this relates to the regulator framework. Is there any overlap between the functionality provided by the smartreflex framework and the regulator framework? If so, would it be better to extend the existing framework so it can do smartreflex as well? Arnd -- 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 02/17][V2] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
On 04/10/2012 12:37 AM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
Reviewed-by: Jean Pihetj-pi...@ti.com
Reviewed-by: Santosh Shilimkarsantosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 57 +---
1 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index ee0bc50..6d86b59 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -132,21 +132,39 @@ struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner = THIS_MODULE,
.en_core_tk_irqen = 1,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C1,
+ .desc = MPUSS ON
+ },
+ {
+/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
+ .exit_latency = 328 + 440,
+ .target_residency = 960,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C2,
+ .desc = MPUSS CSWR,
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = C3,
+ .desc = MPUSS OSWR,
+ },
+ },
+ .state_count = OMAP4_NUM_STATES,
I think you can drop OMAP4_NUM_STATES here, and just use:
.state_count = ARRAY_SIZE(omap4_idle_driver.states),
Then drop OMAP4_NUM_STATES all together in patch 3.
Ok.
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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] OMAPDSS: Ensure OPP100 when DSS is operational
Tomi Valkeinen tomi.valkei...@ti.com writes: On Wed, 2012-04-18 at 10:03 -0700, Kevin Hilman wrote: [...] So, in summary, I have no objection $SUBJECT patch which implements the constraint using the only available method we have today. I take that was an ack for these patches? =) Yes. A reluctant one, but since I have nothing better to offer you: Acked-by: Kevin Hilman khil...@ti.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 10/17][V2] ARM: OMAP3: cpuidle - remove the 'valid' field
On 04/10/2012 01:13 AM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org writes:
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcanodaniel.lezc...@linaro.org
Reviewed-by: Jean Pihetj-pi...@ti.com
---
[ ... ]
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
- cx-valid = 0;
+ drv-state_count = OMAP3_NUM_STATES - 1;
pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
I'm not too particular about this one, but it might be cleaner to just
remove this check all together. This errata already has a check in
next_valid_state() so strictly speaking, it's not needed here.
Yes, right. Thanks for pointing this.
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
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/17][V2] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
On 04/10/2012 01:23 AM, Kevin Hilman wrote: Daniel Lezcanodaniel.lezc...@linaro.org writes: This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Thanks for this really nice cleanup. I have some comments on specific patches, but here's some general comments: Some minor comments: First, please be sure all patches have a descriptive changelog. Yes, even simple ones need changelogs. In particular, maintainers are looking for the why of a patch, not just the what or how. Second, this series introduced a couple sparse warnings: /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:134:1: warning: symbol 'omap4_idle_dev' was not declared. Should it be static? /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle44xx.c:136:23: warning: symbol 'omap4_idle_driver' was not declared. Should it be static? Ok, I probably missed it. I will fix that it in the next version. Thanks for reviewing. -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] ARM: OMAP: USB: fix warning on EHCI PHY reset path
ping Alan, Felipe, Can this go into 3.5? The dependency patch has already reached Samuel's tree, what would be the best way to apply this one? Should I ask Samuel to apply this one also (after having your acks) via his tree, to reduce possible merge failures/conflicts? On 03/27/12 16:08, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- Regards, Igor. -- 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] tty: omap-serial: Keep the wakeup mechanism enabled by default
On Thu, Apr 19, 2012 at 12:38 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: The point is that wakeups should be enabled whenever driver is in use, and disabled when the driver is not in use. Which is the tty_port methods for initialisation and shutdown, which are mutex protected against each other and hang up. Not sure how the uart layer glue exposes that. Is it okay to read the port flags to identify the port state in driver whether the serial port shutdown ops is called from port_suspend or due to port closure. Since port_shutdown gets called even from uart_suspend_port Is things like test_bit(ASYNCB_SUSPENDED, port-flags); or test_bit(ASYNCB_CLOSING, port-flags); allowed in low level driver ? -- Thanks, Govindraj.R -- 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 06/17][V2] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
On 04/10/2012 12:56 AM, Kevin Hilman wrote: Daniel Lezcanodaniel.lezc...@linaro.org writes: We are storing the 'omap4_idle_data' in the private data field of the cpuidle device. As we are using this variable only in this file, that does not really make sense. Let's use the global variable directly instead dereferencing pointers in an idle critical loop. Did you notice a performance impact before this change? No, I didn't and I don't think I will be able to measure it. But by experience, when dereferencing a pointer that could leads to a cache miss and impact the performances. That may not be the case here, so I won't argue with that as I won't able to prove it :) Also, that simplfies the code. possibly, but at the expense of clean abstractions which IMO helps readability. Unless there is a real performance hit here (which I doubt), I'd prefer to leave this as is. There are two reasons of this change. We are storing 'state_count' times a pointer in a private structure for state_usage but the information is already available in the file and easily accessible. Also, this is set in the fill_cstate function I am removing to let all the initialization to be done at compile time. Furthermore, I don't get why we have a 'driver data' area in a structure which is dedicated for the states statistics, IMHO that does not help understanding. My mid-term cleanup is to kill the 'driver_data' field in the cpuidle core because I don't think it is at the right place. An idea I had for consolidate all the cpuidle driver was to use the containerof macro to define the architecture specific structure and declare inside this structure the cpuidle driver and the devices. It is similar on how are implemented the 'routes' for the network stack or the cgroup subsystems, there is a core engine handling generic structure which a contained by the specific structure related to the engine's user. That helps a lot for readability. Well this is an idea but before I have to unify the cpuidle drivers code to make it clear what is doable or not. -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Thu, 19 Apr 2012, Igor Grinberg wrote: ping Alan, Felipe, Can this go into 3.5? It's okay with me. Acked-by: Alan Stern st...@rowland.harvard.edu The dependency patch has already reached Samuel's tree, what would be the best way to apply this one? Should I ask Samuel to apply this one also (after having your acks) via his tree, to reduce possible merge failures/conflicts? Sure, go ahead. On 03/27/12 16:08, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I did a little digging... Firstly, only the am3571evm board registers the davinci_emac platform device. On a Craneboard or a CM-T3517 there will simply be no network device for IP autoconfig to use (unless you magically have DT working). Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. -- 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: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Arnd, On Thu, Apr 19, 2012 at 3:54 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 05 April 2012, Trilok Soni wrote: Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I would definitely prefer something under drivers/power, drivers/regulators or a new top-level directory under drivers. Can I take this as an OK for drivers/power/avs as suggested? IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. I don't understand much of these versions right now, but hopefully after going through all these docs. My only contention point is to not create any directory into the drivers/power, unless it is generic fwk and then build up client drivers on top of it. Meanwhile we could move this driver into above options as I have suggested. I think creating the directory in the place where we want the files to stay in the long run is ok, if the plan is to add more drivers and make the base code more generic. We don't have to wait until it's too late and we absolutely need a framework ;-) Agree! That is the intention to provide a fwk. The part I don't understand is how this relates to the regulator framework. Is there any overlap between the functionality provided by the smartreflex framework and the regulator framework? If so, would it be better to extend the existing framework so it can do smartreflex as well? The link with regulator has indeed an impact on the target dir, this is still unknown and discussed internally. Arnd Thanks, 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] ASoC: omap-pcm: Free dma buffers in case of error.
Hi, On Thu, Apr 19, 2012 at 3:37 AM, Oleg Matcovschi oleg.matcovs...@ti.com wrote: Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- sound/soc/omap/omap-pcm.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index a2a464f..380a5bd 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -414,6 +414,10 @@ static int omap_pcm_new(struct snd_soc_pcm_runtime *rtd) } out: + /* free preallocated buffers in case of error */ + if (ret) + omap_pcm_free_dma_buffers(pcm); + If the playback preallocation fails, or if only capture is supported on the dai link this is not needed. It only applies if we have both playback and capture streams and the capture preallocation fails. Luckily the omap_pcm_free_dma_buffers() has internal checks for these cases... Acked-by: Peter Ujfalusi peter.ujfal...@ti.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: AM3517 boot failure
* Måns Rullgård m...@mansr.com [120419 08:31]: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I did a little digging... Firstly, only the am3571evm board registers the davinci_emac platform device. On a Craneboard or a CM-T3517 there will simply be no network device for IP autoconfig to use (unless you magically have DT working). Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. Just to check, is this with the bad muxing removed in fixes branch? Without that there can be all kinds of weird issues if some uart pins are used for non-uart functionality: bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads)? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Arnd Bergmann a...@arndb.de writes: On Thursday 05 April 2012, Trilok Soni wrote: Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I would definitely prefer something under drivers/power, drivers/regulators or a new top-level directory under drivers. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. I don't understand much of these versions right now, but hopefully after going through all these docs. My only contention point is to not create any directory into the drivers/power, unless it is generic fwk and then build up client drivers on top of it. Meanwhile we could move this driver into above options as I have suggested. I think creating the directory in the place where we want the files to stay in the long run is ok, if the plan is to add more drivers and make the base code more generic. We don't have to wait until it's too late and we absolutely need a framework ;-) Completely agree, thanks. The part I don't understand is how this relates to the regulator framework. Is there any overlap between the functionality provided by the smartreflex framework and the regulator framework? If so, would it be better to extend the existing framework so it can do smartreflex as well? IMO, there isn't any overlap with the regulator framework, and AVS drivers/devices should be separate from the regulator framework. Think of AVS/SmartReflex as a way for hardware to do automatic micro-adjustments to the regulator. The regulator voltage (a.k.a nominal voltage) will stay same from the perspective of the regulator and regulator framework, but AVS allows the hardware to do micro voltage adjustments around the nominal voltage. We recently extended the regulator framework to have allow get/set voltage hooks which can query platform-specific voltage frameworks which do hardware voltage control (which in turn can control AVS sensors/devices.) 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 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
Hi Benoît, On Thu, 19 Apr 2012, Cousson, Benoit wrote: The concern of the people doing SW in these embedded processors was mainly because we were releasing the reset of processor without loading any SW first and thus the processor was executing some random instructions. So if we consider a better hwmods definition, we can potentially fix the MMU case: 'mmu_ipu': 'rst_ipu_mmu_cache' 'mmu_dsp': 'rst_dsp_mmu_cache' 'iva_config': 'rst_logic' Wouldn't these still be pseudo-hwmods? Or do each of these actually have address space, interconnect ports, etc.? Another approach that might not require defining pseudo-hwmods is to define a per-hard-reset-line flag that could be used to alter the way the hwmod code handles the hardreset line. But then we do have the processor resets that have to be exposed somewhere. 'ipu': 'rst_cpu0' 'rst_cpu1' 'dsp': 'rst_dsp' 'iva': 'rst_seq1' 'rst_seq2' None of these one should be controlled automatically. Don't we still want to put these IP blocks into reset until a driver for these IP blocks is loaded? /* -* If an IP contains HW reset lines, then de-assert them in order -* to allow the module state transition. Otherwise the PRCM will return -* Intransition status, and the init will failed. +* If an IP block contains HW reset lines and any of them are +* asserted, we let integration code associated with that +* block handle the enable. We've received very little +* information on what those driver authors need, and until +* detailed information is provided and the driver code is +* posted to the public lists, this is probably the best we +* can do. Maybe we should keep that with some mechanism to prevent it for some IP like processors . I guess that with that patch, we cannot enable anymore IPU/DSP and IVA at boot time. I am probably misunderstanding your comment, but I don't think there's any way at the moment to generically enable those IP blocks without driver integration code assistance. If we leave the hardreset lines asserted in _enable(), then the PRCM status for those modules will be stuck in In-transition state, according to the previous comments in the code. I think this will block PM idle transitions. Also we have no way to restore the clockdomain idle settings during the second part of the hwmod enable sequence, I think, since it will need to be executed by driver integration code :-( And I don't think we can deassert the hardreset lines in _enable() right now, for the reason that you mentioned in your message: unless the driver integration code implements a custom reset function, we don't have any way to load code into the IP block before deasserting the hardreset. So at this point I'd propose that we encourage these driver authors to implement custom reset functions for their IP blocks that load firmware if needed, and put them into idle, similar to what omap3_iva_idle() does in mach-omap2/pm34xx.c. If the custom reset function takes the IP block out of hardreset, then the subsequent hwmod enable/idle/shutdown calls should work, after this patch. Otherwise, it looks fine to me. Thanks for the review. - Paul
Re: [PATCH 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization
On Wed, Apr 18, 2012 at 06:39:14PM -0700, Tony Lindgren wrote: Cool, you almost got it. Got it working for n800 and 770 with the following patch. Only extremely light testing done now so careful with this patch too.. Had to hack in support for the src_port and dst_port that's needed for omap_set_dma_src/dest_params on omap1. What's the relationship between these ports and the DMA request signal? Is there a document which describes this? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Tony Lindgren t...@atomide.com writes: * Måns Rullgård m...@mansr.com [120419 08:31]: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I did a little digging... Firstly, only the am3571evm board registers the davinci_emac platform device. On a Craneboard or a CM-T3517 there will simply be no network device for IP autoconfig to use (unless you magically have DT working). Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). This clock problem was recently fixed in the linux-omap tree. I should have made sure my tree was fully up to date before poking around. With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. Just to check, is this with the bad muxing removed in fixes branch? Without that there can be all kinds of weird issues if some uart pins are used for non-uart functionality: bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads)? Same problem on linux-omap master. If I simply drop the msleep() calls (and use CONFIG_PREEMPT), it progresses a bit further. With a static IP config provided, ip_auto_config() returns and it hangs somewhere else. With ip=dhcp it sends out a DHCP request but gets stuck waiting for the reply. -- 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: AM3517 boot failure
On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: I did a little digging... Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). This is fixed by 59269b94483eabeacbc9a535944b3dafac92a303 (ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases) from Ilya Yanok ya...@emcraft.com. Its in the current mainline kernel. I'm sure you already know this but I want to make everyone is aware--don't forget to enable davinci_emac because it isn't in omap2plus_defconfig. Matt Porter mpor...@ti.com submitted a patch for that some time ago but I don't know its status: http://www.spinics.net/lists/linux-omap/msg64367.html With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. I tried the current mainline on my am3517 evm and it hangs as well. I'm not surprised, the am35xx has some serious issues ATM. I submitted a set of patches to fix a lot of them but they need to be reworked. I'm working on that now. Until then, don't expect much to work well. If it does seem to work well, you got lucky. If you want to get running quickly, try the ***HACK*** below. Current mainline boot with it applied, CONFIG_TI_DAVINCI_EMAC=y, boots on my am3517 evm with both an MMC-mounted NFS-mounted rootfs. Mark -- diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 703bd10..187f5cb 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -705,7 +705,6 @@ static int __init omap3_pm_init(void) struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm; int ret; - if (!cpu_is_omap34xx()) return -ENODEV; if (!omap3_has_io_chain_ctrl()) -- 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 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization
* Russell King - ARM Linux li...@arm.linux.org.uk [120419 10:46]: On Wed, Apr 18, 2012 at 06:39:14PM -0700, Tony Lindgren wrote: Cool, you almost got it. Got it working for n800 and 770 with the following patch. Only extremely light testing done now so careful with this patch too.. Had to hack in support for the src_port and dst_port that's needed for omap_set_dma_src/dest_params on omap1. What's the relationship between these ports and the DMA request signal? Is there a document which describes this? It's the source and destination addresses bus port, so it's more related to the addresses than request signal. I guess routing of the DMA request signal is what it really does. I'm now wondering if it might be possible to set it automatically based on source and destination address. There's some information in the omap5912 trm on pages 717 and 718: http://www.ti.com/litv/pdf/spru742 It says for CSDP source port This field identifies the port originator of the transfer. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: craneboard: register emac device
This adds the required am35xx_emac_init() call to the craneboard init function. Signed-off-by: Mans Rullgard m...@mansr.com --- arch/arm/mach-omap2/board-am3517crane.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c index c3851e8..3b8a53c 100644 --- a/arch/arm/mach-omap2/board-am3517crane.c +++ b/arch/arm/mach-omap2/board-am3517crane.c @@ -30,6 +30,7 @@ #include common.h #include plat/usb.h +#include am35xx-emac.h #include mux.h #include control.h @@ -90,6 +91,7 @@ static void __init am3517_crane_init(void) } usbhs_init(usbhs_bdata); + am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1); } MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD) -- 1.7.8.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap3: Only access IVA if one exists
From: Mark A. Greer mgr...@animalcreek.com
prcm_setup_regs() blindly accesses IVA bits
in the PRM and calls omap3_iva_idle() which
does more IVA related register accesses.
Only do this if the IVA hardware actually
exists.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/pm34xx.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..ec92676 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -583,10 +583,13 @@ static void __init prcm_setup_regs(void)
OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
/* Don't attach IVA interrupts */
- omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
- omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
- omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
- omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL);
+ if (omap3_has_iva()) {
+ omap2_prm_write_mod_reg(0, WKUP_MOD, OMAP3430_PM_IVAGRPSEL);
+ omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430_PM_IVAGRPSEL1);
+ omap2_prm_write_mod_reg(0, CORE_MOD, OMAP3430ES2_PM_IVAGRPSEL3);
+ omap2_prm_write_mod_reg(0, OMAP3430_PER_MOD,
+ OMAP3430_PM_IVAGRPSEL);
+ }
/* Clear any pending 'reset' flags */
omap2_prm_write_mod_reg(0x, MPU_MOD, OMAP2_RM_RSTST);
@@ -600,7 +603,9 @@ static void __init prcm_setup_regs(void)
/* Clear any pending PRCM interrupts */
omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- omap3_iva_idle();
+ if (omap3_has_iva())
+ omap3_iva_idle();
+
omap3_d2d_idle();
}
--
1.7.9.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] arm: omap3: am35x: Register davinci_mdio before davinci_emac
From: Mark A. Greer mgr...@animalcreek.com
Problem:
When resuming from a Suspend-to-RAM event, the eth0 device
(davinci emac/mdio) on am35xx boards wouldn't work and the
following error message appeared on the console:
net eth0: could not connect to phy davinci_mdio-0:00
Cause:
--
When davinci_emac_resume() calls emac_dev_open() which
ultimately calls davinci_mdio_read(), the 'data-suspended'
flag in davinci_mdio.c is still set to 'true'. This causes
davinci_mdio_read() to fail which ripples back up the call
chain causing davinci_emac_resume() to fail. The reason
'data-suspended' is still set to 'true' is that
davinci_mdio_resume() hasn't been called yet as it should
have been. davinci_mdio_resume() must be called before
davinci_emac_resume().
Solution:
-
Register the davinci_mdio platform device before registering
the davinci_emac platform device so davinci_mdio_resume()
is called before davinci_emac_resume() and eth0 can resume.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/am35xx-emac.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 1f97e74..d23bd6c 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -97,11 +97,6 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq, u8
rmii_en)
am35xx_emac_pdata.rmii_en = rmii_en;
am35xx_emac_mdio_pdata.bus_freq = mdio_bus_freq;
- err = platform_device_register(am35xx_emac_device);
- if (err) {
- pr_err(AM35x: failed registering EMAC device: %d\n, err);
- return;
- }
err = platform_device_register(am35xx_emac_mdio_device);
if (err) {
@@ -110,6 +105,12 @@ void __init am35xx_emac_init(unsigned long mdio_bus_freq,
u8 rmii_en)
return;
}
+ err = platform_device_register(am35xx_emac_device);
+ if (err) {
+ pr_err(AM35x: failed registering EMAC device: %d\n, err);
+ return;
+ }
+
regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
regval = regval (~(AM35XX_CPGMACSS_SW_RST));
omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
--
1.7.9.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] arm: omap3: am35x: Register davinci_mdio before davinci_emac
On Thu, Apr 19, 2012 at 11:19:38AM -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com Problem: When resuming from a Suspend-to-RAM event, the eth0 device (davinci emac/mdio) on am35xx boards wouldn't work and the following error message appeared on the console: net eth0: could not connect to phy davinci_mdio-0:00 I'm sorry, please ignore. This patch has already been pooh-pooh'd. Mark -- -- 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hello,
Here is version 2 of this patch, fixing in bug discovered while testing
on a BeagleBoard rev C3 (OMAP3530 ES3.0 + Micron NAND 256MiB 1,8V 16-bit).
--
Ivan
This patch adds a simple BCH ecc computation api, similar to the
existing Hamming ecc api. It is intended to be used by the MTD layer.
It implements the following features:
- support 4-bit and 8-bit ecc computation
- do not protect user bytes in spare area, only data area is protected
- ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs
This last feature is obtained by adding a constant polynomial to
the hardware computed ecc. It allows to correct bitflips in blank pages
and is extremely useful to support filesystems such as UBIFS, which expect
erased pages to contain only 0xFFs.
This api has been tested on an OMAP3630 board.
Signed-off-by: Ivan Djelic ivan.dje...@parrot.com
---
v2 changelog: added missing control register configuration
arch/arm/mach-omap2/gpmc.c | 148
arch/arm/plat-omap/include/plat/gpmc.h | 10 +++
2 files changed, 158 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..e3a91a1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -920,3 +921,150 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char
*ecc_code)
return 0;
}
EXPORT_SYMBOL_GPL(gpmc_calculate_ecc);
+
+#ifdef CONFIG_ARCH_OMAP3
+
+/**
+ * gpmc_enable_hwecc_bch - enable hardware BCH ecc functionality
+ * @cs: chip select number
+ * @mode: read/write mode
+ * @dev_width: device bus width(1 for x16, 0 for x8)
+ * @nsectors: how many 512-byte sectors to process
+ * @nerrors: how many errors to correct per sector (4 or 8)
+ */
+int gpmc_enable_hwecc_bch(int cs, int mode, int dev_width, int nsectors,
+ int nerrors)
+{
+ unsigned int val;
+
+ /* check if ecc module is in use */
+ if (gpmc_ecc_used != -EINVAL)
+ return -EINVAL;
+ /*
+* FIXME: some OMAP3 revisions have a hardware bug which prevents
+* the 4-bit BCH mode from working properly. Such revisions could be
+* detected and rejected here.
+*/
+
+ gpmc_ecc_used = cs;
+
+ /* clear ecc and enable bits */
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x1);
+
+ /*
+* When using BCH, sector size is hardcoded to 512 bytes.
+* Here we are using wrapping mode 6 both for reading and writing, with:
+* size0 = 0 (no additional protected byte in spare area)
+* size1 = 32 (skip 32 nibbles = 16 bytes per sector in spare area)
+*/
+ gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, (32 22) | (0 12));
+
+ /* BCH configuration */
+ val = ((1 16) | /* enable BCH */
+ (((nerrors == 8) ? 1 : 0) 12) | /* 8 or 4 bits */
+ (0x06 8) | /* wrap mode = 6 */
+ (dev_width 7) | /* bus width */
+ (((nsectors-1) 0x7) 4) | /* number of sectors */
+ (cs 1) | /* ECC CS */
+ (0x1));/* enable ECC */
+
+ gpmc_write_reg(GPMC_ECC_CONFIG, val);
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gpmc_enable_hwecc_bch);
+
+/**
+ * gpmc_calculate_ecc_bch4 - Generate 7 ecc bytes per sector of 512 data bytes
+ * @cs: chip select number
+ * @dat: The pointer to data on which ecc is computed
+ * @ecc: The ecc output buffer
+ */
+int gpmc_calculate_ecc_bch4(int cs, const u_char *dat, u_char *ecc)
+{
+ int i;
+ unsigned long nsectors, reg, val1, val2;
+
+ if (gpmc_ecc_used != cs)
+ return -EINVAL;
+
+ nsectors = ((gpmc_read_reg(GPMC_ECC_CONFIG) 4) 0x7) + 1;
+
+ for (i = 0; i nsectors; i++) {
+
+ reg = GPMC_ECC_BCH_RESULT_0 + 16*i;
+
+ /* Read hw-computed remainder */
+ val1 = gpmc_read_reg(reg + 0);
+ val2 = gpmc_read_reg(reg + 4);
+
+ /*
+* Add constant polynomial to remainder, in order to get an ecc
+* sequence of 0xFFs for a buffer filled with 0xFFs; and
+* left-justify the resulting polynomial.
+*/
+ *ecc++ = 0x28 ^ ((val2 12) 0xFF);
+ *ecc++ = 0x13 ^ ((val2 4) 0xFF);
+ *ecc++ = 0xcc ^ (((val2 0xF) 4)|((val1 28) 0xF));
+ *ecc++ = 0x39 ^ ((val1 20) 0xFF);
+ *ecc++ = 0x96 ^ ((val1 12) 0xFF);
+ *ecc++ = 0xac ^ ((val1 4) 0xFF);
+ *ecc++ = 0x7f ^ ((val1 0xF) 4);
+ }
+
+
[PATCH] arm: omap3: am35x: Don't mark missing features as present
From: Mark A. Greer mgr...@animalcreek.com The Chip Identification register on the am35x family of SoCs has bits 12, 7:5, and 3:2 marked as reserved and are read as zeroes. Unfortunately, on other omap SoCs, a 0 bit means a feature is Full Use so the OMAP3_CHECK_FEATURE() macro called by omap3_check_features() will incorrectly interpret those zeroes to mean that a feature is present even though it isn't. To fix that, the feature bits that are incorrectly set (namely, OMAP3_HAS_IVA and OMAP3_HAS_ISP) need to be cleared after all of the calls to OMAP3_CHECK_FEATURE() in omap3_check_features() are made. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- arch/arm/mach-omap2/id.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0e79b7b..9736049 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -248,6 +248,17 @@ void __init omap3xxx_check_features(void) omap_features |= OMAP3_HAS_SDRC; /* +* am35x fixups: +* - The am35x Chip ID register has bits 12, 7:5, and 3:2 marked as +* reserved and therefore return 0 when read. Unfortunately, +* OMAP3_CHECK_FEATURE() will interpret some of those zeroes to +* mean that a feature is present even though it isn't so clear +* the incorrectly set feature bits. +*/ + if (cpu_is_omap3505() || cpu_is_omap3517()) + omap_features = ~(OMAP3_HAS_IVA | OMAP3_HAS_ISP); + + /* * TODO: Get additional info (where applicable) * e.g. Size of L2 cache. */ -- 1.7.9.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: AM3517 boot failure
On Thu, 2012-04-19 at 10:57 +0300, Igor Grinberg wrote: On 04/19/12 05:07, Paul Walmsley wrote: Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I have a board with the AM3505 and NFS root works fine here. I'm using 3.4-rc3, Mark A. Greer's patch series on this list (2012-04-11) and Paul Walmsley's fixes-for-v3.4-rc3 tag. A possible difference is that I'm using the fixed PHY driver. Best regards, Jan Lübbe -- 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 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
Hi Paul, On 4/19/2012 7:17 PM, Paul Walmsley wrote: Hi Benoît, On Thu, 19 Apr 2012, Cousson, Benoit wrote: The concern of the people doing SW in these embedded processors was mainly because we were releasing the reset of processor without loading any SW first and thus the processor was executing some random instructions. So if we consider a better hwmods definition, we can potentially fix the MMU case: 'mmu_ipu': 'rst_ipu_mmu_cache' 'mmu_dsp': 'rst_dsp_mmu_cache' 'iva_config': 'rst_logic' Wouldn't these still be pseudo-hwmods? Or do each of these actually have address space, interconnect ports, etc.? Yes, these ones are the only real IPs for MPU stand point, with interconnect port and configuration registers. Another approach that might not require defining pseudo-hwmods is to define a per-hard-reset-line flag that could be used to alter the way the hwmod code handles the hardreset line. Yes, I think this is what Rajendra proposed long time ago... But then we do have the processor resets that have to be exposed somewhere. 'ipu': 'rst_cpu0' 'rst_cpu1' 'dsp': 'rst_dsp' 'iva': 'rst_seq1' 'rst_seq2' None of these one should be controlled automatically. Don't we still want to put these IP blocks into reset until a driver for these IP blocks is loaded? Yes, indeed, my point is where are we going to declare these reset lines if we do not have any fake hwmods to store them. /* -* If an IP contains HW reset lines, then de-assert them in order -* to allow the module state transition. Otherwise the PRCM will return -* Intransition status, and the init will failed. +* If an IP block contains HW reset lines and any of them are +* asserted, we let integration code associated with that +* block handle the enable. We've received very little +* information on what those driver authors need, and until +* detailed information is provided and the driver code is +* posted to the public lists, this is probably the best we +* can do. Maybe we should keep that with some mechanism to prevent it for some IP like processors . I guess that with that patch, we cannot enable anymore IPU/DSP and IVA at boot time. I am probably misunderstanding your comment, but I don't think there's any way at the moment to generically enable those IP blocks without driver integration code assistance. Well, for the MMU we can, these are regular IPs (almost). The real issues was for the processors. If we leave the hardreset lines asserted in _enable(), then the PRCM status for those modules will be stuck in In-transition state, according to the previous comments in the code. I think this will block PM idle transitions. Also we have no way to restore the clockdomain idle settings during the second part of the hwmod enable sequence, I think, since it will need to be executed by driver integration code :-( And I don't think we can deassert the hardreset lines in _enable() right now, for the reason that you mentioned in your message: unless the driver integration code implements a custom reset function, we don't have any way to load code into the IP block before deasserting the hardreset. Fully agree, what I was trying to highlight is that we do have two types of hardreset here: the processors ones and the MMU / Logic ones. Only the processors do require some special management because a firmware has to be loaded first. So at this point I'd propose that we encourage these driver authors to implement custom reset functions for their IP blocks that load firmware if needed, and put them into idle, similar to what omap3_iva_idle() does in mach-omap2/pm34xx.c. If the custom reset function takes the IP block out of hardreset, then the subsequent hwmod enable/idle/shutdown calls should work, after this patch. First they will have to release their driver :-) Regards, 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: AM3517 boot failure
Mark A. Greer mgr...@animalcreek.com writes: On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: I did a little digging... Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). This is fixed by 59269b94483eabeacbc9a535944b3dafac92a303 (ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases) from Ilya Yanok ya...@emcraft.com. Its in the current mainline kernel. Yeah, I noticed after I'd already figured out why it was failing. Oh well, it was a good exercise. With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. I tried the current mainline on my am3517 evm and it hangs as well. I'm not surprised, the am35xx has some serious issues ATM. I submitted a set of patches to fix a lot of them but they need to be reworked. I'm working on that now. Until then, don't expect much to work well. If it does seem to work well, you got lucky. If you want to get running quickly, try the ***HACK*** below. Current mainline boot with it applied, CONFIG_TI_DAVINCI_EMAC=y, boots on my am3517 evm with both an MMC-mounted NFS-mounted rootfs. Mark -- diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 703bd10..187f5cb 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -705,7 +705,6 @@ static int __init omap3_pm_init(void) struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm; int ret; - if (!cpu_is_omap34xx()) return -ENODEV; if (!omap3_has_io_chain_ctrl()) That does indeed make it boot. -- 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: [PATCH v2 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
Hi Benoît, On Thu, 19 Apr 2012, Cousson, Benoit wrote: On 4/19/2012 7:17 PM, Paul Walmsley wrote: On Thu, 19 Apr 2012, Cousson, Benoit wrote: The concern of the people doing SW in these embedded processors was mainly because we were releasing the reset of processor without loading any SW first and thus the processor was executing some random instructions. So if we consider a better hwmods definition, we can potentially fix the MMU case: 'mmu_ipu': 'rst_ipu_mmu_cache' 'mmu_dsp': 'rst_dsp_mmu_cache' 'iva_config': 'rst_logic' Wouldn't these still be pseudo-hwmods? Or do each of these actually have address space, interconnect ports, etc.? Yes, these ones are the only real IPs for MPU stand point, with interconnect port and configuration registers. These are the MMUs documented in Chapter 20 of the OMAP4430 TRM vX, right? I don't really understand the interaction of the hardreset lines with these IPs. Chapter 20 doesn't seem to mention the PRCM-controllable hardreset lines at all. It only mentions the OCP_SYSCONFIG registers associated with them. Meanwhile Table 3-375 RM_DSP_RSTCTRL mentions a DSP MMU, cache, and slave interface reset line. Is that referring to the same MMU that is mentioned in Chapter 20? The end of Section 20.2 MMU Integration mentions two different DSP MMUs, a shared cache MMU and an L2 MMU - maybe the hardreset line only pertains to the first MMU? But then we do have the processor resets that have to be exposed somewhere. 'ipu': 'rst_cpu0' 'rst_cpu1' 'dsp': 'rst_dsp' 'iva': 'rst_seq1' 'rst_seq2' None of these one should be controlled automatically. Don't we still want to put these IP blocks into reset until a driver for these IP blocks is loaded? Yes, indeed, my point is where are we going to declare these reset lines if we do not have any fake hwmods to store them. Wouldn't we associate them with the processor hwmods? e.g., omap44xx_iva_hwmod, omap44xx_dsp_hwmod ? Well, for the MMU we can, these are regular IPs (almost). The real issues was for the processors. Omar, do you know how these hardreset lines interact with the MMUs described in the TRM Chapter 20? First they will have to release their driver :-) Hehe, indeed. - Paul
Re: [PATCH 2/2] OMAPDSS: Ensure OPP100 when DSS is operational
On Wed, Apr 18, 2012 at 10:06 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-04-18 at 10:26 -0700, Turquette, Mike wrote: On Wed, Apr 18, 2012 at 10:03 AM, Kevin Hilman khil...@ti.com wrote: Tomi Valkeinen tomi.valkei...@ti.com writes: On Tue, 2012-03-13 at 11:37 -0700, Kevin Hilman wrote: It sounds to me like it acutally is a throughput constraint on CORE. If so, wouldn't it be clearer to set a throughput constraint that is calculated based on the pixel clock and resulting bitrate that would have the same effect? I don't see that these limits would have anything to do with CORE. I'm guessing that the DSS HW just can't function properly with high clocks and low voltage. OK, this gets back to something we've talked about a few times that is needed in the clock framework. Basically, we need a way for clocks to prevent changes so these kinds of dependencies can be tracked. We've talked about new APIs like clk_allow_changes(), clk_block_changes() or something like that. Basically, something that allows clocks to know that their will not be changed under them. Are the DSS clocks changing frequency behind your back? Or are the clock rates staying the same while the voltage is dropped? The latter. The clocks do not change behind my back. It's the DSS driver making the clock rate changes. Right. The DVFS RFC that I'm working on right now should at least take care of the voltage scaling down when it shouldn't. For the former issue Kevin is right that we need better clock semantics. For the latter issue hopefully the future dvfs architecture will do the right thing (at least it does on paper). Note that many of the DSS clocks are generated inside DSS HW, and managed by the DSS driver, and thus the clock framework doesn't know anything about them. Will the future dvfs offer some way for the drivers to limit the OPP? It must! In fact the common clk framework today (merged in 3.4-rc1) allows you to model your DSS clocks in a common way that jives with the rest of the SoC/PMIC/whatever. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap3: Remove superfluous commas from gfx_sgx_3xxx_wkdeps[]
From: Mark A. Greer mgr...@animalcreek.com
Clean up clockdomains3xxx_data.c a bit by removing the
superfluous commas in gfx_sgx_3xxx_wkdeps[].
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index b84e138..6038adb 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -53,9 +53,9 @@
* 3430ES2 PM_WKDEP_SGX: adds IVA2, removes CORE
*/
static struct clkdm_dep gfx_sgx_3xxx_wkdeps[] = {
- { .clkdm_name = iva2_clkdm, },
- { .clkdm_name = mpu_clkdm, },
- { .clkdm_name = wkup_clkdm, },
+ { .clkdm_name = iva2_clkdm },
+ { .clkdm_name = mpu_clkdm },
+ { .clkdm_name = wkup_clkdm },
{ NULL },
};
--
1.7.9.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 v2] arm: omap3: am35x: Fix clockdomain dependencies
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs do not have an IVA so
a parallel set of clockdomain dependencies are
required that are simililar to OMAP3 but without
any IVA dependencies.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
Paul, this is a respin of
[PATCH 08/12] arm: omap3: am35x: Fix clockdomain dependencies
with your comments [hopefully] addressed. I'm breaking that long series
into smaller pieces because most of them really weren't related.
arch/arm/mach-omap2/clockdomains3xxx_data.c | 157 ---
1 file changed, 144 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 6038adb..e72991f 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -59,6 +59,12 @@ static struct clkdm_dep gfx_sgx_3xxx_wkdeps[] = {
{ NULL },
};
+static struct clkdm_dep gfx_sgx_am35x_wkdeps[] = {
+ { .clkdm_name = mpu_clkdm },
+ { .clkdm_name = wkup_clkdm },
+ { NULL },
+};
+
/* 3430: PM_WKDEP_PER: CORE, IVA2, MPU, WKUP */
static struct clkdm_dep per_wkdeps[] = {
{ .clkdm_name = core_l3_clkdm },
@@ -69,6 +75,14 @@ static struct clkdm_dep per_wkdeps[] = {
{ NULL },
};
+static struct clkdm_dep per_am35x_wkdeps[] = {
+ { .clkdm_name = core_l3_clkdm },
+ { .clkdm_name = core_l4_clkdm },
+ { .clkdm_name = mpu_clkdm },
+ { .clkdm_name = wkup_clkdm },
+ { NULL },
+};
+
/* 3430ES2: PM_WKDEP_USBHOST: CORE, IVA2, MPU, WKUP */
static struct clkdm_dep usbhost_wkdeps[] = {
{ .clkdm_name = core_l3_clkdm },
@@ -79,6 +93,14 @@ static struct clkdm_dep usbhost_wkdeps[] = {
{ NULL },
};
+static struct clkdm_dep usbhost_am35x_wkdeps[] = {
+ { .clkdm_name = core_l3_clkdm },
+ { .clkdm_name = core_l4_clkdm },
+ { .clkdm_name = mpu_clkdm },
+ { .clkdm_name = wkup_clkdm },
+ { NULL },
+};
+
/* 3430 PM_WKDEP_MPU: CORE, IVA2, DSS, PER */
static struct clkdm_dep mpu_3xxx_wkdeps[] = {
{ .clkdm_name = core_l3_clkdm },
@@ -89,6 +111,14 @@ static struct clkdm_dep mpu_3xxx_wkdeps[] = {
{ NULL },
};
+static struct clkdm_dep mpu_am35x_wkdeps[] = {
+ { .clkdm_name = core_l3_clkdm },
+ { .clkdm_name = core_l4_clkdm },
+ { .clkdm_name = dss_clkdm },
+ { .clkdm_name = per_clkdm },
+ { NULL },
+};
+
/* 3430 PM_WKDEP_IVA2: CORE, MPU, WKUP, DSS, PER */
static struct clkdm_dep iva2_wkdeps[] = {
{ .clkdm_name = core_l3_clkdm },
@@ -116,6 +146,12 @@ static struct clkdm_dep dss_wkdeps[] = {
{ NULL },
};
+static struct clkdm_dep dss_am35x_wkdeps[] = {
+ { .clkdm_name = mpu_clkdm },
+ { .clkdm_name = wkup_clkdm },
+ { NULL },
+};
+
/* 3430: PM_WKDEP_NEON: MPU */
static struct clkdm_dep neon_wkdeps[] = {
{ .clkdm_name = mpu_clkdm },
@@ -131,6 +167,11 @@ static struct clkdm_dep dss_sleepdeps[] = {
{ NULL },
};
+static struct clkdm_dep dss_am35x_sleepdeps[] = {
+ { .clkdm_name = mpu_clkdm },
+ { NULL },
+};
+
/* 3430: CM_SLEEPDEP_PER: MPU, IVA */
static struct clkdm_dep per_sleepdeps[] = {
{ .clkdm_name = mpu_clkdm },
@@ -138,6 +179,11 @@ static struct clkdm_dep per_sleepdeps[] = {
{ NULL },
};
+static struct clkdm_dep per_am35x_sleepdeps[] = {
+ { .clkdm_name = mpu_clkdm },
+ { NULL },
+};
+
/* 3430ES2: CM_SLEEPDEP_USBHOST: MPU, IVA */
static struct clkdm_dep usbhost_sleepdeps[] = {
{ .clkdm_name = mpu_clkdm },
@@ -145,6 +191,11 @@ static struct clkdm_dep usbhost_sleepdeps[] = {
{ NULL },
};
+static struct clkdm_dep usbhost_am35x_sleepdeps[] = {
+ { .clkdm_name = mpu_clkdm },
+ { NULL },
+};
+
/* 3430: CM_SLEEPDEP_CAM: MPU */
static struct clkdm_dep cam_sleepdeps[] = {
{ .clkdm_name = mpu_clkdm },
@@ -175,6 +226,15 @@ static struct clockdomain mpu_3xxx_clkdm = {
.clktrctrl_mask = OMAP3430_CLKTRCTRL_MPU_MASK,
};
+static struct clockdomain mpu_am35x_clkdm = {
+ .name = mpu_clkdm,
+ .pwrdm = { .name = mpu_pwrdm },
+ .flags = CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP,
+ .dep_bit= OMAP3430_EN_MPU_SHIFT,
+ .wkdep_srcs = mpu_am35x_wkdeps,
+ .clktrctrl_mask = OMAP3430_CLKTRCTRL_MPU_MASK,
+};
+
static struct clockdomain neon_clkdm = {
.name = neon_clkdm,
.pwrdm = { .name = neon_pwrdm },
@@ -210,6 +270,15 @@ static struct clockdomain sgx_clkdm = {
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
};
+static struct clockdomain sgx_am35x_clkdm = {
+ .name = sgx_clkdm,
+ .pwrdm = { .name = sgx_pwrdm },
+ .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .wkdep_srcs = gfx_sgx_am35x_wkdeps,
+ .sleepdep_srcs = gfx_sgx_sleepdeps,
+ .clktrctrl_mask =
[GIT PULL] ARM: OMAP2+: hwmod data: add most of the remaining OMAP4 hwmods
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit 3af35fbcd088e0b675fa423a879c596384894180:
ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP (2012-04-19
04:25:08 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending
tags/omap-devel-a-for-3.5
for you to fetch changes up to 96566043b19ae76d3828ce75cbf28dc6d0bcaaf1:
ARM: OMAP4: hwmod data: add DEBUGSS skeleton (2012-04-19 13:33:59 -0600)
-
Add in most of the remaining hwmods (IP block descriptions) for the
OMAP44xx family of SoCs. There still seem to be a few missing, such
as those for the MMU IP blocks, but this seems to cover the bulk of
the remainder.
-
This is based on top of the hwmod cleanup for 3.5 tag.
This series has been boot-tested on N800, 2430SDP, CM-T3517, 3530ES3
Beagle, 3730ES1.2 EVM, and 4430ES2 Panda. System suspend entry and
exit (via UART wakeup) was tested on 3530ES3 Beagle and 4430ES2 Panda.
Dynamic idle entry and exit (via UART wakeup) was tested on 3530ES3
Beagle. Logs of this testing are available at
http://www.pwsan.com/omap/bootlogs/20120419/omap4_hwmod_devel_a_3.5__96566043b19ae76d3828ce75cbf28dc6d0bcaaf1/
- - Paul
- ---
object size (delta in bytes from hwmod_cleanup_a_3.5
(3af35fbcd088e0b675fa423a879c596384894180)):
textdata bss total kernel
0 0 0 0 5912osk_testconfig/vmlinux
0 0 0 0 n800_multi_omap2xxx/vmlinux
0 0 0 0 n800_testconfig/vmlinux
0 0 0 0 omap1_defconfig/vmlinux
+4096 +7008 0 +11104 omap2_4_testconfig/vmlinux
0 +6944 0 +6944 omap2plus_defconfig/vmlinux
+4096 +7008 0 +11104 omap2plus_no_pm/vmlinux
+4160 +7008 +64 +11232 omap3_4_testconfig/vmlinux
0 0 0 0 omap3_testconfig/vmlinux
0 +7136 0 +7136 omap4_testconfig/vmlinux
Benoît Cousson (6):
ARM: OMAP4: hwmod data: add GPMC
ARM: OMAP4: hwmod data: add the Slimbus IP blocks
ARM: OMAP4: hwmod data: add McASP
ARM: OMAP4: hwmod data: add remaining USB-related IP blocks
ARM: OMAP4: hwmod data: add the OCP-WP IP block
ARM: OMAP4: hwmod data: add DEBUGSS skeleton
Ming Lei (1):
ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod
Paul Walmsley (8):
ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
ARM: OMAP4: hwmod data: add HDQ/1-wire
ARM: OMAP4: hwmod data: add EMIF1 and 2
ARM: OMAP4: hwmod data: add GPU
ARM: OMAP4: hwmod data: add some interconnect-related IP blocks
ARM: OMAP4: hwmod data: add OCM RAM IP block
ARM: OMAP4: hwmod data: add System Control Module
ARM: OMAP4: hwmod data: add PRCM and related IP blocks
arch/arm/mach-omap2/Makefile |8 +-
arch/arm/mach-omap2/clockdomain44xx.c|6 +
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10 -
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +
arch/arm/mach-omap2/clockdomains_common_data.c | 24 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1504
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
7 files changed, 1463 insertions(+), 92 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJPkHV6AAoJEMePsQ0LvSpLJOAQAKi5wXrem3JhunXGUoywuKw/
/qy8Fy+s392JWzRla9c0+3Wn0MmcmSECdHFP49j1kiGrK2Nd3DpYQA4artkRKvlD
G9XhUYoxoV3cf6/b7QlMVxz2NHtm5BvhNPiwGOgMpyqPr121CaNihjcjyyzOl6nQ
006BUUWuxACwe5wBtqWa2CA4TLM+8+D/edtpTcrMBLgpfMqjQ2m4RwIgjV5A3D/h
KfSIrfaXe2xXEcIjqoGghsEesUThvw7GrKeP3Kde1cQKjR7inz1QrdjuKYG7RB5L
DrxWAZFyPY6aoo1QheiCaw8BpFWhX1sI43Wz6TUE5vOfLqwWoZk4lnMz2rS6KelJ
zRy/cmHzeMGY0j1o+VlYh80WHEl/sqOurIxsN0rJey1c/KRJURR8qmmPkRbyxsvD
hoLhFpP6Uh0CVJubayi/UPr+kUZZNYCLIpU8WBHa5Dqf8ID6NB7TbqgVTCIt86y7
r2kXOoF27KLXdZMundElcNGWuI906t/UbFt1x6KgIUO0mYCmjA8XymgoEWKCkzDv
oiWxHsECT/lRS2M9KGrQHzQsV9Uc/UmFH2bkPKLoA0zJpDrOViWYDroezp7i3kB9
cwaTyb2jilTRR+AIghGvhLFIh5PSAJZoIBcQEhWHykG+kL+NLXRRaVrtPBB6NSMQ
aFxSceVcuSynFrRe8IvN
=sO30
-END PGP SIGNATURE-
Re: [PATCH v2 4/8] ARM: OMAP2+: hwmod: revise hardreset behavior
Hi Paul, On Thu, Apr 19, 2012 at 2:46 PM, Paul Walmsley p...@pwsan.com wrote: Hi Benoît, On Thu, 19 Apr 2012, Cousson, Benoit wrote: On 4/19/2012 7:17 PM, Paul Walmsley wrote: On Thu, 19 Apr 2012, Cousson, Benoit wrote: The concern of the people doing SW in these embedded processors was mainly because we were releasing the reset of processor without loading any SW first and thus the processor was executing some random instructions. So if we consider a better hwmods definition, we can potentially fix the MMU case: 'mmu_ipu': 'rst_ipu_mmu_cache' 'mmu_dsp': 'rst_dsp_mmu_cache' 'iva_config': 'rst_logic' Wouldn't these still be pseudo-hwmods? Or do each of these actually have address space, interconnect ports, etc.? Yes, these ones are the only real IPs for MPU stand point, with interconnect port and configuration registers. These are the MMUs documented in Chapter 20 of the OMAP4430 TRM vX, right? I don't really understand the interaction of the hardreset lines with these IPs. Chapter 20 doesn't seem to mention the PRCM-controllable hardreset lines at all. It only mentions the OCP_SYSCONFIG registers associated with them. Meanwhile Table 3-375 RM_DSP_RSTCTRL mentions a DSP MMU, cache, and slave interface reset line. Is that referring to the same MMU that is mentioned in Chapter 20? The end of Section 20.2 MMU Integration mentions two different DSP MMUs, a shared cache MMU and an L2 MMU - maybe the hardreset line only pertains to the first MMU? I don't thinks so, because trying to read the L2 MMU registers with DSP RST2 asserted causes an L3 error. DSP's shared cache MMU refers to section 5.3.2.5 Attribute MMU which is inside the dsp megamodule, OTOH L2 MMU refers to section 5.3.4 MMU, the latter is the one being referenced in section 20. But then we do have the processor resets that have to be exposed somewhere. 'ipu': 'rst_cpu0' 'rst_cpu1' 'dsp': 'rst_dsp' 'iva': 'rst_seq1' 'rst_seq2' None of these one should be controlled automatically. Don't we still want to put these IP blocks into reset until a driver for these IP blocks is loaded? Yes, indeed, my point is where are we going to declare these reset lines if we do not have any fake hwmods to store them. Wouldn't we associate them with the processor hwmods? e.g., omap44xx_iva_hwmod, omap44xx_dsp_hwmod ? Well, for the MMU we can, these are regular IPs (almost). The real issues was for the processors. Omar, do you know how these hardreset lines interact with the MMUs described in the TRM Chapter 20? For M3, RM_MPU_M3_RSTCTRL[2].RST3 releases both the cache and mmu interfaces, this one is needed if you want to program the mmu by touching any of the MMU registers, typical initialization is to deassert this line and then enable the M3 clock (since it is shared with its MMU) which should allow the reset to complete *only* after the clock has been enabled. For DSP, RM_DSP_RSTCTRL[1].RST2 it also releases dsp, cache and mmu (however the dsp doesn't boot until RST1 is deasserted), it is the same rationale as above; you deassert RST2, enable dsp clock (so reset can complete) and then program mmu. Touching any mmu registers without deasserting its reset line (even if the associated clock is ON) generates a L3 error. This can be found in 3.5.6 Reset sequences for DSP and M3. Regards, Omar -- 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 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Vaibhav Hiremath hvaib...@ti.com writes:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Also, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use kernel parameter (clocksource=) to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
[...]
@@ -285,7 +273,32 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static int __init omap2_sync32k_clocksource_init(void)
+{
+ int res;
+ u32 pbase, size;
+ struct omap_hwmod *oh;
+ struct resource mem_rsrc;
minor nit: personaly, I find 'rsrc' hard on the eyes. I suggest just
using 'res' for this variable name.
+ const char *oh_name = counter_32k;
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh || oh-slaves_cnt == 0)
+ return -ENODEV;
+
+ res = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM,
+ NULL, mem_rsrc);
+ if (!res) {
+ pbase = mem_rsrc.start + OMAP2_32KSYNCNT_CR_OFF;
+ size = mem_rsrc.end - mem_rsrc.start;
This should be (end - start + 1), but instead, use the resource_size()
helper should be used for this.
Also note that because you're adding an offset of 0x10 to the start, the
ioremap later is actually mapping 0x10 past the end. More on the base
address later...
+
+ res = omap_init_clocksource_32k(pbase, size);
+ }
+
+ WARN_ON(res);
Just use pr_warn() here instead of WARN_ON() which will dump a full
backtrace, and isn't necessary.
[...]
@@ -510,3 +541,28 @@ static int __init omap2_dm_timer_init(void)
return 0;
}
arch_initcall(omap2_dm_timer_init);
+
+/**
+ * omap2_override_clocksource - clocksource override with user configuration
+ *
+ * Allows user to override default clocksource, using kernel parameter
+ * clocksource=gp timer
+ *
+ * Note that, here we are using same standard kernel parameter
clocksource=,
+ * and not introducing any OMAP specific interface.
+ */
Are you sure the clocksource= setup function is getting called in
kernel/time/clocksource.c as well? IOW, do both the generic one and
this one get called?
To be honest, I still don't like this. The clocksource core will
already sets the right clocksource, and this is duplicating that.
I do see why you're doing this though because both clocksource init
functions call setup_sched_clock().
Ideally, we would just wait to call setup_sched_clock() until later
(possibly in a late_initcall) after the clocksource selection is
decided. I'm not sure we have the right hooks to do that though.
Possibly by setting a flag in the -enable method of each clocksource,
and checking that in a late_initcall before calling setup_sched_clock.
That would be easy for the GP timer, but the 32k timer is setting up an
mmio clocksource, so we don't have an -enable method.
Any other ideas?
[...]
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index 5068fe5..bd4a3fd 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -35,8 +35,6 @@
*/
static void __iomem *timer_32k_base;
-#define OMAP16XX_TIMER_32K_SYNCHRONIZED
Re: [GIT PULL] ARM: OMAP2+: hwmod cleanup series for 3.5
* Paul Walmsley p...@pwsan.com [120419 11:02]: Hi Tony, The following changes since commit 1f5e6247ca99287bac87aff4971a7eee9c2b223a: ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface (2012-04-13 05:28:34 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-cleanup-b-for-3.5 for you to fetch changes up to 3af35fbcd088e0b675fa423a879c596384894180: ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP (2012-04-19 04:25:08 -0600) Clean up various aspects of the OMAP hwmod code, which is the IP block control code for OMAP SoCs. In particular, this series results in a considerable diffstat savings by changing the way that IP block interconnections are defined. Thanks pulling this into cleanup-hwmod and merging into linux-omap master. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: hwmod data: add most of the remaining OMAP4 hwmods
* Paul Walmsley p...@pwsan.com [120419 13:33]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit 3af35fbcd088e0b675fa423a879c596384894180: ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP (2012-04-19 04:25:08 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending tags/omap-devel-a-for-3.5 for you to fetch changes up to 96566043b19ae76d3828ce75cbf28dc6d0bcaaf1: ARM: OMAP4: hwmod data: add DEBUGSS skeleton (2012-04-19 13:33:59 -0600) - Add in most of the remaining hwmods (IP block descriptions) for the OMAP44xx family of SoCs. There still seem to be a few missing, such as those for the MMU IP blocks, but this seems to cover the bulk of the remainder. Thanks merging this into devel-hwmod and merging into linux-omap master. Just for reference, I now have omap-cleanup-a2-for-3.5, omap-cleanup-b-for-3.5 and omap-devel-a-for-3.5 merged, and I've dropped all the earlier branches you posted. So I'm assuming you'll be resending what was in hwmod_misc_devel_3.4, clock_devel_3.4 and io_chain_devel_3.4 once you're done with your fixes/updates for those. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
YUV422 input to CPI?
Hi all, I have a camera module capable of outputting YUV422 over a parallel interface. I've been having some issues interfacing this to a Gumstix. Reading through the OMAP3530 tech ref, I'm now beginning to wonder whether it is actually possible to input YUV422 to the CPI? - Section 12.1.1 mentions RGB and YeCyMgG for image sensors; YUV is only mentioned for CS12. - On the other hand, 12.4.6.1 says that the CCDC accepts YUV data in numerous formats. Is anyone able to confirm whether it's possible to input YUV422 to the CPI? Thanks, Simon-- 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
