Re: [PATCH 00/19] OMAP: DSS2: ULPS support
On Wed, 2011-04-20 at 11:13 +0530, Archit Taneja wrote: On Tuesday 19 April 2011 02:52 PM, Valkeinen, Tomi wrote: ULPS (Ultra-Low Power State) is a power saving method for DSI bus. When the ULPS is entered, the host sends an ULPS entry sequence and pulls the DSI lines down. On ULPS exit, the host sends an exit sequence and continues normal operation. This allows both the host and the DSI peripheral to save some power while in ULPS. This patch set implements ULPS support for DSS2. ULPS can be used with DSI command mode displays, and as command mode displays can refresh the panel independently using its own framebuffer, entering ULPS allows OMAP DSS HW to be totally turned off while the image on the display stays. This in turn may allow OMAP to enter deep sleep. Taal panel driver implements an inactivity timer which is used to enter ULPS after a certain period. The period can configured via sysfs, ulps_timeout file. A good value for the ulps_timeout depends on the use case and board, but is most likely around 100-500ms. The patch set does not enable the ULPS timeout, but it has to be enabled either manually via sysfs or from the board file. Tested on OMAP 4430 Blaze board. The patches are based on the current DSS2 master branch. Tested on 4430sdp and 3430sdp with Taal Panel. Thanks. I've applied the ULPS patch set to my master branch. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V3 0/4] cpuidle: global registration of idle states with per-cpu statistics
The core change in this series is to split the cpuidle_device structure into parts that can be global and parts that has to remain per-cpu. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. This patch series along with Len Brown's pm_idle() cleanup (ref:https://lkml.org/lkml/2011/4/2/8) will simplify the cpuidle framework and make it easy to port to other architectures like POWER. References: https://lkml.org/lkml/2011/2/10/37 https://lkml.org/lkml/2011/3/25/52 First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. [2/4] - removes the cpuidle_device()-prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. Version 1 is at https://lkml.org/lkml/2011/3/22/161 Version 2 is at https://lkml.org/lkml/2011/4/11/32 Changes from V2: 1. Enabled global registration for arm at91_idle_driver, davinci_idle_driver, kirkwood_idle_driver, omap3_idle_driver cpuidle drivers. Enabled global registration for x86 intel_idle_driver also. 2. Made ladder governor follow new changed API. Thus both menu and ladder governors work with these changes. This patch series applies on top of 2.6.39-rc2 and is tested on x86 Nehalem system with multiple ACPI C-States with both acpi_idle and intel_idle cpuidle drivers. Note that this code is not tested for arm yet. Thanks, -Trinabh -- 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
[RFC PATCH V3 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
Cpuidle subsystem only suggests the state to enter and does not
guarantee if the suggested state is entered. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.
Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-at91/cpuidle.c | 14 --
arch/arm/mach-davinci/cpuidle.c | 12 -
arch/arm/mach-kirkwood/cpuidle.c | 14 --
arch/arm/mach-omap2/cpuidle34xx.c | 55 ++
arch/sh/kernel/cpu/shmobile/cpuidle.c | 15 --
drivers/acpi/processor_idle.c | 81 ++---
drivers/cpuidle/cpuidle.c | 27 ---
drivers/cpuidle/governors/ladder.c| 13 +
drivers/cpuidle/governors/menu.c |7 ++-
drivers/idle/intel_idle.c | 14 --
include/linux/cpuidle.h |7 +--
11 files changed, 169 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..c85da01 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
do_gettimeofday(before);
- if (state == dev-states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == dev-states[1]) {
+ else if (index == 1) {
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,13 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ /* Update cpuidle counters */
+ dev-last_residency = idle_time;
+ dev-states[index].time += (unsigned long long)dev-last_residency;
+ dev-states[index].usage++;
+
+ return index;
}
/* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..0053aaa 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(state);
+ struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
struct timeval before, after;
int idle_time;
@@ -98,7 +98,13 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ /* Update cpuidle counters */
+ dev-last_residency = idle_time;
+ dev-states[index].time += (unsigned long long)dev-last_residency;
+ dev-states[index].usage++;
+
+ return index;
}
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-kirkwood/cpuidle.c
index f68d33f..a5f6fef 100644
--- a/arch/arm/mach-kirkwood/cpuidle.c
+++ b/arch/arm/mach-kirkwood/cpuidle.c
@@ -32,17 +32,17 @@ static DEFINE_PER_CPU(struct cpuidle_device,
kirkwood_cpuidle_device);
/* Actual code that puts the SoC in different idle states */
static int kirkwood_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
local_irq_disable();
do_gettimeofday(before);
- if
[RFC PATCH V3 3/4] Split cpuidle_state structure and move per-cpu statistics fields
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-at91/cpuidle.c |4 +--
arch/arm/mach-davinci/cpuidle.c |9 +++---
arch/arm/mach-kirkwood/cpuidle.c |4 +--
arch/arm/mach-omap2/cpuidle34xx.c | 17 ++-
arch/sh/kernel/cpu/shmobile/cpuidle.c |4 +--
drivers/acpi/processor_idle.c | 37 +++
drivers/cpuidle/cpuidle.c | 12
drivers/cpuidle/sysfs.c | 15 ++
drivers/idle/intel_idle.c | 52 -
include/linux/cpuidle.h | 25 ++--
10 files changed, 108 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index c85da01..ed38e3c 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -58,8 +58,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
/* Update cpuidle counters */
dev-last_residency = idle_time;
- dev-states[index].time += (unsigned long long)dev-last_residency;
- dev-states[index].usage++;
+ dev-states_usage[index].time += (unsigned long
long)dev-last_residency;
+ dev-states_usage[index].usage++;
return index;
}
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 0053aaa..e3aebe6 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
@@ -101,8 +102,8 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
/* Update cpuidle counters */
dev-last_residency = idle_time;
- dev-states[index].time += (unsigned long long)dev-last_residency;
- dev-states[index].usage++;
+ state_usage-time += (unsigned long long)dev-last_residency;
+ state_usage-usage++;
return index;
}
@@ -145,7 +146,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
strcpy(device-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(device-states[1], davinci_states[1]);
+ cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-kirkwood/cpuidle.c
index a5f6fef..d135a41 100644
--- a/arch/arm/mach-kirkwood/cpuidle.c
+++ b/arch/arm/mach-kirkwood/cpuidle.c
@@ -60,8 +60,8 @@ static int kirkwood_enter_idle(struct cpuidle_device *dev,
/* Update cpuidle counters */
dev-last_residency = idle_time;
- dev-states[index].time += (unsigned long long)dev-last_residency;
- dev-states[index].usage++;
+ dev-states_usage[index].time += (unsigned long
long)dev-last_residency;
+ dev-states_usage[index].usage++;
return index;
}
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0b00872..4282420 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -123,7 +123,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_processor_cx *cx =
- cpuidle_get_statedata(dev-states[index]);
+ cpuidle_get_statedata(dev-states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -166,8 +166,8 @@ return_sleep_time:
/* Update cpuidle counters */
dev-last_residency = idle_time;
- dev-states[index].time += (unsigned long long)dev-last_residency;
- dev-states[index].usage++;
+ dev-states_usage[index].time += (unsigned long
long)dev-last_residency;
+ dev-states_usage[index].usage++;
return index;
}
@@ -185,11 +185,12 @@ static int next_valid_state(struct cpuidle_device *dev,
int index)
{
struct cpuidle_state *curr = dev-states[index];
+ struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
[RFC PATCH V3 4/4] cpuidle: Single/Global registration of idle states
With this patch there is single copy of cpuidle_states structure
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driverand
architectures such as POWER do not have asymmetric C-states.
To Do:
1. Handle the case when idle states may change at run time
and acpi_processor_cst_has_changed() routine is called.
2. Handle acpi_processor_power_exit() correctly i.e. ensure
unregistration of cpuidle driver since registration is now
moved inside acpi_processor_power_init().
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-at91/cpuidle.c | 31 +
arch/arm/mach-davinci/cpuidle.c | 39 ++-
arch/arm/mach-kirkwood/cpuidle.c | 30 +---
arch/arm/mach-omap2/cpuidle34xx.c | 97 +--
arch/sh/kernel/cpu/shmobile/cpuidle.c | 18 +++--
drivers/acpi/processor_driver.c | 18 +
drivers/acpi/processor_idle.c | 117 +++--
drivers/cpuidle/cpuidle.c | 46 -
drivers/cpuidle/driver.c | 25 +++
drivers/cpuidle/governors/ladder.c| 26 ---
drivers/cpuidle/governors/menu.c | 20 +++---
drivers/cpuidle/sysfs.c |3 +
drivers/idle/intel_idle.c | 80 +--
include/linux/cpuidle.h | 21 --
14 files changed, 378 insertions(+), 193 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index ed38e3c..039b378 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct timeval before, after;
@@ -68,27 +69,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
-
- cpuidle_register_driver(at91_idle_driver);
+ struct cpuidle_drive *driver = at91_idle_driver;
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
+ driver-state_count = AT91_MAX_STATES;
/* Wait for interrupt state */
- device-states[0].enter = at91_enter_idle;
- device-states[0].exit_latency = 1;
- device-states[0].target_residency = 1;
- device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ driver-states[0].enter = at91_enter_idle;
+ driver-states[0].exit_latency = 1;
+ driver-states[0].target_residency = 1;
+ driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[0].name, WFI);
+ strcpy(driver-states[0].desc, Wait for interrupt);
/* Wait for interrupt and RAM self refresh state */
- device-states[1].enter = at91_enter_idle;
- device-states[1].exit_latency = 10;
- device-states[1].target_residency = 1;
- device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, RAM_SR);
- strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+ driver-states[1].enter = at91_enter_idle;
+ driver-states[1].exit_latency = 10;
+ driver-states[1].target_residency = 1;
+ driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[1].name, RAM_SR);
+ strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
+
+ cpuidle_register_driver(at91_idle_driver);
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index e3aebe6..ba46a83 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
@@ -112,6 +113,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
+ strcut cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device =
Re: The old omapfb support
On Tue, 2011-04-19 at 14:45 +0200, Michael Büsch wrote: On Tue, 2011-04-19 at 15:41 +0300, Tomi Valkeinen wrote: On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote: On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: But this again reminded me of the mess of having two display drivers, the old omapfb and the new DSS2. Many of the OMAP2 boards using the old driver should be quite easy to port to DSS2, with the exception of N800. DSS2 doesn't support OMAP1, so there's not much that can be done with those boards currently. Yeh we can just make old omapfb depends on ARCH_OMAP1. As he said, the old omapfb code is used on n8x0, which is OMAP2. But as I also said, the old OMAP2 panel drivers can be ported to the new DSS driver. I just mentioned N800 because the panel driver for N800 is rather difficult to port and will require more work than the other OMAP2 panel drivers. So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: omap2: mtd split nand_scan in ident and tail
On Tue, 2011-04-19 at 16:15 +0200, Jan Weitzel wrote: nand_scan calls nand_scan_tail and here we got a ecc.layout and calculate oobavail for this layout. After calling nand_scan, we change the layout pointer if OMAP_ECC_HAMMING_CODE_HW_ROMCODE is set. This results in not calcluated oobavail. Mountig as jffs2 is not possible. To fix that nand_scan has to split up in nand_scan_ident and nand_scan_tail setting ecc.layout between these calls. So nand_scan_tail calculates oobvail for the used layout. This is also done in serveral other platforms. Signed-off-by: Jan Weitzel j.weit...@phytec.de Reviewed-by: Vimal Singh vimal.neww...@gmail.com Jan, thanks for the patch, pushed to l2-mtd-2.6.git. And apologies that I missed. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed, because of which clock's tree rates get goofed
up when DVFS happens. This Patch adds recalc API back.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] crypto: omap-sham driver fixes
Hi, Here is few patches with couple of important fixes... Regards, Dmitry Dmitry Kasatkin (3): crypto: omap-sham - remove debug print crypto: omap-sham - enable driver for EMU chips crypto: omap-sham - hmac calculation bug fix for sha1 base hash Markku Kylanpaa (1): crypto: omap-sham - fix concurrent sha1 calculations drivers/crypto/omap-sham.c | 78 +++- 1 files changed, 34 insertions(+), 44 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] crypto: omap-sham - enable driver for EMU chips
EMU chips also have crypto HW as HS chips.
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
drivers/crypto/omap-sham.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 50aca41..f5c01dc 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1295,7 +1295,8 @@ static int __init omap_sham_mod_init(void)
pr_info(loading %s driver\n, omap-sham);
if (!cpu_class_is_omap2() ||
- omap_type() != OMAP2_DEVICE_TYPE_SEC) {
+ (omap_type() != OMAP2_DEVICE_TYPE_SEC
+ omap_type() != OMAP2_DEVICE_TYPE_EMU)) {
pr_err(Unsupported cpu\n);
return -ENODEV;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] crypto: omap-sham - remove debug print
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com --- drivers/crypto/omap-sham.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index e36032b..50aca41 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -890,8 +890,6 @@ static int omap_sham_cra_init_alg(struct crypto_tfm *tfm, const char *alg_base) struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm); const char *alg_name = crypto_tfm_alg_name(tfm); - pr_info(enter\n); - /* Allocate a fallback and abort if it failed. */ tctx-fallback = crypto_alloc_shash(alg_name, 0, CRYPTO_ALG_NEED_FALLBACK); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] crypto: omap-sham - fix concurrent sha1 calculations
From: Markku Kylanpaa ext-markku.kylan...@nokia.com SHA1 accelerator can also be busy. Add -EBUSY status return option and return busy status from omap_sham_finup(). Signed-off-by: Markku Kylanpaa ext-markku.kylan...@nokia.com --- drivers/crypto/omap-sham.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index 465cde3..e36032b 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -835,7 +835,7 @@ static int omap_sham_finup(struct ahash_request *req) ctx-flags |= FLAGS_FINUP; err1 = omap_sham_update(req); - if (err1 == -EINPROGRESS) + if (err1 == -EINPROGRESS || err1 == -EBUSY) return err1; /* * final() has to be always called to cleanup resources -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off
Thanks for the ack. Now can we get this patch set in? Anton are you reading this? If you need refreshed set, I can do that. - Kalle -Original Message- From: ext Tony Lindgren [mailto:t...@atomide.com] Sent: 13. huhtikuuta 2011 9:29 To: Krogerus Heikki (Nokia-SD/Helsinki) Cc: Jokiniemi Kalle (Nokia-SD/Tampere); linux-...@vger.kernel.org; cbouatmai...@gmail.com; ba...@ti.com; sshtyl...@mvista.com; khil...@ti.com; linux-omap@vger.kernel.org; jhnik...@gmail.com Subject: Re: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off * Heikki Krogerus heikki.kroge...@nokia.com [110413 08:07]: Hi, On Wed, Mar 30, 2011 at 08:08:54AM +0300, ext Heikki Krogerus wrote: On Tue, Mar 29, 2011 at 04:28:00PM +0300, Kalle Jokiniemi wrote: The isp1704 usb tranceiver is used for charging and can be disabled when not in use. Provide the powering routine to the driver via platform data. Also changed the indent of .name variable in rx51_charger_device definition to use tabs same way as the new .dev variable indent. Put this in the same patch since the indent fix is only needed when there are multiple members in the struct definition. Loosely based on earlier patches from Heikki Krogerus in Nokia N900 maemo kernel. Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com Cc: Heikki Krogerus heikki.kroge...@nokia.com Acked-By: Heikki Krogerus heikki.kroge...@nokia.com Before Anton takes these, this one needs ack from Tony. Looks good to me: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off
-Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of ext kalle.jokini...@nokia.com Sent: 20. huhtikuuta 2011 13:38 To: t...@atomide.com; Krogerus Heikki (Nokia-SD/Helsinki); cbouatmai...@gmail.com Cc: linux-...@vger.kernel.org; ba...@ti.com; sshtyl...@mvista.com; khil...@ti.com; linux-omap@vger.kernel.org; jhnik...@gmail.com Subject: RE: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off Thanks for the ack. Now can we get this patch set in? Anton are you reading this? Let's try another mail address for Anton... - Kalle If you need refreshed set, I can do that. - Kalle -Original Message- From: ext Tony Lindgren [mailto:t...@atomide.com] Sent: 13. huhtikuuta 2011 9:29 To: Krogerus Heikki (Nokia-SD/Helsinki) Cc: Jokiniemi Kalle (Nokia-SD/Tampere); linux-...@vger.kernel.org; cbouatmai...@gmail.com; ba...@ti.com; sshtyl...@mvista.com; khil...@ti.com; linux-omap@vger.kernel.org; jhnik...@gmail.com Subject: Re: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off * Heikki Krogerus heikki.kroge...@nokia.com [110413 08:07]: Hi, On Wed, Mar 30, 2011 at 08:08:54AM +0300, ext Heikki Krogerus wrote: On Tue, Mar 29, 2011 at 04:28:00PM +0300, Kalle Jokiniemi wrote: The isp1704 usb tranceiver is used for charging and can be disabled when not in use. Provide the powering routine to the driver via platform data. Also changed the indent of .name variable in rx51_charger_device definition to use tabs same way as the new .dev variable indent. Put this in the same patch since the indent fix is only needed when there are multiple members in the struct definition. Loosely based on earlier patches from Heikki Krogerus in Nokia N900 maemo kernel. Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com Cc: Heikki Krogerus heikki.kroge...@nokia.com Acked-By: Heikki Krogerus heikki.kroge...@nokia.com Before Anton takes these, this one needs ack from Tony. Looks good to me: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. It needs some additional glue code, which can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch But with that code it works fine. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Wed, 2011-04-20 at 13:18 +0200, Michael Büsch wrote: On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. It needs some additional glue code, which can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch But with that code it works fine. Ok, thanks. I found an N810 from my HW stash, but as I don't have a serial adapter for it, kernel work will be rather difficult. I'll port the display driver, but I'm probably not able to test it at all. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Wed, 2011-04-20 at 14:31 +0300, Tomi Valkeinen wrote: On Wed, 2011-04-20 at 13:18 +0200, Michael Büsch wrote: On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. It needs some additional glue code, which can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch But with that code it works fine. Ok, thanks. I found an N810 from my HW stash, but as I don't have a serial adapter for it, kernel work will be rather difficult. I'll port the display driver, but I'm probably not able to test it at all. Ok thanks. I'll test it. I have access to the serial console. Also see the other patches in that SVN directory. If all those patches are applied, it does boot on 2.6.38. I'm not sure which ones are really required to make it boot. So you should probably first try to boot with the old driver to check if your setup works. -- Greetings Michael. -- 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
Monitoring uevents at the user space
Hello All, I am writing a driver for OMAP4460 thermal sensor. I have a requirement to send events to the user space from the driver on some condition. I am using kobject_uevent(temp_sensor-dev-kobj, KOBJ_ADD) as part of initialization. On the occurrence of the event i am notifying via kobject_uevent(temp_sensor-dev-kobj, KOBJ_CHANGE). I am using busybox file system. What is the recommended way to actually verify whether the uevent has been propagated to the user space or not from the driver? -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Wednesday, April 20, 2011 2:55 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Gulati, Shweta; Nayak, Rajendra;
Paul Wamsley
Subject: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed, because of which clock's tree rates get goofed
up when DVFS happens. This Patch adds recalc API back.
I see that the patch is not adding API back.
It is adding a call to the API.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
checking if (!ret) is an intelligent way.
But it is an individual's choice.
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
copy_to_user speed from dma_alloc_coherent vs. kmalloc buffer
Hi, I have a driver where I do memory to memory DMA between GPMC and SDRAM. Adding a read function, I found that copy_to_user from a dma_alloc_coherent buffer is significantly slower than from a kmalloc'd one. Looking at arch/arm/include/asm/pgtable.h I suspect this difference in speed is due to the fact that the dma_alloc_coherent buffer is unbuffered. What are my options (besides using mmap)? * Reserve a portion of memory at boot time to be used as the DMA destination buffer, use ioremap_cached + manual cache flush as needed? * Turn on buffering for the DMA destination buffer for the duration of the copy_to_user call, then turn it off again (and flush it from the cache)? * Something else entirely? This is on a 3730, on Linux 2.6.32. Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RX-51: Platform support for lp5523
* Felipe Balbi ba...@ti.com [110405 06:00]: But the fact that Russell has already stated the next merge window is strictly for code consolidation already puts a stop sign in front of this patch :-) Still, Tony is the final judge. Yes this would be for the next merge window. It is still unclear what if any more platform data we want to merge. As stated, consolidation patches will be the highest priority right now. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap2: enable smc instruction for sleep34xx
* oskar.and...@sonyericsson.com oskar.and...@sonyericsson.com [110419 07:39]: This fixes broken build when using binutils 2.21. Thanks will queue for the -rc cycle. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
Hello. On 20-04-2011 13:25, Shweta Gulati wrote: From: Gulati, Shwetashweta.gul...@ti.com Core Clk Tree shows incorrect Clk rates at OPP50, as in commit e07f469d284ca3d1f5dcf5438c22982be98bc071 Please also specify that commit's summary -- for human readers. calling of 'recalc' in API clk_set_rate is unintentionally removed, because of which clock's tree rates get goofed up when DVFS happens. This Patch adds recalc API back. Tested on OMAP3630 SDP Board. Signed-off-by: Shweta Gulatishweta.gul...@ti.com Cc: Rajendra Nayakrna...@ti.com Cc: Paul Wamsleyp...@pwsan.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Monitoring uevents at the user space
On Wed, Apr 20, 2011 at 07:04, J, KEERTHY j-keer...@ti.com wrote: Hello All, I am writing a driver for OMAP4460 thermal sensor. I have a requirement to send events to the user space from the driver on some condition. I am using kobject_uevent(temp_sensor-dev-kobj, KOBJ_ADD) as part of initialization. On the occurrence of the event i am notifying via kobject_uevent(temp_sensor-dev-kobj, KOBJ_CHANGE). I am using busybox file system. What is the recommended way to actually verify whether the uevent has been propagated to the user space or not from the driver? does this help? http://wildanm.wordpress.com/2007/08/21/mdev-mini-udev-in-busybox/ Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: copy_to_user speed from dma_alloc_coherent vs. kmalloc buffer
On 2011-04-20 17:12, Orjan Friberg wrote:
What are my options (besides using mmap)?
It looks like kmalloc + dma_map_single for the DMA destination buffer
and then dma_sync_single_for_{cpu,device} around the call to
copy_to_user pretty much does the trick. At least the %sys load
measured with mpstat goes from 13% to 2%.
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2plus: add wl12xx support in omap4plus_defconfig
Many omap2plus-based boards include wireless chips supported by the wl12xx driver (eg. WL1271 on Blaze and Panda) or can get an extension that includes such chips (eg. the WLAN daugther card for Beagle). To get out-of-the-box support for the wl12xx-based chips on such boards, this patch adds the wl12xx driver as modules in omap2plus_defconfig. Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/configs/omap2plus_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 076db52..cfc343e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -108,6 +108,11 @@ CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_MAC80211_LEDS=y +CONFIG_WL12XX_MENU=m +CONFIG_WL12XX=m +CONFIG_WL12XX_HT=y +CONFIG_WL12XX_SDIO=m +CONFIG_WL12XX_PLATFORM_DATA=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y CONFIG_MTD=y -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] RX-51: Enable isp1704 power on/off
On Wed, Apr 20, 2011 at 10:56:51AM +, kalle.jokini...@nokia.com wrote: Thanks for the ack. Now can we get this patch set in? Anton are you reading this? Let's try another mail address for Anton... Sorry for the delay, folks. The two patches are now applied. Much thanks for your work! -- Anton Vorontsov Email: cbouatmai...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH V3 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
Trinabh Gupta trin...@linux.vnet.ibm.com writes: Cpuidle subsystem only suggests the state to enter and does not guarantee if the suggested state is entered. The actual entered state may be different because of software or hardware demotion. Software demotion is done by the back-end cpuidle driver and can be accounted correctly. Current cpuidle code uses last_state field to capture the actual state entered and based on that updates the statistics for the state entered. Ideally the driver enter routine should update the counters, and it should return the state actually entered rather than the time spent there. OK, the return type was changed to return the state index instead of the time, but since the governors are still relying on dev-last_residency, drivers are required to update it. Because of that, why not keep the update of the time/usage counters in common code rather than duplicating it (9 times in this patch) into all the drivers? Something like the patch below should suffice. Kevin diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c index 845d3ef..875d241 100644 --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -91,6 +91,11 @@ static void cpuidle_idle_call(void) entered_state = target_state-enter(dev, drv, next_state); + /* Update cpuidle counters */ + dev-states_usage[entered_state].time += + (unsigned long long)dev-last_residency; + dev-states_usage[entered_state].usage++; + trace_power_end(dev-cpu); trace_cpu_idle(PWR_EVENT_EXIT, dev-cpu); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH V3 4/4] cpuidle: Single/Global registration of idle states
Trinabh Gupta trin...@linux.vnet.ibm.com writes: With this patch there is single copy of cpuidle_states structure instead of per-cpu. The statistics needed on per-cpu basis by the governor are kept per-cpu. This simplifies the cpuidle subsystem as state registration is done by single cpu only. Having single copy of cpuidle_states saves memory. Rare case of asymmetric C-states can be handled within the cpuidle driverand architectures such as POWER do not have asymmetric C-states. I haven't actually tested this series on OMAP yet, but it currently doesn't compile. The patch below (on top of your series) is required to compile on OMAP, I think it's doing what you intended, but please confirm. Kevin diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6641574..ab77ba3 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -512,6 +512,7 @@ static int omap3_cpuidle_driver_init(void) int i, retval, count = 0; struct omap3_processor_cx *cx; struct cpuidle_state *state; + struct cpuidle_driver *drv = omap3_idle_driver; mpu_pd = pwrdm_lookup(mpu_pwrdm); core_pd = pwrdm_lookup(core_pwrdm); @@ -532,7 +533,7 @@ static int omap3_cpuidle_driver_init(void) state-enter = (state-flags CPUIDLE_FLAG_CHECK_BM) ? omap3_enter_idle_bm : omap3_enter_idle; if (cx-type == OMAP3_STATE_C1) - dev-safe_state_index = count; + drv-safe_state_index = count; sprintf(state-name, C%d, count+1); strncpy(state-desc, cx-desc, CPUIDLE_DESC_LEN); count++; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.
Thanks, queued for 2.6.39-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Couple of fixes regarding CM_AUTOIDLE_PLL register
Thanks, queued both of these for 2.6.39-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
Hi On Thu, 14 Apr 2011, Premi, Sanjeev wrote: [sp] You seem to have missed this patch: http://marc.info/?l=linux-arm-kernelm=129735383925285w=2 I asked Eduardo to post his patches because there was no response to http://marc.info/?l=linux-arm-kernelm=129961775124912w=2 and because he tracked down and fully documented the actual problem. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
Hi Rajendra, Santosh, just FYI I just observed this happening without the clockdomain patch, and tracked this down. It seems that there is an intermittent problem with the OMAP L3 bus code. On the 35xx BeagleBoard here, it occasionally hangs after powerup: [0.810119] OMAP GPIO hardware version 2.5 [0.815368] OMAP GPIO hardware version 2.5 [0.820465] OMAP GPIO hardware version 2.5 [0.825531] OMAP GPIO hardware version 2.5 [0.830657] OMAP GPIO hardware version 2.5 [0.835784] OMAP GPIO hardware version 2.5 [0.840881] initcall omap_gpio_drv_reg+0x0/0xc returned 0 after 38146 usecs [0.848358] calling bdi_class_init+0x0/0x50 @ 1 [0.854003] initcall bdi_class_init+0x0/0x50 returned 0 after 0 usecs [0.860870] calling kobject_uevent_init+0x0/0x20 @ 1 [0.866363] initcall kobject_uevent_init+0x0/0x20 returned 0 after 0 usecs [0.873626] calling gpiolib_sysfs_init+0x0/0x98 @ 1 [0.885894] initcall gpiolib_sysfs_init+0x0/0x98 returned 0 after 0 usecs [0.893157] calling lcd_class_init+0x0/0x58 @ 1 [0.898742] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs [0.905731] calling backlight_class_init+0x0/0x70 @ 1 [0.911834] initcall backlight_class_init+0x0/0x70 returned 0 after 0 usecs [0.919219] calling tty_class_init+0x0/0x3c @ 1 [0.924743] initcall tty_class_init+0x0/0x3c returned 0 after 0 usecs [0.931610] calling vtconsole_class_init+0x0/0xe4 @ 1 [0.938812] initcall vtconsole_class_init+0x0/0xe4 returned 0 after 7629 usecs [0.946472] calling wakeup_sources_debugfs_init+0x0/0x3c @ 1 [0.952606] initcall wakeup_sources_debugfs_init+0x0/0x3c returned 0 after 0 usecs [0.960571] calling spi_init+0x0/0x88 @ 1 [0.966247] initcall spi_init+0x0/0x88 returned 0 after 0 usecs [0.972564] calling i2c_init+0x0/0x70 @ 1 [0.978485] initcall i2c_init+0x0/0x70 returned 0 after 0 usecs [0.984832] calling omap3_l3_init+0x0/0x14 @ 1 (hang) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP hwmod/PRCM/clock: patches for 2.6.39-rc
Hello, This series contains OMAP hwmod/PRCM/clock fixes for the 2.6.39-rc merge period. Of particular note is the DSS clock alias patch, without which OMAP4 will crash on boot. Boot-tested on N800, OMAP35xx Beagle, OMAP37xx Beagle, and OMAP4430 ES2 Panda. - Paul --- for_tony_a_2.6.39rc textdata bss dec hex filename 5793259 542448 5594272 11929979 b6097b vmlinux.omap2plus_defconfig.orig 5793339 542448 5594272 11930059 b609cb vmlinux.omap2plus_defconfig Avinash.H.M (1): OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. Benoit Cousson (1): OMAP2+: hwmod data: Fix wrong dma_system end address Eduardo Valentin (2): OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL Tomi Valkeinen (1): OMAP4: clock data: Change DSS clock aliases arch/arm/mach-omap2/clock44xx_data.c |9 ++--- arch/arm/mach-omap2/cm2xxx_3xxx.c | 17 + arch/arm/mach-omap2/control.c |8 +++- arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |7 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- 7 files changed, 45 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP4: clock data: Change DSS clock aliases
From: Tomi Valkeinen tomi.valkei...@ti.com
DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
running, and also to get the pixel clock's source clock rate from the
fck.
On OMAP4 the clock data is set up in a different way, as there's no ick,
dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
dss_dss_clk if the DSS_FCK.
From DSS driver's point of view the dss_fck sounds like an ick, and
dss_dss_clk is the fck. While this is not entirely correct from HW point
of view, especially for the ick, configuring the clock aliases that way
makes DSS just work with OMAP4's clock setup.
In the (hopefully near) future DSS driver will be reworked to use
pm_runtime support which should clean up the clock code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 276992d..8c96567 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3116,14 +3116,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
CLK(omapdss_dss, sys_clk, dss_sys_clk,
CK_443X),
CLK(omapdss_dss, tv_clk, dss_tv_clk,
CK_443X),
- CLK(omapdss_dss, dss_clk, dss_dss_clk,
CK_443X),
CLK(omapdss_dss, video_clk,dss_48mhz_clk,
CK_443X),
- CLK(omapdss_dss, fck, dss_fck,
CK_443X),
- /*
-* On OMAP4, DSS ick is a dummy clock; this is needed for compatibility
-* with OMAP2/3.
-*/
- CLK(omapdss_dss, ick, dummy_ck,
CK_443X),
+ CLK(omapdss_dss, fck, dss_dss_clk,
CK_443X),
+ CLK(omapdss_dss, ick, dss_fck,
CK_443X),
CLK(NULL, efuse_ctrl_cust_fck, efuse_ctrl_cust_fck,
CK_443X),
CLK(NULL, emif1_fck,emif1_fck,
CK_443X),
CLK(NULL, emif2_fck,emif2_fck,
CK_443X),
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area
From: Eduardo Valentin eduardo.valen...@ti.com The saving of CCR.CM_AUTOIDLE_PLL is done in scratchpad area. However, in current code, the saving is done for CM_AUTOIDLE2_PLL (offset 0x34) instead of CM_AUTOIDLE_PLL (offset 0x30). This patch changes the code to save the correct register. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/control.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 6952794..df0c75c 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -317,7 +317,7 @@ void omap3_save_scratchpad_contents(void) prcm_block_contents.cm_clken_pll = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_block_contents.cm_autoidle_pll = - omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL); + omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_block_contents.cm_clksel1_pll = omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL); prcm_block_contents.cm_clksel2_pll = -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
From: Eduardo Valentin eduardo.valen...@ti.com
As per OMAP3 erratum (i671), ROM code adds extra latencies while
restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.
This patch stores 0's in scratchpad content area corresponding to
AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
it won't respect proper programing scheme.
This register is then stored in prcm context. The saving and restore
is now done by kernel side.
Here follow the erratum description
DESCRIPTION
After OFF mode transition, among many restorations, the ROM Code restores the
CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL.
In case the restoration data stored in scratchpad memory contains a field
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and
locks the PER DPLL does not respect the PER DPLL programming scheme.
In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER
DPLL, the ROM Code does not hang. Only extra latencies are introduced at
wake-up.
WORKAROUND
When saving the context-restore structure in scratchpad memory, in order to
respect the PER DPLL programming scheme, it is advised to store 0 in the
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure.
After wake-up, the application should store in CM_AUTOIDLE_PLL register the
right desired value.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/cm2xxx_3xxx.c | 17 +
arch/arm/mach-omap2/control.c |8 +++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c
b/arch/arm/mach-omap2/cm2xxx_3xxx.c
index 9d0dec8..38830d8 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c
@@ -247,6 +247,7 @@ struct omap3_cm_regs {
u32 per_cm_clksel;
u32 emu_cm_clksel;
u32 emu_cm_clkstctrl;
+ u32 pll_cm_autoidle;
u32 pll_cm_autoidle2;
u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
@@ -319,6 +320,15 @@ void omap3_cm_save_context(void)
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
cm_context.emu_cm_clkstctrl =
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
+ /*
+* As per erratum i671, ROM code does not respect the PER DPLL
+* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
+* In this case, even though this register has been saved in
+* scratchpad contents, we need to restore AUTO_PERIPH_DPLL
+* by ourselves. So, we need to save it anyway.
+*/
+ cm_context.pll_cm_autoidle =
+ omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
cm_context.pll_cm_autoidle2 =
omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
cm_context.pll_cm_clksel4 =
@@ -441,6 +451,13 @@ void omap3_cm_restore_context(void)
CM_CLKSEL1);
omap2_cm_write_mod_reg(cm_context.emu_cm_clkstctrl, OMAP3430_EMU_MOD,
OMAP2_CM_CLKSTCTRL);
+ /*
+* As per erratum i671, ROM code does not respect the PER DPLL
+* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
+* In this case, we need to restore AUTO_PERIPH_DPLL by ourselves.
+*/
+ omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle, PLL_MOD,
+ CM_AUTOIDLE);
omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle2, PLL_MOD,
CM_AUTOIDLE2);
omap2_cm_write_mod_reg(cm_context.pll_cm_clksel4, PLL_MOD,
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index df0c75c..da53ba3 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -316,8 +316,14 @@ void omap3_save_scratchpad_contents(void)
omap2_cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
prcm_block_contents.cm_clken_pll =
omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+ /*
+* As per erratum i671, ROM code does not respect the PER DPLL
+* programming scheme if CM_AUTOIDLE_PLL..AUTO_PERIPH_DPLL == 1.
+* Then, in anycase, clear these bits to avoid extra latencies.
+*/
prcm_block_contents.cm_autoidle_pll =
- omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
+ omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE)
+ ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
prcm_block_contents.cm_clksel1_pll =
omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
prcm_block_contents.cm_clksel2_pll =
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.
From: Avinash.H.M avinas...@ti.com
GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |4
arch/arm/mach-omap2/omap_hwmod_2430_data.c |5 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index f50e56a..c4d0ae8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1639,6 +1639,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[]
= {
static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1669,6 +1670,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio2_slaves[]
= {
static struct omap_hwmod omap2420_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1699,6 +1701,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio3_slaves[]
= {
static struct omap_hwmod omap2420_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1729,6 +1732,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio4_slaves[]
= {
static struct omap_hwmod omap2420_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio4_irqs),
.main_clk = gpios_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 96753f7..9682dd5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1742,6 +1742,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio1_slaves[]
= {
static struct omap_hwmod omap2430_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1772,6 +1773,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio2_slaves[]
= {
static struct omap_hwmod omap2430_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1802,6 +1804,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio3_slaves[]
= {
static struct omap_hwmod omap2430_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1832,6 +1835,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio4_slaves[]
= {
static struct omap_hwmod omap2430_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio4_irqs),
.main_clk = gpios_fck,
@@ -1862,6 +1866,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio5_slaves[]
= {
static struct omap_hwmod omap2430_gpio5_hwmod = {
.name = gpio5,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio5_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio5_irqs),
.main_clk = gpio5_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9bee155..909a84d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2141,6 +2141,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_gpio1_slaves[]
= {
static struct omap_hwmod omap3xxx_gpio1_hwmod = {
.name = gpio1,
+ .flags
Re: [PATCH] cbus: tahvo: Remove dead code from tahvo-usb.c
* Felipe Balbi ba...@ti.com [110419 03:02]: On Tue, Apr 19, 2011 at 11:19:53AM +0300, Jarkko Nikula wrote: Looks like this code was ever used. It was added by commit fe3702054f6412aea04373ceb9d27a4a417ff3f0 OMAP: Fix USB on Nokia 770 that can be found from linux-omap history if needed. Signed-off-by: Jarkko Nikula jhnik...@gmail.com FWIW: Reviewied-by: Felipe Balbi ba...@ti.com Both applied to the cbus branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
Hi
On Wed, 20 Apr 2011, Shweta Gulati wrote:
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed,
That's intentional. struct clk.set_rate functions need to set the struct
clk.rate before returning. If they don't do that, it's a bug in the
struct clk's .set_rate function.
because of which clock's tree rates get goofed up when DVFS happens.
Clearly this isn't on the mainline kernel...
This Patch adds recalc API back.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
1.7.0.4
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP hwmod/PRCM/clock: patches for 2.6.39-rc
Hi Tony The following changes since commit f0e615c3cb72b42191b558c130409335812621d8: Linux 2.6.39-rc4 (2011-04-18 21:26:00 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 for_tony_a_2.6.39rc Avinash.H.M (1): OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. Benoit Cousson (1): OMAP2+: hwmod data: Fix wrong dma_system end address Eduardo Valentin (2): OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL Tomi Valkeinen (1): OMAP4: clock data: Change DSS clock aliases arch/arm/mach-omap2/clock44xx_data.c |9 ++--- arch/arm/mach-omap2/cm2xxx_3xxx.c | 17 + arch/arm/mach-omap2/control.c |8 +++- arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |7 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- 7 files changed, 45 insertions(+), 12 deletions(-) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Hi Tony, Tony Lindgren t...@atomide.com writes: * Varadarajan, Charulatha ch...@ti.com [110418 18:00]: From: Charulatha V ch...@ti.com Use PM runtime framework in OMAP GPIO driver. ... arch/arm/mach-omap2/gpio.c |6 + arch/arm/mach-omap2/pm34xx.c | 22 +- arch/arm/plat-omap/gpio.c | 766 ++-- arch/arm/plat-omap/include/plat/gpio.h |3 +- 4 files changed, 439 insertions(+), 358 deletions(-) Before this series gets merged we first need to do the following: - Pass some registers in platform_data so we can have common functions in gpio.c instead of having to test for the bank-method in each function. This allows getting rid of the ifdefs as discussed in the ARM Linux consolidation thread. I have a series that starts this process, will post it shortly. - Move it to drivers/gpio - Further consolidate with whatever common GPIO code might be coming up. Is the above order required? IMO, before we move it to drivers/gpio, this code needs to be runtime PM converted (using this series from Charu.) The runtime PM conversion removes a bunch of platform-specific hacks that should be moved into drivers/*. Personally, I think we should go in this order - runtime PM conversion - #ifdef cleanup - move to drivers/gpio - look at consolidation with other drivers I'm willing to queue the GPIO work in my tree while it's under way if you like as well. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: GPIO: cleanup: first pass at ifdef removal
This series is a first pass at the #ifdef removal cleanup. To demonstrate the type of changes needed for the cleanup, the direction and data input/output functions are handled first. Register offset fields are added to platform_data so #ifdefs can be removed. Similar needs to be done for the remaining #ifdefs. Currently boot tested on 3430/n900 only. Series applies to v2.6.39-rc4. Kevin Hilman (2): OMAP: GPIO: move register offset defines into gpio.h OMAP: GPIO: consolidate direction, input, output, remove #ifdefs arch/arm/mach-omap1/gpio15xx.c |7 + arch/arm/mach-omap1/gpio16xx.c | 15 ++ arch/arm/mach-omap1/gpio7xx.c | 15 ++ arch/arm/mach-omap2/gpio.c | 10 + arch/arm/plat-omap/gpio.c | 328 +++ arch/arm/plat-omap/include/plat/gpio.h | 111 +++ 6 files changed, 190 insertions(+), 296 deletions(-) -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP: GPIO: move register offset defines into gpio.h
Register offset defines are moved to plat/gpio.h so they can be used
by SoC-specific device init code to fill out platform_data register offsets.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/gpio.c | 103
arch/arm/plat-omap/include/plat/gpio.h | 103
2 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index d2adcdd..ff70538 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -30,109 +30,6 @@
#include mach/gpio.h
#include asm/mach/irq.h
-/*
- * OMAP1510 GPIO registers
- */
-#define OMAP1510_GPIO_DATA_INPUT 0x00
-#define OMAP1510_GPIO_DATA_OUTPUT 0x04
-#define OMAP1510_GPIO_DIR_CONTROL 0x08
-#define OMAP1510_GPIO_INT_CONTROL 0x0c
-#define OMAP1510_GPIO_INT_MASK 0x10
-#define OMAP1510_GPIO_INT_STATUS 0x14
-#define OMAP1510_GPIO_PIN_CONTROL 0x18
-
-#define OMAP1510_IH_GPIO_BASE 64
-
-/*
- * OMAP1610 specific GPIO registers
- */
-#define OMAP1610_GPIO_REVISION 0x
-#define OMAP1610_GPIO_SYSCONFIG0x0010
-#define OMAP1610_GPIO_SYSSTATUS0x0014
-#define OMAP1610_GPIO_IRQSTATUS1 0x0018
-#define OMAP1610_GPIO_IRQENABLE1 0x001c
-#define OMAP1610_GPIO_WAKEUPENABLE 0x0028
-#define OMAP1610_GPIO_DATAIN 0x002c
-#define OMAP1610_GPIO_DATAOUT 0x0030
-#define OMAP1610_GPIO_DIRECTION0x0034
-#define OMAP1610_GPIO_EDGE_CTRL1 0x0038
-#define OMAP1610_GPIO_EDGE_CTRL2 0x003c
-#define OMAP1610_GPIO_CLEAR_IRQENABLE1 0x009c
-#define OMAP1610_GPIO_CLEAR_WAKEUPENA 0x00a8
-#define OMAP1610_GPIO_CLEAR_DATAOUT0x00b0
-#define OMAP1610_GPIO_SET_IRQENABLE1 0x00dc
-#define OMAP1610_GPIO_SET_WAKEUPENA0x00e8
-#define OMAP1610_GPIO_SET_DATAOUT 0x00f0
-
-/*
- * OMAP7XX specific GPIO registers
- */
-#define OMAP7XX_GPIO_DATA_INPUT0x00
-#define OMAP7XX_GPIO_DATA_OUTPUT 0x04
-#define OMAP7XX_GPIO_DIR_CONTROL 0x08
-#define OMAP7XX_GPIO_INT_CONTROL 0x0c
-#define OMAP7XX_GPIO_INT_MASK 0x10
-#define OMAP7XX_GPIO_INT_STATUS0x14
-
-/*
- * omap2+ specific GPIO registers
- */
-#define OMAP24XX_GPIO_REVISION 0x
-#define OMAP24XX_GPIO_IRQSTATUS1 0x0018
-#define OMAP24XX_GPIO_IRQSTATUS2 0x0028
-#define OMAP24XX_GPIO_IRQENABLE2 0x002c
-#define OMAP24XX_GPIO_IRQENABLE1 0x001c
-#define OMAP24XX_GPIO_WAKE_EN 0x0020
-#define OMAP24XX_GPIO_CTRL 0x0030
-#define OMAP24XX_GPIO_OE 0x0034
-#define OMAP24XX_GPIO_DATAIN 0x0038
-#define OMAP24XX_GPIO_DATAOUT 0x003c
-#define OMAP24XX_GPIO_LEVELDETECT0 0x0040
-#define OMAP24XX_GPIO_LEVELDETECT1 0x0044
-#define OMAP24XX_GPIO_RISINGDETECT 0x0048
-#define OMAP24XX_GPIO_FALLINGDETECT0x004c
-#define OMAP24XX_GPIO_DEBOUNCE_EN 0x0050
-#define OMAP24XX_GPIO_DEBOUNCE_VAL 0x0054
-#define OMAP24XX_GPIO_CLEARIRQENABLE1 0x0060
-#define OMAP24XX_GPIO_SETIRQENABLE10x0064
-#define OMAP24XX_GPIO_CLEARWKUENA 0x0080
-#define OMAP24XX_GPIO_SETWKUENA0x0084
-#define OMAP24XX_GPIO_CLEARDATAOUT 0x0090
-#define OMAP24XX_GPIO_SETDATAOUT 0x0094
-
-#define OMAP4_GPIO_REVISION0x
-#define OMAP4_GPIO_EOI 0x0020
-#define OMAP4_GPIO_IRQSTATUSRAW0 0x0024
-#define OMAP4_GPIO_IRQSTATUSRAW1 0x0028
-#define OMAP4_GPIO_IRQSTATUS0 0x002c
-#define OMAP4_GPIO_IRQSTATUS1 0x0030
-#define OMAP4_GPIO_IRQSTATUSSET0 0x0034
-#define OMAP4_GPIO_IRQSTATUSSET1 0x0038
-#define OMAP4_GPIO_IRQSTATUSCLR0 0x003c
-#define OMAP4_GPIO_IRQSTATUSCLR1 0x0040
-#define OMAP4_GPIO_IRQWAKEN0 0x0044
-#define OMAP4_GPIO_IRQWAKEN1 0x0048
-#define OMAP4_GPIO_IRQENABLE1 0x011c
-#define OMAP4_GPIO_WAKE_EN 0x0120
-#define OMAP4_GPIO_IRQSTATUS2 0x0128
-#define OMAP4_GPIO_IRQENABLE2 0x012c
-#define OMAP4_GPIO_CTRL0x0130
-#define OMAP4_GPIO_OE 0x0134
-#define OMAP4_GPIO_DATAIN 0x0138
-#define OMAP4_GPIO_DATAOUT 0x013c
-#define OMAP4_GPIO_LEVELDETECT00x0140
-#define OMAP4_GPIO_LEVELDETECT10x0144
-#define OMAP4_GPIO_RISINGDETECT0x0148
-#define OMAP4_GPIO_FALLINGDETECT 0x014c
-#define OMAP4_GPIO_DEBOUNCENABLE 0x0150
-#define OMAP4_GPIO_DEBOUNCINGTIME 0x0154
-#define OMAP4_GPIO_CLEARIRQENABLE1 0x0160
-#define OMAP4_GPIO_SETIRQENABLE1 0x0164
-#define OMAP4_GPIO_CLEARWKUENA 0x0180
-#define OMAP4_GPIO_SETWKUENA 0x0184
-#define OMAP4_GPIO_CLEARDATAOUT0x0190
-#define OMAP4_GPIO_SETDATAOUT 0x0194
-
struct gpio_bank {
unsigned long pbase;
void __iomem *base;
diff --git
[PATCH 2/2] OMAP: GPIO: consolidate direction, input, output, remove #ifdefs
Add register offset fields to GPIO platform_data for registers that
control direction, input and output data. Using these register
offsets in the common driver allows removal of #ifdefs and greatly
improves readability.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c |7 +
arch/arm/mach-omap1/gpio16xx.c | 15 ++
arch/arm/mach-omap1/gpio7xx.c | 15 ++
arch/arm/mach-omap2/gpio.c | 10 ++
arch/arm/plat-omap/gpio.c | 225 +---
arch/arm/plat-omap/include/plat/gpio.h |8 +
6 files changed, 87 insertions(+), 193 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
index 04c4b04..706015b 100644
--- a/arch/arm/mach-omap1/gpio15xx.c
+++ b/arch/arm/mach-omap1/gpio15xx.c
@@ -39,6 +39,10 @@ static struct __initdata omap_gpio_platform_data
omap15xx_mpu_gpio_config = {
.bank_type = METHOD_MPUIO,
.bank_width = 16,
.bank_stride= 1,
+ .direction_reg = OMAP_MPUIO_IO_CNTL,
+ .set_dataout_reg= OMAP_MPUIO_OUTPUT,
+ .datain_reg = OMAP_MPUIO_INPUT_LATCH,
+ .dataout_reg= OMAP_MPUIO_OUTPUT,
};
static struct __initdata platform_device omap15xx_mpu_gpio = {
@@ -68,6 +72,9 @@ static struct __initdata omap_gpio_platform_data
omap15xx_gpio_config = {
.virtual_irq_start = IH_GPIO_BASE,
.bank_type = METHOD_GPIO_1510,
.bank_width = 16,
+ .direction_reg = OMAP1510_GPIO_DIR_CONTROL,
+ .datain_reg = OMAP1510_GPIO_DATA_INPUT,
+ .dataout_reg= OMAP1510_GPIO_DATA_OUTPUT,
};
static struct __initdata platform_device omap15xx_gpio = {
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 5dd0d4c..9573b5e 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -42,6 +42,10 @@ static struct __initdata omap_gpio_platform_data
omap16xx_mpu_gpio_config = {
.bank_type = METHOD_MPUIO,
.bank_width = 16,
.bank_stride= 1,
+ .direction_reg = OMAP_MPUIO_IO_CNTL,
+ .set_dataout_reg= OMAP_MPUIO_OUTPUT,
+ .datain_reg = OMAP_MPUIO_INPUT_LATCH,
+ .dataout_reg= OMAP_MPUIO_OUTPUT,
};
static struct __initdata platform_device omap16xx_mpu_gpio = {
@@ -67,10 +71,18 @@ static struct __initdata resource
omap16xx_gpio1_resources[] = {
},
};
+#define OMAP16XX_GPIO_REG_OFFSETS \
+ .direction_reg = OMAP1610_GPIO_DIRECTION, \
+ .set_dataout_reg= OMAP1610_GPIO_SET_DATAOUT, \
+ .clr_dataout_reg= OMAP1610_GPIO_CLEAR_DATAOUT, \
+ .datain_reg = OMAP1610_GPIO_DATAIN, \
+ .dataout_reg= OMAP1610_GPIO_DATAOUT
+
static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
.virtual_irq_start = IH_GPIO_BASE,
.bank_type = METHOD_GPIO_1610,
.bank_width = 16,
+ OMAP16XX_GPIO_REG_OFFSETS,
};
static struct __initdata platform_device omap16xx_gpio1 = {
@@ -100,6 +112,7 @@ static struct __initdata omap_gpio_platform_data
omap16xx_gpio2_config = {
.virtual_irq_start = IH_GPIO_BASE + 16,
.bank_type = METHOD_GPIO_1610,
.bank_width = 16,
+ OMAP16XX_GPIO_REG_OFFSETS,
};
static struct __initdata platform_device omap16xx_gpio2 = {
@@ -129,6 +142,7 @@ static struct __initdata omap_gpio_platform_data
omap16xx_gpio3_config = {
.virtual_irq_start = IH_GPIO_BASE + 32,
.bank_type = METHOD_GPIO_1610,
.bank_width = 16,
+ OMAP16XX_GPIO_REG_OFFSETS,
};
static struct __initdata platform_device omap16xx_gpio3 = {
@@ -158,6 +172,7 @@ static struct __initdata omap_gpio_platform_data
omap16xx_gpio4_config = {
.virtual_irq_start = IH_GPIO_BASE + 48,
.bank_type = METHOD_GPIO_1610,
.bank_width = 16,
+ OMAP16XX_GPIO_REG_OFFSETS,
};
static struct __initdata platform_device omap16xx_gpio4 = {
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 1204c8b..79b0af8 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -44,6 +44,10 @@ static struct __initdata omap_gpio_platform_data
omap7xx_mpu_gpio_config = {
.bank_type = METHOD_MPUIO,
.bank_width = 32,
.bank_stride= 2,
+ .direction_reg = OMAP_MPUIO_IO_CNTL / 2, \
+ .set_dataout_reg= OMAP_MPUIO_OUTPUT / 2, \
+ .datain_reg = OMAP_MPUIO_INPUT_LATCH / 2, \
+ .dataout_reg= OMAP_MPUIO_OUTPUT / 2
};
static struct __initdata platform_device omap7xx_mpu_gpio = {
[PATCH] OMAP2+: powerdomain: fix typo: lose context -- loose context
Before we get any users of this function, fix the name (and comments)
to use loose instead of lose.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to v2.6.39-rc4
arch/arm/mach-omap2/powerdomain.c |6 +++---
arch/arm/mach-omap2/powerdomain.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..ec3423f 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -960,18 +960,18 @@ u32 pwrdm_get_context_loss_count(struct powerdomain
*pwrdm)
}
/**
- * pwrdm_can_ever_lose_context - can this powerdomain ever lose context?
+ * pwrdm_can_ever_loose_context - can this powerdomain ever loose context?
* @pwrdm: struct powerdomain *
*
* Given a struct powerdomain * @pwrdm, returns 1 if the powerdomain
- * can lose either memory or logic context or if @pwrdm is invalid, or
+ * can loose either memory or logic context or if @pwrdm is invalid, or
* returns 0 otherwise. This function is not concerned with how the
* powerdomain registers are programmed (i.e., to go off or not); it's
* concerned with whether it's ever possible for this powerdomain to
* go off while some other part of the chip is active. This function
* assumes that every powerdomain can go to either ON or INACTIVE.
*/
-bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm)
+bool pwrdm_can_ever_loose_context(struct powerdomain *pwrdm)
{
int i;
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index d23d979..95d5b9e 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -208,7 +208,7 @@ int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
-bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
+bool pwrdm_can_ever_loose_context(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
extern void omap3xxx_powerdomains_init(void);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] OMAP4: GPIO: Save/restore context
Varadarajan, Charulatha ch...@ti.com writes:
From: Charulatha V ch...@ti.com
Modify the omap_gpio_save/restore_context to support OMAP4
architecture so that the OMAP GPIO driver need not be modified
when OMAP4 off mode support is available.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/plat-omap/gpio.c | 131 +---
1 files changed, 86 insertions(+), 45 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 74085b5..e68da08 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2022,43 +2022,62 @@ void omap2_gpio_resume_after_idle(void)
#endif
-#ifdef CONFIG_ARCH_OMAP3
-/* save the registers of bank 2-6 */
void omap_gpio_save_context(void)
{
int i;
- /* saving banks from 2-6 only since GPIO1 is in WKUP */
Minor: these comment removals belong in the previous patch.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: DSS2: DSI: enable interface for omap4
From: Vikram Pandita vikram.pand...@ti.com By default, the DSI is not getting enabled for omap4. OMAP2PLUS does not catch this issue since it has ARCH_OMAP3. The issue is only seen when using defconfig with ARCH_OMAP4 only. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Cc: Archit Taneja arc...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index 7a49a75..6b3e2da 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -80,7 +80,7 @@ config OMAP2_DSS_SDI config OMAP2_DSS_DSI bool DSI support - depends on ARCH_OMAP3 + depends on ARCH_OMAP3 || ARCH_OMAP4 default n help MIPI DSI (Display Serial Interface) support. -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH V3 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
On 04/20/2011 10:57 PM, Kevin Hilman wrote: Trinabh Guptatrin...@linux.vnet.ibm.com writes: Cpuidle subsystem only suggests the state to enter and does not guarantee if the suggested state is entered. The actual entered state may be different because of software or hardware demotion. Software demotion is done by the back-end cpuidle driver and can be accounted correctly. Current cpuidle code uses last_state field to capture the actual state entered and based on that updates the statistics for the state entered. Ideally the driver enter routine should update the counters, and it should return the state actually entered rather than the time spent there. OK, the return type was changed to return the state index instead of the time, but since the governors are still relying on dev-last_residency, drivers are required to update it. Because of that, why not keep the update of the time/usage counters in common code rather than duplicating it (9 times in this patch) into all the drivers? Hi Kevin, Thanks for your review. Yes, we can do like this and it would prevent duplication of code. I just wanted to make cpuidle handle only selection and entering of state, and leave everything else to the driver which knows best about these things. But both are functionally same and definitely statistics update inside cpuidle_idle_call() prevents duplication of code. Thanks, -Trinabh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
On 4/21/2011 1:12 AM, Paul Walmsley wrote: Hi Rajendra, Santosh, just FYI I just observed this happening without the clockdomain patch, and tracked this down. It seems that there is an intermittent problem with the OMAP L3 bus code. On the 35xx BeagleBoard here, it occasionally hangs after powerup: [0.810119] OMAP GPIO hardware version 2.5 [0.815368] OMAP GPIO hardware version 2.5 [0.820465] OMAP GPIO hardware version 2.5 [0.825531] OMAP GPIO hardware version 2.5 [0.830657] OMAP GPIO hardware version 2.5 [0.835784] OMAP GPIO hardware version 2.5 [0.840881] initcall omap_gpio_drv_reg+0x0/0xc returned 0 after 38146 usecs [0.848358] calling bdi_class_init+0x0/0x50 @ 1 [0.854003] initcall bdi_class_init+0x0/0x50 returned 0 after 0 usecs [0.860870] calling kobject_uevent_init+0x0/0x20 @ 1 [0.866363] initcall kobject_uevent_init+0x0/0x20 returned 0 after 0 usecs [0.873626] calling gpiolib_sysfs_init+0x0/0x98 @ 1 [0.885894] initcall gpiolib_sysfs_init+0x0/0x98 returned 0 after 0 usecs [0.893157] calling lcd_class_init+0x0/0x58 @ 1 [0.898742] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs [0.905731] calling backlight_class_init+0x0/0x70 @ 1 [0.911834] initcall backlight_class_init+0x0/0x70 returned 0 after 0 usecs [0.919219] calling tty_class_init+0x0/0x3c @ 1 [0.924743] initcall tty_class_init+0x0/0x3c returned 0 after 0 usecs [0.931610] calling vtconsole_class_init+0x0/0xe4 @ 1 [0.938812] initcall vtconsole_class_init+0x0/0xe4 returned 0 after 7629 usecs [0.946472] calling wakeup_sources_debugfs_init+0x0/0x3c @ 1 [0.952606] initcall wakeup_sources_debugfs_init+0x0/0x3c returned 0 after 0 usecs [0.960571] calling spi_init+0x0/0x88 @ 1 [0.966247] initcall spi_init+0x0/0x88 returned 0 after 0 usecs [0.972564] calling i2c_init+0x0/0x70 @ 1 [0.978485] initcall i2c_init+0x0/0x70 returned 0 after 0 usecs [0.984832] calling omap3_l3_init+0x0/0x14 @ 1 Will have a look at it -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH V3 4/4] cpuidle: Single/Global registration of idle states
On 04/20/2011 11:03 PM, Kevin Hilman wrote: Trinabh Guptatrin...@linux.vnet.ibm.com writes: With this patch there is single copy of cpuidle_states structure instead of per-cpu. The statistics needed on per-cpu basis by the governor are kept per-cpu. This simplifies the cpuidle subsystem as state registration is done by single cpu only. Having single copy of cpuidle_states saves memory. Rare case of asymmetric C-states can be handled within the cpuidle driverand architectures such as POWER do not have asymmetric C-states. I haven't actually tested this series on OMAP yet, but it currently doesn't compile. Hi Kevin, Yes, I tested it only for x86 (as I had mentioned in the description of the patch series). I just wanted to get comments on the design and understand how it affects various architectures in question. It looks to me as if the design should be okay and infact better for architectures like ARM since they do not have different idle states for different cpus and thus do not require per-cpu registration. Global registration would work and be simpler; please correct me if I am wrong. The patch below (on top of your series) is required to compile on OMAP, I think it's doing what you intended, but please confirm. Thanks for helping with this. -Trinabh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Kevin Hilman khil...@ti.com [110421 02:56]: Hi Tony, Tony Lindgren t...@atomide.com writes: * Varadarajan, Charulatha ch...@ti.com [110418 18:00]: From: Charulatha V ch...@ti.com Use PM runtime framework in OMAP GPIO driver. ... arch/arm/mach-omap2/gpio.c |6 + arch/arm/mach-omap2/pm34xx.c | 22 +- arch/arm/plat-omap/gpio.c | 766 ++-- arch/arm/plat-omap/include/plat/gpio.h |3 +- 4 files changed, 439 insertions(+), 358 deletions(-) Before this series gets merged we first need to do the following: - Pass some registers in platform_data so we can have common functions in gpio.c instead of having to test for the bank-method in each function. This allows getting rid of the ifdefs as discussed in the ARM Linux consolidation thread. I have a series that starts this process, will post it shortly. Saw that, looks good :) Need to post it also to lakml BTW. - Move it to drivers/gpio - Further consolidate with whatever common GPIO code might be coming up. Is the above order required? Yes please. Otherwise we'll have more of the crazy churn in arch/arm/*omap*/ and the runtime PM patches should apply easily in drivers/gpio too. IMO, before we move it to drivers/gpio, this code needs to be runtime PM converted (using this series from Charu.) The runtime PM conversion removes a bunch of platform-specific hacks that should be moved into drivers/*. Personally, I think we should go in this order - runtime PM conversion Let's do this after the consolidation and move to drivers/gpio. This way any additions can be reviewed by the drivers/gpio maintainers. - #ifdef cleanup Looks like you got this already done :) - move to drivers/gpio With this part there may be more comments from the drivers/gpio maintainers so we need to get to this point ASAP. - look at consolidation with other drivers I'm willing to queue the GPIO work in my tree while it's under way if you like as well. If so, please put all the consolidation patches into a separate branch with absolutely zero additional new code. And let's merge those branches into linux-omap devel-cleanup branch on regular basis for testing. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
