Hi
This series converts the OMAP2+ powerdomain and PM code to use
functional power states - high-level power states such as OSWR,
which reflect changes in multiple underlying registers, rather than
expecting high-level PM code to program the registers directly. This
is intended to reduce the
Add several functions to report on whether powerdomains can change their
power state or logic retention power state, and whether those abilities
can be controlled by the kernel. This code is used in subsequent patches
that add the functional power state code.
Signed-off-by: Paul Walmsley
From: Jean Pihet jean.pi...@newoldbits.com
Trace the power domain transitions using the functional power states,
which include the power and logic states.
Signed-off-by: Jean Pihet j-pi...@ti.com
[p...@pwsan.com: split the fix that was originally part of this patch into a
separate patch]
From: Jean Pihet jean.pi...@newoldbits.com
Use the functional power states as the API to control power domains:
- use the PWRDM_FUNC_PWRST_* macros for the power states and logic
settings,
- the function pwrdm_set_next_fpwrst(), which controls the power domains
next power and logic
From: Jean Pihet jean.pi...@newoldbits.com
Use the functional power states as the API to control power
domains:
- use the PWRDM_FUNC_PWRST_* and PWRDM_LOGIC_MEM_PWRST_*
macros for the power states and logic settings,
- the function pwrdm_set_next_fpwrst, which controls
the power domains next
Assume that the memory bank power states follow the powerdomain power
states. The motivations are to reduce the amount of powerdomain code,
decrease the execution time of the powerdomain state switch code, and
simplify the power state debug.
This assumption is true for the currently-implemented
Add pwrdm_supports_fpwrst(), intended for use by the PM code to avoid
attempting to program a powerdomain to a power state that it doesn't
support.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/powerdomain.c | 33 +
During powerdomain init, we were previously programming a reasonable
default for the powerdomain and logic next-power-state fields, but not
touching the memory bank next-power-state fields. To ensure that the
previous OS or bootloader didn't leave the system in a bad state, program
the memory
Previously the PM code attempted to program power states that the
underlying powerdomain didn't support. Change this to only program
power states that are supported by the hardware.
In the future, the PM code should be changed further to program
explicit lists of powerdomain power states that
The powerdomain code that exported the ability to read or change the
previous, current, or next powerdomain or logic power states can now
be removed. All this is controlled via the powerdomain functional
power state interface now.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
From: Jean Pihet jean.pi...@newoldbits.com
Use the functional power states as the API to control power domains:
- use the PWRDM_FUNC_PWRST_* macros for the power states and logic
settings,
- the function pwrdm_set_next_fpwrst(), which controls the power domains
next power and logic
From: Jean Pihet jean.pi...@newoldbits.com
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the information to
sysfs for debug purpose.
This patch provides the information
From: Jean Pihet jean.pi...@newoldbits.com
Introduce the functional states for power domains, which include
the power states and the logic states.
This patch provides the API functions to set and read the power
domains functional state and internal functions to convert between
the functional
OMAP powerdomain code updates, implemented on top of the
functional power state conversion series. This series fixes the powerdomain
handling for OMAP2xxx, adds caching for the powerdomain next-power-state
and previous-power-state register bitfields, and some cleanup that's
intended to make it
Check for the presence of some of the arch_pwrdm function pointers
during powerdomain setup, rather than in the individual functions.
The primary motivation is to make the code slightly easier to read, but it
also should avoid a few instructions in some hot paths.
Signed-off-by: Paul Walmsley
Move the power state time tracking code into the powerdomain code.
This code accesses internal powerdomain state, so this change will
allow us to reduce what is exported from the powerdomain code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman
Remove some redundant tests in static functions, and add some comments
to some code that should have future attention.
Signed-off-by: Paul Walmsley p...@pwsan.com?
---
arch/arm/mach-omap2/powerdomain.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git
Move the pwrdm_state_switch() code that deals with previous power
states into the post-transition callback. This improves the clarity
of pwrdm_state_switch() considerably. Add some sorely-needed
kerneldoc for these functions.
It should be possible to drop pwrdm_state_switch() completely during
Move some debugfs functions into the powerdomain and clockdomain code;
the ultimate goal is to stop exporting some of the
powerdomain/clockdomain functions. Get rid of the nasty hacks that
avoid executing some of the debug functions based on string
comparisons on powerdomain and clockdomain
Avoid some unnecessary CM IP block reads by using the cached copy of
the clockdomain's hardware-supervised idle state. This should
simplify the code slightly and save a few hundred nanoseconds in these
paths.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/cm2xxx.c | 19
The OMAP2xxx PM code was missing calls to pwrdm_pre_transition() and
pwrdm_post_transition(). This prevented the power state debugging
from working correctly, and also violated some assumptions that are
used in future power state caching patches.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc:
If the powerdomain's next-power-state is set to ON, then we can skip
the powerdomain previous-power-state read during
pwrdm_post_transition(). This is both an optimization (for all OMAPs)
and a fix (for OMAP2xxx). It turns out the OMAP2xxx previous power
state mechanism is slightly different
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as being in the ON power
state while the kernel is running.
The OMAP2xxx PRM does support a form of powerdomain previous-power-state
tracking; so add it. This allows the power state tracking and debugging
code to do something useful on this platform.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx.c | 12
1
Cache the powerdomain previous power state registers. The objective
here is to avoid unneeded reads from the previous power state
registers. Reads from these registers can be extremely slow, even by
I/O device standards. I no longer recall the exact measurements, but
my recollection was that
Cache the powerdomain next power state registers. The objective here
is to avoid unneeded reads and writes to the next power state
registers, which are slow compared to RAM CPU cache.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
Hi Jon,
On Fri, 7 Dec 2012, Jon Hunter wrote:
Commit d043d87 (ARM: OMAP2+: clockdomain: bypass clockdomain handling
when disabling unused clks) skips the decrementing of a clock-domains
use count if the clocks use count is zero. However, for OMAP4 devices
this is causing the EMU clock-domain
On Mon, 3 Dec 2012, Jon Hunter wrote:
Fixes included, fixing up timer clock aliases for v3.8 and working
around ABE DPLL issue seen with latest u-boot bootloader (v2012.10).
Testing includes:
- Boot testing on OMAP4460 Panda and verifying that all dmtimers are
working.
V2 changes:
-
Hi,
in case anyone is interested in trying out the recent powerdomain PM
changes, posted for 3.9, there's a temporary branch
TEST_pwrdm_post_fpwrst_devel_a_3.9 in the git tree
git://git.pwsan.com/linux-2.6. It's based on the PRCM cleanup branches
for v3.7, plus some old regression
Hi,
I implemented gas gauge driver by 1-Wire interface in OMAP4 CPU, the
driver we used is a GPIO pin to simulate 1-Wire bus but it sometimes can't
work well of timing issue. So we want to use HDQ/1Wire controller in OMAP4,
does anyone have experience of OMAP4 1-Wire driver of using its
On Fri, Dec 07, 2012 at 16:07:23, Nori, Sekhar wrote:
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
The ELM hardware module can be used to speedup BCH 4/8/16 ECC scheme
error correction.
For now only 4 8 bit support is added
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Cc:
On Fri, Dec 07, 2012 at 16:10:04, Nori, Sekhar wrote:
On 12/5/2012 6:13 PM, Philip, Avinash wrote:
On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote:
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro
On Wed, Nov 28, 2012 at 16:42:26, Russell King - ARM Linux wrote:
On Tue, Nov 27, 2012 at 03:42:39PM -0800, Andrew Morton wrote:
+ /* Do not allow to execute any other task */
+ spin_lock_irqsave(lock, flags);
+ while (1);
I suspect this doesn't do what you want it to do.
This series resolves a few minor issues for EMIF driver.
Tested all the patches on OMAP4-sdp, OMAP5-sevm.
Patch : memory: emif: setup LP settings on freq update
is tested on a local tree, since freq update cannot be
tested on mainline.
Ambresh K (1):
memory: emif: use default custom config
From: Nishanth Menon n...@ti.com
Program the power management shadow register on freq update
else the concept of threshold frequencies dont really matter
as the system always uses the performance mode timing for LP
which is programmed in at init time.
Signed-off-by: Nishanth Menon n...@ti.com
From: Severine Glock s-gl...@ti.com
MR4 is reported under debugfs with following format MR4=%d.
Remove MR4= string for better convenience.
Signed-off-by: Severine Glock s-gl...@ti.com
---
drivers/memory/emif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
The issue was that only the first timings table was added to the
emif platform data at the emif driver registration. All other
timings tables was filled with zeros. Now all emif timings table
are added to the platform data.
Signed-off-by:
The driver tries to round up the specified timeout cycles to
next power of 2 value. But this is done wrongly.
Correcting this here.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/memory/emif.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Nishanth Menon n...@ti.com
As per OMAP5 TRM, phy_fast_dll_lock is meant for simulations only.
'0' is supposed to be used for normal operations. So, use 0.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/memory/emif.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Nishanth Menon n...@ti.com
In case the custom timings provide values which overflow
the maximum possible field value, warn and use maximum
permissible value.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/memory/emif.c | 36
1 file changed, 28
From: Nishanth Menon n...@ti.com
As per JESD209-2E specification for LPDDR2,
http://www.jedec.org/standards-documents/results/jesd209-2E
Table 73, LPDDR2 memories come in two flavors - Standard and
Extended. The Standard types can operate from -25C to +85C
However, beyond that and upto
From: Nishanth Menon n...@ti.com
Some machine or kernel variants might have missed implementation
of power off handlers. We DONOT want to let the system be in
out of spec state in this condition. So, WARN and attempt
a machine restart in the hopes of clearing the out-of-spec
temperature
From: Ambresh K ambr...@ti.com
In-case of low power mode selected and custom parameters
are not configured, then use default configuration.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/memory/emif.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
Sorry to Spam you in-box.
Please discard this message...
Thanks
Lokesh
On Monday 10 December 2012 12:38 PM, a...@dbdp33.itg.ti.com wrote:
From: Lokesh Vutla lokeshvu...@ti.com
This series resolves a few minor issues for EMIF driver.
Tested all the patches on OMAP4-sdp, OMAP5-sevm.
Patch :
Hi,
On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
display code from omapdss) moved setting up the initial overlay, overlay
manager, output and display connections from omapdss to omapfb.
However, currently
When there is heavy transmission traffic in the CPDMA, then Rx descriptors
memory is also utilized as tx desc memory this leads to reduced rx desc memory
which leads to poor performance.
This patch adds boundary for tx and rx descriptors in bd ram dividing the
descriptor memory to ensure that
46 matches
Mail list logo
