On Thu, Jan 26, 2012 at 05:23:30, john stultz wrote:
On Wed, 2012-01-18 at 16:58 +0530, Vaibhav Hiremath wrote:
+/**
+ * read_persistent_clock - Return time from a persistent clock.
+ *
+ * Reads the time from a source which isn't disabled during PM, the
+ * 32k sync timer. Convert
Hi,
On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the
This series optimizes some of the powerdomain-related code in
arch/arm/mach-omap2/pm*, and fixes a bug or two. These were noticed while
working on the functional powerstate code.
Rajendra and Santosh, if you have a spare moment, could you please
peek at the OMAP4 LOWPOWERSTATECHANGE part of the
Clean up a few different parts of omap_set_pwrdm_state():
- Remove a superfluous call to pwrdm_state_switch(). Not needed
unless LOWPOWERSTATECHANGE is used, because the state switch code is
called by either clkdm_sleep() or clkdm_allow_idle().
- Add code to wait for the power state
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no
need to do it twice.
N.B.: some of us have observed that accesses to the previous
powerstate
On 01/29/2012 12:57 AM, Olof Johansson :
Hi,
On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
And we're now there. So...
Arnd, Olaf,
Please incorporate the latest ARM (for-armsoc branch) changes, which can be
found at:
This series does some cleanup and documentation on the OMAP hwmod code
(and a bit of the OMAP4 data) and timer code. It is the first
prerequisite series to removing a big chunk of hwmod data -- that will
be done in a later series.
Boot-tested on an OMAP35xx BeagleBoard and OMAP44xx ES2
Parts of the hwmod code test to see if a module has one and only one
hardreset line before taking an action. It seems more appropriate
to control all hardreset lines associated with a hwmod, not just one.
It so happens that with the current hwmod data, this will not change
any behavior, since
A subsequent patch will need to know the struct omap_hwmod_addr_space
record corresponding to the module's register target, used by the MPU.
So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then
modify its sole current user, _populate_mpu_rt_base(), to extract the
MPU RT base
Split the interface clock setup from _setup() into
_setup_iclk_autoidle() and split the post-setup state code from
_setup() into _enter_postsetup_state(). Fix the existing, incorrect
documentation for _setup(), and add documentation for the other two
functions. The goal is to shrink the size of
arch/arm/mach-omap2/timer.c pokes around inside the hwmod data
structures. Since the hwmod data structures are about to change, this
code will break. This patch modifies the timer code to use
recently-added hwmod functions instead.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren
Remove the pseudo-hwmods associated with hardreset lines from the
OMAP4 data file. Future patches will convert this data to register
hwmods by interfaces, rather than registering hwmods directly; and
these pseudo-hwmods aren't associated with any interfaces.
The hwmod code now resets processor
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.
The timer integration code pokes around in hwmod data structures.
Those data structures are about to change. Define some functions for
the timer integration code to use instead.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.
On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei ming@canonical.com wrote:
Hi,
On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
eran...@googlemail.com wrote:
On Mon, Jan 30, 2012 at 3:13 PM, Paul Walmsley p...@pwsan.com wrote:
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no
need to do it twice.
Hello Steve,
on 01/27/2012 03:09 PM Steve Sakoman said the following:
On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold hun...@linuxtv.org wrote:
Your summary below is a pretty accurate description of the current state.
Ok.
I've made an attempt at creating a patch for 3.2 that follows David
On Tue, 2012-01-24 at 09:06 +, Russell King - ARM Linux wrote:
However, the bug made it into the 3.3 merge window, so shouldn't this
bugfix be sent upstream immediately?
David is the MTD maintainer, and Artem just helps out. I believe Artem
is waiting for David to finish travelling
On Mon, Jan 30, 2012 at 3:13 PM, Paul Walmsley p...@pwsan.com wrote:
Clean up a few different parts of omap_set_pwrdm_state():
- Remove a superfluous call to pwrdm_state_switch(). Not needed
unless LOWPOWERSTATECHANGE is used, because the state switch code is
called by either clkdm_sleep()
Same results for me with 3.3.0-rc1 + 5 patches.
top - 14:42:34 up 8 min, 1 user, load average: 0.70, 0.29, 0.15
Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie
Cpu(s): 32.9%us, 1.3%sy, 0.0%ni, 65.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 940232k total, 118520k
On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
eran...@googlemail.com wrote:
Same results for me with 3.3.0-rc1 + 5 patches.
In fact, I think the only effect of the patch is to enable pmu
interrupt handling,
which may cause so much difference?
Also maybe you should put 'noploop' to run on
Same result for me on CPU1:
top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:940232k total, 228984k used, 711248k free,
stephane eranian eran...@googlemail.com writes:
Same result for me on CPU1:
top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Hi,
* Paul Walmsley p...@pwsan.com [120130 01:47]:
The timer integration code pokes around in hwmod data structures.
Those data structures are about to change. Define some functions for
the timer integration code to use instead.
Maybe these should use struct resource instead to make these
2012/1/24 Felipe Contreras felipe.contre...@gmail.com:
2012/1/23 Víctor Manuel Jáquez Leal vjaq...@igalia.com:
Uppercase function names are not pretty. Also the code flow readability is
enhanced.
Looks good to me.
FWIW, I agree.
Regards,
Omar
--
To unsubscribe from this list: send the line
On Mon, Jan 30, 2012 at 5:08 PM, Måns Rullgård m...@mansr.com wrote:
stephane eranian eran...@googlemail.com writes:
Same result for me on CPU1:
top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s):
2012/1/24 Felipe Contreras felipe.contre...@gmail.com:
2012/1/23 Víctor Manuel Jáquez Leal vjaq...@igalia.com:
No functional changes.
The header file drv_interface.h was only used locally, hence there's no need
to have it.
Also the only prototyped functions were the file_operations
On Mon, Jan 30, 2012 at 05:15:53PM +, stephane eranian wrote:
Still need to investigate why the frequency mode does
not yield the correct number of samples even with low frequency.
$ taskset -c 1 perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
Aggregated stats:
2012/1/23 Víctor Manuel Jáquez Leal vjaq...@igalia.com:
No functional changes.
According to Lindent, the file drv_internface.c had some lines with bad
indentation.
This commit is the output of Lindent.
Usually lindent tends to do whatever it wants, unless carefully configured...
...
@@
2012/1/23 Víctor Manuel Jáquez Leal vjaq...@igalia.com:
Silence the warning when compiling drv_interface.c
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
On Tue, Jan 24, 2012 at 3:25 PM, Joe Perches j...@perches.com wrote:
tidspbridge when built as a module is named bridgedriver.
bridgedriver is not a particularly good module name.
tidspbridge is what the source is named. That seems
a more appropriate module name too as it describes
the
Will,
There you go, no attachment, not sure the omap list
supports this.
There is something quite interesting to observe.
While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number of interrupts is way lower than
expected. Therefore the number of samples is way
On Mon, Jan 30, 2012 at 7:34 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
On Tue, Jan 24, 2012 at 3:25 PM, Joe Perches j...@perches.com wrote:
tidspbridge when built as a module is named bridgedriver.
bridgedriver is not a particularly good module name.
tidspbridge is what the source is
On Mon, Jan 30, 2012 at 11:25:34AM -0600, Ramirez Luna, Omar wrote:
2012/1/23 Víctor Manuel Jáquez Leal vjaq...@igalia.com:
No functional changes.
According to Lindent, the file drv_internface.c had some lines with bad
indentation.
This commit is the output of Lindent.
Usually
Paul Walmsley p...@pwsan.com writes:
[ This series is targeted for merging during v3.3-rc ]
Hi
Here's an updated version of OMAP serial bugfix series against v3.3-rc1.
This revision has:
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Tested on 3430/n900,
On Mon, Jan 30, 2012 at 05:45:19PM +, stephane eranian wrote:
There you go, no attachment, not sure the omap list
supports this.
Cheers Stephane.
There is something quite interesting to observe.
While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number
On Mon, Jan 30, 2012 at 11:25:34AM -0600, Ramirez Luna, Omar wrote:
+ pr_info(%s:%d handle(s) still opened\n, __func__,
+ atomic_read(bridge_cref));
I remember the rule was to break lines as far to the right as
possible, no? Chapter 2
Grazvydas Ignotas nota...@gmail.com writes:
Hi,
On 3.2 (I think some earlier versions too), with CONFIG_CPU_IDLE
enabled GPIO based buttons are not working properly on OMAP3 pandora,
button presses are almost never registered. The buttons are connected
GPIO bank4 and have hardware debounce
On Mon, 2012-01-30 at 22:29 +0300, Dan Carpenter wrote:
On Mon, Jan 30, 2012 at 11:25:34AM -0600, Ramirez Luna, Omar wrote:
+ pr_info(%s:%d handle(s) still opened\n,
__func__,
+ atomic_read(bridge_cref));
I remember the rule was to
On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote:
sorry for the delay, just caught this during a list sweep. The maintainer
of the OMAP4 hwmod data is Benoît, so I'd suggest cc'ing him for OMAP4
hwmod data requests.
No worries and thanks for the reply.
On Wed, 4 Jan 2012,
On Mon, Jan 30, 2012 at 11:53:00AM -0800, Joe Perches wrote:
On Mon, 2012-01-30 at 22:29 +0300, Dan Carpenter wrote:
On Mon, Jan 30, 2012 at 11:25:34AM -0600, Ramirez Luna, Omar wrote:
+ pr_info(%s:%d handle(s) still opened\n,
__func__,
+
On Mon, 2012-01-30 at 21:33 +0100, Víctor M. Jáquez L. wrote:
On Mon, Jan 30, 2012 at 11:53:00AM -0800, Joe Perches wrote:
I've done a patch here to tidspbridge that standardizes
printk output.
Basically, the patch adds
#define pr_fmt(fmt) KBUILD_MODNAME %s: , __func__
to prefix
On Mon, Jan 30, 2012 at 8:14 PM, Will Deacon will.dea...@arm.com wrote:
On Mon, Jan 30, 2012 at 05:45:19PM +, stephane eranian wrote:
There you go, no attachment, not sure the omap list
supports this.
Cheers Stephane.
There is something quite interesting to observe.
While I run perf
Paul Walmsley p...@pwsan.com writes:
This series optimizes some of the powerdomain-related code in
arch/arm/mach-omap2/pm*, and fixes a bug or two. These were noticed while
working on the functional powerstate code.
Rajendra and Santosh, if you have a spare moment, could you please
peek at
Hi
On Mon, 30 Jan 2012, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120130 01:47]:
The timer integration code pokes around in hwmod data structures.
Those data structures are about to change. Define some functions for
the timer integration code to use instead.
Maybe these
Hello,
Tasslehoff Kjappfot tasskj...@gmail.com writes:
It was removed in:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=98e182a26bbbf5575457622337684ef61493e864
The commit message says a bit about what was done, but not why.
The reason why was because the way it
cc Peter, Liam, Kevin, Mike
On Mon, 30 Jan 2012, Marc Butler wrote:
On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote:
The driver shouldn't have any hwmod code in it. Any
omap_device/omap_hwmod code that's needed should go into an appropriate
file in arch/arm/mach-omap2.
Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables. Remove it.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Paul, now that the CPUfreq driver is in mainline (v3.3), this can be safely
removed.
On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
Hi,
On 3.2 (I think some earlier versions too), with CONFIG_CPU_IDLE
enabled GPIO based buttons are not working properly on OMAP3 pandora,
button presses are almost never
On Mon, 30 Jan 2012 00:57:13 +0200 Grazvydas Ignotas nota...@gmail.com
wrote:
Hello,
I've been trying to get suspend working with musb compiled in on 3.2.
It seems both patches from this thread are needed, Kevin's patch stops
omap2430_runtime_suspend() from being called at inappropriate
On Monday, January 30, 2012, Artem Bityutskiy wrote:
On Tue, 2012-01-24 at 09:06 +, Russell King - ARM Linux wrote:
However, the bug made it into the 3.3 merge window, so shouldn't this
bugfix be sent upstream immediately?
David is the MTD maintainer, and Artem just helps out. I
I'm trying to learn how to contribute to the kernel and dsp/bridge is
a module that I have used for a while.
These patches are the result of this first effort. It is a clean up of
the file drv_interface.c which is the entry point of the kernel
module.
Thanks
v2:
* Removed changes in lines with
No functional changes.
The header file drv_interface.h was only used locally, hence there's no need
to have it.
Also the only prototyped functions were the file_operations callbacks, then
this commit moves them up to avoid prototyping too.
Signed-off-by: Víctor Manuel Jáquez Leal
Instead of assign it to a global variable which is not used anymore.
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
The variable offset is not used but in the debug log, so I don't see reason to
calculate it here.
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git
The function dsp_deinit() always return true, so assert its output is
pointless. As consequence the variable were the returned value is stored, is
no longer needed.
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |4 +---
1
Silence the warning when compiling drv_interface.c
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/drv_interface.c
Hi Paul,
Paul Walmsley p...@pwsan.com writes:
This series does some cleanup and documentation on the OMAP hwmod code
(and a bit of the OMAP4 data) and timer code. It is the first
prerequisite series to removing a big chunk of hwmod data -- that will
be done in a later series.
Boot-tested
No functional changes.
According to Lindent, the file drv_internface.c had some lines with bad
indentation.
This commit is the output of Lindent.
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 12 ++--
1 files
drv_interface.c include several header files that are not really used.
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git
Uppercase function names are not pretty. Also the code flow readability is
enhanced.
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
Hi,
On 3.2 (I think some earlier versions too), with CONFIG_CPU_IDLE
enabled GPIO based buttons are not working properly on OMAP3
On Mon, 30 Jan 2012, Kevin Hilman wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On 3.2 (I think some earlier versions too), with CONFIG_CPU_IDLE
enabled GPIO based
On Mon, 30 Jan 2012, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
This series does some cleanup and documentation on the OMAP hwmod code
(and a bit of the OMAP4 data) and timer code. It is the first
prerequisite series to removing a big chunk of hwmod data -- that will
be
Paul Walmsley p...@pwsan.com writes:
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no
need to do it twice.
It looks like these two for
Paul Walmsley p...@pwsan.com writes:
On Mon, 30 Jan 2012, Kevin Hilman wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On Mon, Jan 30, 2012 at 9:36 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On 3.2 (I think some earlier versions too), with
On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley p...@pwsan.com wrote:
On Mon, 30 Jan 2012, Kevin Hilman wrote:
Grazvydas Ignotas nota...@gmail.com writes:
Hmm but it doesn't work here (OMAP3530 ES2.1), /proc/interrupts
doesn't increase when I hit buttons unless something else is happening
On Tue, Jan 31, 2012 at 2:22 AM, Kevin Hilman khil...@ti.com wrote:
Paul Walmsley p...@pwsan.com writes:
That's probably I/O ring/pad wakeups happening there, not GPIO wakeups.
Gražvydas, you are referring to the case where the CORE powerdomain is on,
but the GPIO IP block is idle?
Right
On Tue, Jan 31, 2012 at 12:37 AM, NeilBrown ne...@suse.de wrote:
1/ I don't know what your problem might be, but I have suspend working
quite well with musb compiled in. CORE goes to RET.
The code is at git://neil.brown.name/gta04 in the 3.2-gta04 branch.
There are various additions and
These patches solve two lingering memory leak scenarios introduced
in tidspbridge code.
1. Due to missing balanced calls during bridge_release deallocation, and
a potential leak in bridge_open because of missing cleanup path.
2. Leaks because of a misuse of an already freed pointer, which
There are two members of pr_ctxt allocated during bridge_open that
are never freed resulting in memory leaks, these are stream_id and
node_id, they are now freed on release of the handle (bridge_release)
right before freeing pr_ctxt.
Error path for bridge_open was also fixed since the same
This structure is still used after it has been freed, since it
is being allocated in probe, calls to free it have been moved to
module's remove routine.
This should fix the follwoing messages when attempting to remove the
module:
drv_get_first_dev_extension: Failed to retrieve the object handle
Hi Gražvydas
On Tue, 31 Jan 2012, Grazvydas Ignotas wrote:
On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley p...@pwsan.com wrote:
So apparently, looking at these references, the following registers should
be configured:
1. at least one of GPIO_LEVELDETECT{0,1} or
On Tue, 31 Jan 2012, Grazvydas Ignotas wrote:
On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley p...@pwsan.com wrote:
So apparently, looking at these references, the following registers should
be configured:
1. at least one of GPIO_LEVELDETECT{0,1} or GPIO_{RISING,FALLING}DETECT
2.
Hi Paul,
On Monday 30 January 2012 03:13 PM, Paul Walmsley wrote:
Clean up a few different parts of omap_set_pwrdm_state():
- Remove a superfluous call to pwrdm_state_switch(). Not needed
unless LOWPOWERSTATECHANGE is used, because the state switch code is
called by either clkdm_sleep()
On Tuesday 31 January 2012 05:44 AM, Kevin Hilman wrote:
Paul Walmsleyp...@pwsan.com writes:
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's
Hi Catalin,
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me that this dicussion
didn't reach a full
On Mon, 30 Jan 2012, Paul Walmsley wrote:
It seems highly suspicious to me that nothing in
set_24xx_gpio_triggering() in our GPIO code seems to touch the
WAKEUPENABLE register.
Heh. Just wanted to follow up on this for anyone who cares. Gražvydas
noticed that the bit was indeed being
On Tue, Jan 31, 2012 at 5:44 AM, Kevin Hilman khil...@ti.com wrote:
Paul Walmsley p...@pwsan.com writes:
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain
Hi
just a few thoughts.
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
In this code the need is to clear only CPU and MPUPD, and hence they are
explicitly cleared since the pre/post transition calls can be moved to
PM_DEBUG
in production kernels.
But as you stated in current mainline
On Mon, 2012-01-30 at 13:27 -0800, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
This series optimizes some of the powerdomain-related code in
arch/arm/mach-omap2/pm*, and fixes a bug or two. These were noticed while
working on the functional powerstate code.
Rajendra and
On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
just a few thoughts.
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
In this code the need is to clear only CPU and MPUPD, and hence they are
explicitly cleared since the pre/post transition calls can be moved to
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
In this code the need is to clear only CPU and MPUPD, and hence they are
explicitly cleared since the pre/post transition
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me
On Tue, Jan 31, 2012 at 12:57 PM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
In this code the need is to clear only CPU and MPUPD,
On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 31 January 2012 05:21, Aneesh V ane...@ti.com wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
On Fri, Jan 20, 2012 at 08:57:11AM +, Joe Woodward wrote:
So I re-iterate that we need to have
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
A week back I was discussing with Benoit and Tony about having some
infrastructure like unused clocks so that we can shutdown those
modules, and if possible some power domains. That way they get
removed at one single place and they the power
87 matches
Mail list logo
