Hi Mark,
On Fri, Jun 24, 2011 at 20:43:50, Sergei Shtylyov wrote:
+ rproc-priv = dsp_clk;
+
+ psc_base = ioremap(soc_info-psc_bases[0], SZ_4K);
+
+ /* insure local reset is asserted before writing start address */
+ __raw_writel(NEXT_ENABLED, psc_base + MDCTL + 4 *
Tony Lindgren t...@atomide.com writes:
* Tero Kristo t-kri...@ti.com [110622 09:38]:
[...]
+struct omap_prcm_irq __initdata omap_prcm_3xxx_irqs[] = {
+OMAP_PRCM_IRQ(wkup, 0,
+ CHIP_IS_OMAP3430 | CHIP_GE_OMAP3630ES1_1),
+OMAP_PRCM_IRQ(evgenon,
The current selection of the GPTIMER on was result of
a hardware issue in early versions of the Beagleboards
(Ax and B1 thru B4). [1] [2]
Its been long since the hardware issue has been fixed.
This patch uses GPTIMER 1 for all newer board revisions
incl. Beagleboard XM.
[1]
Right, thanks for the file. Here's the patch.
--- omap2plus-cpufreq.c~2011-06-24 15:50:32.0 +0100
+++ omap2plus-cpufreq.c 2011-06-24 16:00:08.0 +0100
@@ -44,6 +44,16 @@
static char *mpu_clk_name;
static struct device *mpu_dev;
+#ifdef CONFIG_SMP
+struct lpj_info {
+
[CC'ing Liam and Mark as well]
On 24 June 2011 20:07, Jassi Brar jaswinder.si...@linaro.org wrote:
VUSB is a fixed level line and hence have no set_voltage
callback in regulator ops, but has apply_uV set to true.
As a result it fails to register with the regulator core.
Remove setting
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 8:42 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
Hi Alan,
On Thu, 23 Jun 2011, Alan Stern wrote:
On Thu, 23 Jun 2011, Paul Walmsley wrote:
On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
At the moment, isn't it possible for the userspace ioctl PM interface to
freeze processes without going all the way through to a system sleep?
Russell,
On 6/24/2011 8:12 AM, Russell King - ARM Linux wrote:
Right, thanks for the file. Here's the patch.
[.]
Notice how we adjust _both_ the per-cpu loops_per_jiffy, and that we
adjust them with reference to the initial values.
If you adjust lpj with reference to the last, then
On Fri, Jun 24, 2011 at 11:20:44PM +0530, Premi, Sanjeev wrote:
I was able to test BogoMIPS calculations via /proc/cpuinfo for
both with without CONFIG_SMP selected.
For most part things work fine - but I do notice occassional Oops
and segmentation faults while doing cat /proc/cpuinfo
Vishal Mahaveer (1):
omap: blaze: add mmc5/wl1283 device support
arch/arm/mach-omap2/board-4430sdp.c | 81 +++
1 files changed, 81 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
Add MMC5 support on BLAZE, which has the wl1283 device hardwired to.
The wl1283 is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line,
and power-controlled by a GPIO-based fixed regulator.
Based on the patch for zoom by Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Vishal
(Arve cc'ed, also adding Magnus and Kevin back to cc)
Hi Rafael,
On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:
On Thursday, June 23, 2011, Alan Stern wrote:
On Thu, 23 Jun 2011, Paul Walmsley wrote:
On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
Well, the freezing of user space by
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Fri, Jun 24, 2011 at 11:20:44PM +0530, Premi, Sanjeev wrote:
I was able to test BogoMIPS calculations via /proc/cpuinfo for
both with without CONFIG_SMP selected.
For most part things work fine - but I do notice occassional Oops
On 06/21/2011 12:18 AM, Ohad Ben-Cohen wrote:
* Rpmsg: a virtio-based messaging bus that allows kernel drivers to
communicate with remote processors available on the system. In turn,
drivers could then expose appropriate user space interfaces, if needed
(tasks running on remote processors
Tero Kristo t-kri...@ti.com writes:
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt
Tero Kristo t-kri...@ti.com writes:
PRCM interrupt handler will now parse registered pads to see whether there
is an active wakeup event. If this is the case, the corresponding interrupt
will be triggered. This can be used for example with UART driver to register
PAD wakeup event for the UART
Govindraj govindraj...@gmail.com writes:
On Wed, Jun 22, 2011 at 10:12 PM, Tero Kristo t-kri...@ti.com wrote:
PRCM interrupt handler will now parse registered pads to see whether there
is an active wakeup event. If this is the case, the corresponding interrupt
will be triggered. This can be
Tero Kristo t-kri...@ti.com writes:
PRCM interrupts are now handled with the chained handler mechanism. This patch
also changes the PRCM interrupts to be of one-shot type,
Not sure I understand the change to one-shot. But since I don't think
you need the handlers anymore, I don't think this
Tero Kristo t-kri...@ti.com writes:
This is required by OMAP3 as it needs to dynamically unmask events during
idle cycle.
This shouldn't be needed if you move the clearing etc. back into the
PRCM IRQ handler (more on this in [4/6])
Kevin
--
To unsubscribe from this list: send the line
Tero Kristo t-kri...@ti.com writes:
Signed-off-by: Tero Kristo t-kri...@ti.com
You should put 'TEMP' or something similar in the subject of 5/6 and 6/6
since those are only needed without the full conversion from Govindraj.
If Govindraj is able to validate the rest of this series with his
On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote:
...
As I understand it, in the original Android implementation, the hardware
that they were using didn't have fine-grained power management. So
system-wide suspend made more sense in that context. But that shouldn't
be
Govindraj.R govindraj.r...@ti.com writes:
Cleanup serial.c file in preparation to addition of runtime api's in
omap-serial
file. Remove all clock handling mechanism as this will be taken care with
pm runtime api's in omap-serial.c file itself.
1.) Remove omap-device enable and disable. We
Govindraj.R govindraj.r...@ti.com writes:
The pad values here are same as the default pad values updated in
serial.c file.
Avoid structure duplication and use default pads.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
This should be folded in with [03/12]
Kevin
--
To unsubscribe from
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
Please make this part a separate patch.
2.) Moving context_restore func to driver from serial.c
3.) Adding
Govindraj.R govindraj.r...@ti.com writes:
Acquire console lock before enabling and writing to console-uart
to avoid any recursive prints from console write.
for ex:
-- printk
-- uart_console_write
-- get_sync
-- printk from omap_device enable
Govindraj.R govindraj.r...@ti.com writes:
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is
Govindraj.R govindraj.r...@ti.com writes:
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side
Govindraj.R govindraj.r...@ti.com writes:
Use resume idle call from prcm_irq to enable uart_port from low power states.
Comment is valid for OMAP3 but not for OMAP2. Maybe [01/12] should just
leave this call in for OMAP2 instead of having to add it back here?
Add api to check pad wakeup
Govindraj.R govindraj.r...@ti.com writes:
Prior to this patch the uart_clock was cut using prepare/resume calls since
these funcs are no more available with runtime changes use has_async_wake
flag to keep clock active during bootup otherwise uart port will disabled
during boot-up and cannot
Hi,
This is the first attempt in making the omap mailbox framework generic
enough to support other mailbox drivers, in this series the way the mailbox
are defined and registered is changed to support requests of mailboxes through
an id. So far, the mailbox static declarations have been removed
Define number of mailboxes available to a specific chip.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
Use hwmod data attributes to get the defined number of mailboxes on
our current chip, and pass it through platform data.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git
Use omap_XXX as the OMAP device naming convention.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/mailbox.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Move API functions to common framework like save/restore_ctx,
enable/disable_irq instead of being under a header file. While
at it dropping their static inline declarations.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h | 35
So far, mailbox architecture dependent implementations have contained
static declarations for its supported mailbox and users, this has
affected the framework by extending the requests to match the hardcoded
names and only support the known users.
These changes try to provide a more generic
Remove mailbox static declarations, while at it, simplify the macros
to be reused in a cleaner way.
New approach configures available mailboxes per request.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap1/mailbox.c | 92 -
1
Remove mailbox static declarations which limit the driver to
either work with 1 or 2 predefined mailboxes, even if there are
more mailboxes in hardware.
New approach configures available mailboxes per request.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
2011/6/25 Arve Hjønnevåg a...@android.com:
On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley p...@pwsan.com wrote:
...
As I understand it, in the original Android implementation, the hardware
that they were using didn't have fine-grained power management. So
system-wide suspend made more
On Fri, Jun 24, 2011 at 2:31 AM, Jassi Brar jassisinghb...@gmail.com wrote:
The commit
7e6502d577106fb5b202bbaac64c5f1b065 'mfd: Add omap-usbhs runtime PM support'
besides moving to RPM, removes necessary TLL initialization as well.
Restore the TLL initialization, without which device
Russell King - ARM Linux wrote:
s3c_cpu_save does not need to save any registers with the new
cpu_suspend calling convention. Remove these redundant instructions.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested-by: Kukjin Kim kgene@samsung.com
It works fine on Samsung
On 24 June 2011 11:52, Munegowda, Keshava keshava_mgo...@ti.com wrote:
On Fri, Jun 24, 2011 at 2:31 AM, Jassi Brar jassisinghb...@gmail.com wrote:
The commit
7e6502d577106fb5b202bbaac64c5f1b065 'mfd: Add omap-usbhs runtime PM support'
besides moving to RPM, removes necessary TLL
Russell,
Just a minor remark:
On Thu, Jun 23, 2011 at 9:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Convert sa11x0 to use the generic CPU suspend/resume support, rather
^^^ should be 'OMAP3'
than implementing its own version. Tested on 3430 LDP.
On Fri, Jun 24, 2011 at 09:37:03AM +0200, Jean Pihet wrote:
Russell,
Just a minor remark:
On Thu, Jun 23, 2011 at 9:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Convert sa11x0 to use the generic CPU suspend/resume support, rather
^^^ should be 'OMAP3'
Hi Russell,
On Thu, Jun 23, 2011 at 9:09 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Version 3.
Currently cpu_suspend is not like a normal C function - when it's called
it returns normally to a bunch of code which is not expected to return.
The return path is via code pointed
On Thu, Jun 23, 2011 at 05:16:14PM -0700, Kevin Hilman wrote:
Applies on top of Russell's suspend cleanup/rejig, and available
(along with Russell's series) in my pm-wip/idle-suspend branch.
Russell, since it depends on your series, feel free to add it to your
series if you like. Or if you
Kevin,
On Fri, Jun 24, 2011 at 2:16 AM, Kevin Hilman khil...@ti.com wrote:
Upon return from off-mode, the ROM code jumps to a restore function
saved in the scratchpad. Based on SoC revision or errata, this
restore entry point is different. Current code uses some helper
functions in
Hi Kevin,
On Fri, Jun 24, 2011 at 2:17 AM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
Can you rebase/retest this on top of my pm-wip/idle-suspend branch,
which now contains Russell's major cleanup to use the common code as
well as an additional patch from me to remove the unncessary
Current implementation was using goto to get to a basic
if..else structure - but wasn't too obvious on first few
reads.
Once the code was restructured, the relation between the
calls to cpufreq_scale() and cpufreq_notify_transition()
became obvious. And small trip to drivers/cpufreq/cpufreq.c
On Fri, Jun 24, 2011 at 04:05:42PM +0530, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated before calling
cpufreq_notify_transition().
However, generic cpufreq driver adjusts the jiffies as well.
Double adjustment leads to incorrect value being assigned to
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy
On Fri, Jun 24, 2011 at 04:18:31PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Hi Paul,
Here is the series that finally add the management of the modulemode
directly from hwmod fmwk instead of using a fake clock node to represent
the IP.
A second series will clean most of the remaining data from the clock data
file. Before that I have to rebase Rajendra's series to control
At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 34 +-
In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might
The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module
Since the clkdm is now part of the omap_hwmod structure, there is no need
to retrieve it from the main_clock or interface clock.
The code can be simplified a little bit with a direct access.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak
It is mandatory to wait for a module to be in disabled state before
potentially disabling source clock or re-asserting a reset.
omap_hwmod_idle and omap_hwmod_shutdown does not wait for
the module to be fully idle.
Add a cm_xxx accessor to wait the clkctrl idle status to be disabled.
Fix
The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module
The new prminst_xxx accessors based on partition and offset
is now used, so removed all the previous prcm_xxx accessors.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 37
The warm reset function was still using the obsolete API.
Replace it by the new one and move the file to the proper c file.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 15
The interconnect modules were using a slightly different layout than
the regular modules.
Align the layout for better consitency.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 48
Add a 'context_offs' entry in the prcm.omap4 structure to all
IPs when applicable.
The offset will be used to retrieve the per module context lost
information now available on OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
In OMAP4, a new programming model based on module control instead
of clock control was introduced.
Expose two APIs to allow the upper layer (omap_hwmod) to control
the module mode independently of the parent clocks management.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
Take advantage of the explicit modulemode control to fix
the way parents clocks are managed.
A module must be disabled before any parents are disabled.
That programming model was not possible with the previous
implementation that was considering a modulemode as a leaf
clock node managed by the
From: Nayak, Rajendra rna...@ti.com
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:22 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy
On Fri, Jun 24, 2011 at 02:16:54AM +0530, Jassi Brar wrote:
Define dummy set_voltage callback for fixed lines,
without which voltage constraints fail to apply.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
No, this isn't sensible - fixed voltage regulators aren't an unusual
property
Hi Paul Rajendra,
Here is an updated version of the series started by Rajendra.
I had to update it because this series is mandatory for the hwmod
modulemodule control series.
I rebased it on top of the various fixes done on hwmod framework
and to take advantage of the new clkdm attribute in
From: Nayak, Rajendra rna...@ti.com
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
From: Nayak, Rajendra rna...@ti.com
Add the SoC specific implemenation for clkdm_is_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12
arch/arm/mach-omap2/clockdomain44xx.c |7 +++
2 files
From: Nayak, Rajendra rna...@ti.com
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a
From: Nayak, Rajendra rna...@ti.com
Since MMC driver is yet to be adapted to
runtime PM and still uses direct clock
calls to enable/disable module, its needed
that the clockdomain (for MMC) is always kept force
enabled since the next few patches move
the clockdomain handling from clock framework
Duplicate the existing API for clockdomain enable from clock to enable
a clock domain from hwmod framework.
This will be needed when the hwmod framework will move from the current
clock centric approach to the module based approach.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
From: Nayak, Rajendra rna...@ti.com
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired module mode to enable or auto
-4- Wait for the desired module idle status to be FUNC
-5- Program
From: Nayak, Rajendra rna...@ti.com
sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH1
This causes the function to wrongly program
Grrr, one patch escaped from the next series and ended up here...
Nayak, Rajendra (1):
OMAP2+: clockdomain: Add an api to read idle mode
That one was re-sent in the proper series:
[PATCH v2 0/7] Fix module-mode enable sequence on OMAP4
The GIT trees are correct.
Benoit
--
To
Sanjeev,
On 6/24/2011 4:21 PM, Russell King - ARM Linux wrote:
On Fri, Jun 24, 2011 at 04:18:31PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc:
On 6/24/2011 4:05 PM, Sanjeev Premi wrote:
This patch replaces the use of goto with simple
if...else syntax. No change in functionality.
This also means that the comment describing the
dependency between CONFIG_SMP and calculation
of loops_per_jiffy can be unified.
Signed-off-by: Sanjeev
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:16 PM
To: Russell King - ARM Linux
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:18 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
On 6/24/2011 4:05 PM, Sanjeev Premi wrote:
On 6/24/2011 6:24 PM, Premi, Sanjeev wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:18 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
On
On 6/24/2011 6:22 PM, Premi, Sanjeev wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:16 PM
To: Russell King - ARM Linux
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:29 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
On 6/24/2011 6:24 PM, Premi, Sanjeev wrote:
On 24 June 2011 16:49, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
On Fri, Jun 24, 2011 at 02:16:54AM +0530, Jassi Brar wrote:
Define dummy set_voltage callback for fixed lines,
without which voltage constraints fail to apply.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
On 6/24/2011 5:06 AM, Benoit Cousson wrote:
Hi Paul Rajendra,
Here is an updated version of the series started by Rajendra.
I had to update it because this series is mandatory for the hwmod
modulemodule control series.
I rebased it on top of the various fixes done on hwmod framework
and to
On 6/24/2011 3:23 PM, Nayak, Rajendra wrote:
On 6/24/2011 5:06 AM, Benoit Cousson wrote:
Hi Paul Rajendra,
Here is an updated version of the series started by Rajendra.
I had to update it because this series is mandatory for the hwmod
modulemodule control series.
I rebased it on top of the
Currently, loops_per_jiffy is being calculated twice for
non-SMP processors.
- Before calling cpufreq_notify_transition()
- From within cpufreq_notify_transition()
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy. This manifests as incorrect BogoMIPS in
cat
-Original Message-
From: Premi, Sanjeev
Sent: Friday, June 24, 2011 7:24 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Premi, Sanjeev
Subject: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy
calculation
Currently, loops_per_jiffy is being
On 6/24/2011 7:23 PM, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated twice for
non-SMP processors.
- Before calling cpufreq_notify_transition()
- From within cpufreq_notify_transition()
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy. This
VUSB is a fixed level line and hence have no set_voltage
callback in regulator ops, but has apply_uV set to true.
As a result it fails to register with the regulator core.
Remove setting apply_uV.
Also, assign name to VUSB supply, without which regulator core
fails to find it and assigns the
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
In order to implement the new class in PM QoS the following changes have been
made:
1. Add a new PM QoS class for device wake-up constraints
(PM_QOS_DEV_WAKEUP_LATENCY).
Due to the per-device nature of
From: Jean Pihet j-pi...@ti.com
Add the field wakeup_lat_plist_head in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/base/power/main.c |
From: Jean Pihet j-pi...@ti.com
- add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
constraints. Due to the per-device nature of the new class the constraints
list is stored inside the device dev_pm_info struct instead of the internal
per-class constraints lists.
The new class
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
From: Vishwanath BS vishwanath...@ti.com
This patch adds wake up latency numbers for OMAP4. Note that these are
preliminary numbers and need to be relooked.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
The INACTIVE state is added as unsupported.
Tested on OMAP4 Pandaboard in RET/OFF using
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using a PM QoS
notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently is
a
From: Jean Pihet j-pi...@ti.com
When a wake-up latency constraint is requested or removed the PM QoS
layer notifies the underlying layer with the updated strongest constraint
value. The constraint is stored in the powerdomain constraints list
and then applied to the corresponding power domain.
From: Jean Pihet j-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and target_residency
figures.
The rest of the power domains get their next power state programmed
from the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS
1 - 100 of 108 matches
Mail list logo
