jp.franc...@cynove.com writes:
_enable_preprogram is marked as __init, but is called from _enable which is
not.
This results in oops once init is freed.
Fix this by removing the __init marker.
Signed-off-by: Jean-Philippe François jp.franc...@cynove.com
Acked-by: Kevin Hilman khil
Joel A Fernandes joelag...@ti.com writes:
Calling runtime PM API for every block causes serious perf hit to
crypto operations that are done on a long buffer.
As crypto is performed on a page boundary, encrypting large buffers can
cause a series of crypto operations divided by page. The
Salut Jean-philippe,
jean-philippe francois jp.franc...@cynove.com writes:
Hi list,
Launching program using I2C after init leads to an oops with 3.9 on a
custom dm3730 based board.
Looking at the disassembly of the _enable function in omap_hwmod.o, I
noticed the call to _enable_preprogram
Hi Joel,
Fernandes, Joel A joelag...@ti.com writes:
Hi Kevin,
Thanks for your review.
-Original Message-
From: Kevin Hilman [mailto:khil...@linaro.org]
Sent: Monday, May 13, 2013 11:36 AM
To: Fernandes, Joel A
Cc: linux-cry...@vger.kernel.org; linux-omap@vger.kernel.org; Mark
hvaib...@ti.com
Minor nit below, otherwise...
Reviewed-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/control.h |5 +
arch/arm/mach-omap2/id.c | 13 +
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/soc.h |1 +
4 files changed, 20
.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Based on v3.9-rc8
arch/arm/mach-omap2/omap_device.c | 2 +-
arch/arm/mach-omap2/soc.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch
Hi Alan,
Alan Stern st...@rowland.harvard.edu writes:
Felipe and Kevin:
While removing the remaining usages of USB_SUSPEND (things that I
missed in the original patch), I noticed that
arch/arm/configs/omap2plus_defconfig does not enable PM_RUNTIME -- even
though it currently does enable
Rajendra Nayak rna...@ti.com writes:
From: Santosh Shilimkar santosh.shilim...@ti.com
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
As discussed on the list, in future if dma mode needs to be brought
back to this
.
The series tries to address the issue and tries to remove complete
sysc handling from serial driver.
Other than the minor nit about the order of the series for bisect,
Reviewed-by: Kevin Hilman khil...@linaro.org
Also tested this on OMAP4/Panda where I was having the sluggish console
issues
Sourav Poddar sourav.pod...@ti.com writes:
The driver manages no_console_suspend by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Tony Lindgren t...@atomide.com writes:
* Santosh Shilimkar santosh.shilim...@ti.com [130419 10:56]:
On Friday 19 April 2013 11:14 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130419 10:43]:
On Friday 19 April 2013 10:43 PM, Tony Lindgren wrote:
Hi all,
Here's
Hi Sourav,
Sourav Poddar sourav.pod...@ti.com writes:
Hi Kevin,
On Thursday 25 April 2013 03:45 AM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Remove no_idle_on_suspend check, since respective
driver should be able to prevent idling of a
device whenever required
Sourav Poddar sourav.pod...@ti.com writes:
The driver manages no_console_suspend by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/tty/serial/omap-serial.c | 29
Sourav Poddar sourav.pod...@ti.com writes:
Remove no_idle_on_suspend check, since respective
driver should be able to prevent idling of a
device whenever required.
Driver's can get same behavior by just returning -EBUSY
from their -runtime_suspend only during suspend.
Cc: Santosh
Olof Johansson o...@lixom.net writes:
On Wed, Apr 10, 2013 at 11:14:52AM -0700, Tony Lindgren wrote:
Hi,
Added Olof to cc, I suggest Olof pull this directly as we're starting
to run out of time.
Hi,
I'm terribly sorry for dropping this one on the floor, in spite of repeated
pings from
Andreas Fenkart andreas.fenk...@streamunlimited.com writes:
When a gpio interrupt is masked, the gpio event will still be latched in
the interrupt status register so when you unmask it later you may get an
interrupt straight away. However, if the interrupt is disabled then gpio
events
Grygorii Strashko grygorii.stras...@ti.com writes:
On 04/22/2013 04:43 PM, Sourav Poddar wrote:
The driver manages no_console_suspend by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Grygorii Strashko grygorii.stras...@ti.com writes:
On 04/22/2013 04:43 PM, Sourav Poddar wrote:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since
driver should be able to prevent idling of an omap device
whenever required.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
On 04/18/2013 07:34 PM, Jon Hunter wrote:
On 04/18/2013 06:10 PM, Jon Hunter wrote:
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
...
Why not just init context right here if bank
Sourav Poddar sourav.pod...@ti.com writes:
[...]
Yes, got your point. omap_device_idle should not be called only
for console uart.
Just did a quick testing by including the following hunk on top of my
patch series..
diff --git a/arch/arm/mach-omap2/omap_device.c
Sourav Poddar sourav.pod...@ti.com writes:
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove dependency to set od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and
omap_device.c(dt
Sourav Poddar sourav.pod...@ti.com writes:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only
one making
use of it. Now serial core/driver takes care of the case when
no_console_suspend
is used in the bootargs and you need to keep the clock enable for console
even
Sourav Poddar sourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
Sourav Poddar sourav.pod...@ti.com writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using no_console_suspend in the bootargs.
We can get rid of the previous implementation of setting the od-flags to
Hi Sourav,
Sourav Poddar sourav.pod...@ti.com writes:
Hi,
This patch series contains fixes and cleanups around the issue that
the console UART should not idled on suspend while using no_console_suspend
in bootargs.
The direction of the series is right, thanks for the updated approach.
I
Hi Jon,
Jon Hunter jon-hun...@ti.com writes:
Commit a2797be (gpio/omap: force restore if context loss is not
detectable) broke gpio support for OMAP when booting with device-tree
because a restore of the gpio context being performed without ever
initialising the gpio context. In other words,
Sourav Poddar sourav.pod...@ti.com writes:
Hi Kevin,
On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
The patch adapt the serial core/driver to take care of the case when
no_console_suspend
is used in the bootargs. The patch will remove
Sourav Poddar sourav.pod...@ti.com writes:
On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since UART was the only
one making
use of it. Now serial core/driver takes care of the case when
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
Hi Kevin,
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Following patch series introduces the Adaptive Body-Bias
LDO driver, which
Hi Vaibhav,
Bedia, Vaibhav vaibhav.be...@ti.com writes:
[...]
So, my proposal is that Sourav remove that flag from the AM33xx hwmod
when he removes this feature.
Apologies for the delayed response. I was out of office for a couple of
days.
I don't recall the exact kernel version in which
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike
00d19c10c02c3a3aa99ca7ae75bc88a932437abd Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@linaro.org
Date: Mon, 15 Apr 2013 15:02:26 -0700
Subject: [PATCH] MAINTAINERS: update OMAP GPIO driver: Jon Hunter taking over
Jon has already been doing most of maintenance of this driver, so
make it official.
Cc
Kevin Hilman khil...@linaro.org writes:
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Sourav,
On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
[...]
Yes, had a look at that and found your situation similar to UART.
But how exactly this gets used, I mean I don't see any drivers
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Sourav,
On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
[...]
Yes, had a look at that and found your situation similar to UART.
But how exactly this gets used, I mean I don't see any drivers/ in mainline
making use of this
-08 09:51:00 -0700)
PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
OMAP3/4 CPUidle cleanups for v3.10
Adding Daniel and Rafael to Cc.
Is this series coordinated with the other cpuidle changes
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@linaro.org [130409 09:43]:
Arnd Bergmann a...@arndb.de writes:
On Tuesday 09 April 2013, Tony Lindgren wrote:
The following changes since commit
07961ac7c0ee8b546658717034fe692fd12eefa9:
Linux 3.9-rc5 (2013-03-31 15
Sourav Poddar sourav.pod...@ti.com writes:
Hi Kevin,
On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
With dt boot, uart wakeup after suspend is non functional while using
no_console_suspend in the bootargs. With no_console_suspend used, we
Daniel Lezcano daniel.lezc...@linaro.org writes:
[...]
PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
OMAP3/4 CPUidle cleanups for v3.10
Adding Daniel and Rafael to Cc.
Kevin,
I just want to point you this patch:
https://git.linaro.org/gitweb?p=people
Tony,
Here's the final set of OMAP PM cleanups for v3.10. This is a small set
of cleanups from Santosh to consolidate and prepare for OMAP5 PM additions.
It's based on your cleanup-v2 branch.
Kevin
The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
Merge branch
Rafael,
Please pull the following OMAP CPUidle changes for v3.10.
Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.
Kevin
The following changes since commit
platforms when
device tree nodes are present.
Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
Cc: Kevin Hilman khil...@linaro.org
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous
[resend with correct address for linux-pm]
Rafael,
Please pull the following OMAP CPUidle changes for v3.10.
Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.
Sourav Poddar sourav.pod...@ti.com writes:
With dt boot, uart wakeup after suspend is non functional while using
no_console_suspend in the bootargs. With no_console_suspend used, we
should prevent the runtime suspend of the uart port which is getting used
as an console.
Cc: Santosh
restores in *_runtime_resume()
For the gpio/omap patches
Reviewed-by: Kevin Hilman khil...@linaro.org
--
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
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle
: instantiate cpufreq-cpu0 as a platform_driver)
Cc: Kevin Hilman khil...@linaro.org
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Keerthy j-keer...@ti.com
Cc: Santosh Shilimkar santosh.shilim
Santosh Shilimkar santosh.shilim...@ti.com writes:
As discussed on list, I split the v2 [1] series into cleanup and OMAP5
support.
Thanks.
This series contains the clean-up patches. I have rebased on top of Tony's
pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
Tony,
This OMAP PM fixes tag is based on your cleanup-v2 branch due to some
dependencies in the series from Santosh you already merged.
Kevin
The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
Merge branch 'for_3.10/omap_generic_cleanup_v2' of
Tony,
Please pull the following changes for OMAP CPUidle for v3.10.
Kevin
The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
are available in the git repository at:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
Here is the refreshed version(v2) of the OMAP5 PM suspport
Nishanth Menon n...@ti.com writes:
The following version 3 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the
, Kevin Hilman wrote:
Sourav Poddarsourav.pod...@ti.com writes:
With dt boot, uart wakeup after suspend is non functional on
omap4/5 while using
no_console_suspend in the bootargs. With no_console_suspend
used, od-flags
should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not
allowing
.
This is an suggested solution till we have OMAP clock nodes in device
tree.
Once the OMAP device tree conversion is complete, we can then do:
clocks = dpll_mpu_ck; or the SoC specific equivalent.
Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.
Cc: Kevin
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5
Santosh Shilimkar santosh.shilim...@ti.com writes:
Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
What is broken?
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode
Santosh Shilimkar santosh.shilim...@ti.com writes:
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is
Santosh Shilimkar santosh.shilim...@ti.com writes:
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Santosh Shilimkar santosh.shilim...@ti.com writes:
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for
OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which
Santosh Shilimkar santosh.shilim...@ti.com writes:
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+
Santosh Shilimkar santosh.shilim...@ti.com writes:
When the entire MPUSS cluster is powered down in device off state, L2 cache
memory looses it's content and hence while targetting such a state,
l2 cache needs to be flushed to main memory.
Add the necessary low power code support for the
Santosh Shilimkar santosh.shilim...@ti.com writes:
OMAP4 CPUidle driver registration call is under a loop which leads
to calling cpuidle_register_driver twice which is not intended.
Fix it by moving the driver registration outside the loop.
Reported-by: Nishanth Menon n...@ti.com
Acked-by:
Santosh Shilimkar santosh.shilim...@ti.com writes:
If the CPUidle device registration fails for some reason, we should
unregister the driver on error path.
Fix the code accordingly. Also when at it, check of the driver registration
failure too.
Acked-by: Nishanth Menon n...@ti.com
Santosh Shilimkar santosh.shilim...@ti.com writes:
It is useful to know the CPU power state along with MPUSS power state
in a supported C-state. Since the data is available via sysfs, one can
avoid scrolling the source code for precise construction of C-state.
Reported-by: Nishanth Menon
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle
Santosh Shilimkar santosh.shilim...@ti.com writes:
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
Retention) power states can be achieved with respective power states
on
]
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/common.h | 5 -
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach
Hi Santosh,
Santosh Shilimkar santosh.shilim...@ti.com writes:
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 28 March 2013 01:39 AM, Shilimkar, Santosh wrote:
Sorry for top posting ...
I will pick the ack and update commit log to prepare new pull request
for you.
I have updated the branch picking acks and updating changelogs and same
Santosh Shilimkar santosh.shilim...@ti.com writes:
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.
So, to acommodate both these usage conditions, we fail init of
omap-cpufreq when we boot with device tree.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Santosh Shilimkar santosh.shilim...@ti.com writes:
From: Tero Kristo t-kri...@ti.com
Simplifies code and also allows the re-use as is on OMAP5 devices.
nit: changelog here is rather weak. It claims simplifies code but
it's not obvious from the patch how changing a few #defines does that.
Santosh Shilimkar santosh.shilim...@ti.com writes:
This was added with intial port where OMAP PM support wasn't existing
and only simple WFI based hooks were used.
This should have been cleaned up while adding the PM support but some
how fall through cracks.
Changelog describes a bit of
Santosh Shilimkar santosh.shilim...@ti.com writes:
Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
Why?
While at
it drop the un-necessary sev() and barrier which was under prepare code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
of the proposed workaround but from
power savings perspective, it isn't an ideal workaround.
Cc: Jon Hunter jon-hun...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Nice.
Acked-by: Kevin Hilman khil...@linaro.org
SOCs.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Nice.
Acked-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/pm44xx.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
Why?
Because that code belongs to smp_prepare_cpus(). As I
Hi Nishanth,
Nishanth Menon n...@ti.com writes:
Hi,
The following version 2 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
Sourav Poddar sourav.pod...@ti.com writes:
OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Kevin
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe
for suspend and CPUidle.
Cc: Kevin Hilman khil...@deeprootsystems.com
Reported-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Update changelog to include testing details as suggested
by Kevin Hilman.
Ping.
It can get into rc's
Jon Hunter jon-hun...@ti.com writes:
Summary of updates:
- Convert OMAP GPIO driver to use linear mapping for IRQ domains
- Avoid crashes seen if a gpio bank is not enabled when requesting an IRQ.
Acked-by: Kevin Hilman khil...@linaro.org
--
To unsubscribe from this list: send the line
Bedia, Vaibhav vaibhav.be...@ti.com writes:
[...]
IMO, this would be a much cleaner implementation if you just created a
small driver for the wkup_m3. You're already doing a bunch of
driver-like stuff for it (requesting base/IRQs, mapping regions,
firmware, etc.) I think this should
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Rajendra nayak
Philip Avinash avinashphi...@ti.com writes:
With GPMC converted to platform driver recently, adds low power
transition support in driver itself.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
Module disable enable added using pm_runtime support.
[...]
Just to recap what we've discussed earlier, the reasons why we want
reset and idle functions should be in the driver specific header are:
1. There's often driver specific logic needed in addition to the
syconfig tinkering in the reset/idle functions.
It's been a while since
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
[ ... ]
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Feb 19, 2013 at 11:50:37AM -0800, Kevin Hilman wrote:
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed
Roger Quadros rog...@ti.com writes:
On 02/15/2013 05:54 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Hi Kevin,
On 02/15/2013 12:50 AM, Kevin Hilman wrote:
Felipe, Roger,
Using Tony's current master branch, and enabling EHCI support, I see
the clock framework spitting
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided
Felipe Balbi ba...@ti.com writes:
Hi,
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for hwmod from DT as Santosh has
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Kevin,
On Tue, Feb 12, 2013 at 06:57:50, Kevin Hilman wrote:
[...]
+
+void (*am33xx_do_wfi_sram)(void);
static?
Will fix.
[...]
+
+ /*
+ * By default the following IPs do not have MSTANDBY asserted
+ * which is necessary
Hi Felipe,
Felipe Balbi ba...@ti.com writes:
Eventually, we need to be able to remove
ti,hwmods DT attribute (or at a minimum
ignore it).
For new platforms, this patch could enable
the transition by not relying on ti,hwmods
to have functioning PM and Idle implementation.
Notice that
pointers), but at least gets rid of
the need for any SYSCONFIG access in the driver for the idle modes.
Needs more thorough testing.
Kevin
From 3d3956472d2375b5ed939d1d0165e439aa47262f Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Wed, 26 Sep 2012 18:36:43 -0700
Subject
Roger Quadros rog...@ti.com writes:
Hi Kevin,
On 02/15/2013 12:50 AM, Kevin Hilman wrote:
Felipe, Roger,
Using Tony's current master branch, and enabling EHCI support, I see
the clock framework spitting loudly about the EHCI driver (full boot log
below.) The same thing happens on v3.8
Felipe, Roger,
Using Tony's current master branch, and enabling EHCI support, I see
the clock framework spitting loudly about the EHCI driver (full boot log
below.) The same thing happens on v3.8-rc7.
Any idea what's going on? Am I missing a set of fixes that's already
been posted?
On a
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Saturday 09 February 2013 02:49 AM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
Current CPU PM code code make use of common cpu_suspend() path for all the
CPU power states which is not optimal. In fact
enters self-refresh. So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code. This removes some
unnecessary SRAM code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
NeilBrown ne...@suse.de writes:
On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/21/13 11:28, NeilBrown wrote:
The standard suspend sequence involves runtime_resuming
devices before
301 - 400 of 5178 matches
Mail list logo
