[RFC PATCH V3 4/4] cpuidle: Single/Global registration of idle states

2011-04-19 Thread Trinabh Gupta
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 
---

 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_dat

[RFC PATCH V3 3/4] Split cpuidle_state structure and move per-cpu statistics fields

2011-04-19 Thread Trinabh Gupta
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 
---

 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 = &

[RFC PATCH V3 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()

2011-04-19 Thread Trinabh Gupta
The cpuidle_device->prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.

Signed-off-by: Trinabh Gupta 
---

 drivers/cpuidle/cpuidle.c|   10 --
 drivers/cpuidle/governors/menu.c |2 --
 include/linux/cpuidle.h  |3 ---
 3 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 355b078..92a6216 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -75,16 +75,6 @@ static void cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
 #endif
 
-   /*
-* Call the device's prepare function before calling the
-* governor's select function.  ->prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
-   if (dev->prepare)
-   dev->prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor->select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 70d9982..40b5630 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -286,8 +286,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i < dev->state_count; i++) {
struct cpuidle_state *s = &dev->states[i];
 
-   if (s->flags & CPUIDLE_FLAG_IGNORE)
-   continue;
if (s->target_residency > data->predicted_us)
continue;
if (s->exit_latency > latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 45eef60..a3306be 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
 
 /* Idle State Flags */
 #define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable? 
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
 
 #define CPUIDLE_DRIVER_FLAGS_MASK (0x)
 
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion   kobj_unregister;
void*governor_data;
int safe_state_index;
-
-   int (*prepare)  (struct cpuidle_device *dev);
 };
 
 DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);

--
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

2011-04-19 Thread Trinabh Gupta
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 
---

 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 (state == 

[RFC PATCH V3 0/4] cpuidle: global registration of idle states with per-cpu statistics

2011-04-19 Thread Trinabh Gupta
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


Re: [PATCH 00/19] OMAP: DSS2: ULPS support

2011-04-19 Thread Tomi Valkeinen
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


Re: [PATCH 00/19] OMAP: DSS2: ULPS support

2011-04-19 Thread Archit Taneja

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.

Archit


  Tomi

Tomi Valkeinen (19):
   OMAP: DSS2: DSI: Add lane override functions
   OMAP: DSS2: DSI: Remove CIO LDO status check
   OMAP: DSS2: DSI: implement ULPS enter and exit
   OMAP: DSS2: DSI: add option to leave DSI lanes powered on
   OMAP: DSS2: DSI: rename complexio related functions
   OMAP: DSS2: Add FEAT_DSI_REVERSE_TXCLKESC
   OMAP: DSS2: DSI: fix _dsi_print_reset_status
   OMAP: DSS2: DSI: implement enable/disable SCP clk
   OMAP: DSS2: DSI: fix CIO init and uninit
   OMAP: DSS2: DSI: wait for TXCLKESC domain to come out of reset
   OMAP: DSS2: DSI: add parameter to enter ulps on disable
   OMAP: DSS2: DSI: Add DSI pad muxing support
   OMAP: DSS2: DSI: ensure VDDS_DSI is disabled on exit
   OMAP: DSS2: Taal: Implement configurable ESD interval
   OMAP: DSS2: Taal: Clean up ESD queueing
   OMAP: DSS2: Taal: Add sysfs file for ESD interval
   OMAP: DSS2: Taal: Separate panel reset
   OMAP: DSS2: Taal: Rename esd_wq to workqueue
   OMAP: DSS2: Taal: Implement ULPS functionality

  arch/arm/mach-omap2/board-4430sdp.c   |2 +-
  arch/arm/plat-omap/include/plat/display.h |4 +-
  arch/arm/plat-omap/include/plat/nokia-dsi-panel.h |6 +-
  drivers/video/omap2/displays/panel-taal.c |  420 +++--
  drivers/video/omap2/dss/dpi.c |4 +-
  drivers/video/omap2/dss/dsi.c |  427 +
  drivers/video/omap2/dss/dss.h |2 +-
  drivers/video/omap2/dss/dss_features.c|4 +-
  drivers/video/omap2/dss/dss_features.h|6 +-
  9 files changed, 764 insertions(+), 111 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



--
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: [RFC PATCH] Consolidate SRAM support

2011-04-19 Thread Tony Lindgren
* Tomi Valkeinen  [110419 17:13]:
> Hi Tony and Russell,
> 
> On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> > * Tomi Valkeinen  [110418 09:57]:
> 
> > > So, I can make a patch that removes the SRAM support from omapfb, and
> > > queue it up for the next merge window.
> > 
> > OK. That patch should probably go into Russell's tree along with
> > other SRAM related patches to avoid conflicts.
> 
> Here's a simple patch to remove SRAM support from omapfb. Or more
> precisely, this just disables it.
> 
> I started to remove the SRAM support from the drivers, but the patches
> got quite big and will probably cause conflicts if they reside in
> somebody else's tree than mine. So I believe it's easiest to divide SRAM
> FB removal into this patch, handled by Russell (?), and then the rest,
> handled by me.

OK sounds like a plan.
 
> Is there something else related to OMAP FB than the code removed in this
> patch that is hindering the SRAM work?

I think we can now also remove sram_ceil and omap_sram_push_address?

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


Re: [RFC PATCH v2] Consolidate SRAM support

2011-04-19 Thread Jean-Christophe PLAGNIOL-VILLARD
On 00:20 Wed 20 Apr , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
> > On 17:18 Tue 19 Apr , Russell King - ARM Linux wrote:
> > > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe 
> > > PLAGNIOL-VILLARD wrote:
> > > > Hi,
> > > > 
> > > > I do post a patch to add the support to specify a virt and phys
> > > > address to the generic allocator so the pv-pool.c is not needed
> > > > we can just use the generic fucntion
> > > 
> > > You've talked about this before in the thread, but the patch never 
> > > appeared.
> > I forget to re-send it sorry
> > it's the mm tree
> 
> One obvious issue here is that you're using 'unsigned long' for phys
> addresses.  With LPAE we could start seeing SRAM outside of the 4GB
> PA range, and so would need this to be phys_addr_t.

I'll update it

any other issue?

Best Regards,
J.
--
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


omap byte order error in w1 slave message

2011-04-19 Thread Paul Alfille
After extensive testing, it's clear that the omap driver in
kernel/drivers/w1/masters/omap_hdq.c reports the slave address in
reversed byte order compared to all the other drivers.

This is in the netlink LIST_SLAVE message.

I've discovered this when testing support in OWFS --
one-wire-file-system (www.owfs.org) which is probably the most
comprehensive 1-wire support around.

I'd be glad to supply detailed information.

The sysfs report is correct, and the CRC8 is computed correctly. If I
just reverse the netlink slave addresses, everything functions well.

If it is not possible to correct the driver, my next alternative is to
always test the address forward and backward (the CRC8 will probably
work only in one direction) and compensate for the bug in that manner.

Paul Alfille
--
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: [RFC PATCH v2] Consolidate SRAM support

2011-04-19 Thread Russell King - ARM Linux
On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> On 17:18 Tue 19 Apr , Russell King - ARM Linux wrote:
> > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> > wrote:
> > > Hi,
> > > 
> > >   I do post a patch to add the support to specify a virt and phys
> > >   address to the generic allocator so the pv-pool.c is not needed
> > >   we can just use the generic fucntion
> > 
> > You've talked about this before in the thread, but the patch never appeared.
> I forget to re-send it sorry
> it's the mm tree

One obvious issue here is that you're using 'unsigned long' for phys
addresses.  With LPAE we could start seeing SRAM outside of the 4GB
PA range, and so would need this to be phys_addr_t.
--
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 linux-omap-pm/pm-wip/cpufreq] OMAP2PLUS: cpufreq: Fix typo when attempting to set mpu_clk for OMAP4

2011-04-19 Thread Kevin Hilman
Jarkko Nikula  writes:

> Fix this typo as there is no dpll_mpu_ck for OMAP3 and code flow is clearly
> trying to set mpu_clk for OMAP4 for which this dpll_mpu_ck is available.
>
> Signed-off-by: Jarkko Nikula 

Thanks, applied to pm-wip/cpufreq branch.

Kevin

> ---
>  arch/arm/mach-omap2/omap2plus-cpufreq.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c 
> b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> index 8d472f6..d53ce23 100644
> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> @@ -161,7 +161,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy 
> *policy)
>   mpu_clk = clk_get(NULL, "virt_prcm_set");
>   else if (cpu_is_omap34xx())
>   mpu_clk = clk_get(NULL, "dpll1_ck");
> - else if (cpu_is_omap34xx())
> + else if (cpu_is_omap44xx())
>   mpu_clk = clk_get(NULL, "dpll_mpu_ck");
>  
>   if (IS_ERR(mpu_clk))
--
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: [RFC PATCH v2] Consolidate SRAM support

2011-04-19 Thread Jean-Christophe PLAGNIOL-VILLARD
On 17:18 Tue 19 Apr , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
> > Hi,
> > 
> > I do post a patch to add the support to specify a virt and phys
> > address to the generic allocator so the pv-pool.c is not needed
> > we can just use the generic fucntion
> 
> You've talked about this before in the thread, but the patch never appeared.
I forget to re-send it sorry
it's the mm tree

patch attached

Best Regards,
J.
>From 05f5a21ca6423b3051d442eaad3ba34ac131ef98 Mon Sep 17 00:00:00 2001
From: Jean-Christophe PLAGNIOL-VILLARD 
Date: Thu, 7 Apr 2011 01:23:45 +0800
Subject: [PATCH] genalloc: add support to specify the physical address

so we specify the virtual address as base of the pool chunk and then
get the physical address for hardware IP

as example on at91 we will use on spi, uart or macb

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
---
 include/linux/genalloc.h |   20 +++-
 lib/genalloc.c   |   39 ---
 2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index b1c70f1..b44625b 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -26,13 +26,31 @@ struct gen_pool {
 struct gen_pool_chunk {
 	spinlock_t lock;
 	struct list_head next_chunk;	/* next chunk in pool */
+	unsigned long phys_addr;	/* physical starting address of memory chunk */
 	unsigned long start_addr;	/* starting address of memory chunk */
 	unsigned long end_addr;		/* ending address of memory chunk */
 	unsigned long bits[0];		/* bitmap for allocating memory chunk */
 };
 
 extern struct gen_pool *gen_pool_create(int, int);
-extern int gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
+extern int gen_pool_add_virt(struct gen_pool *, unsigned long, unsigned long,
+			 size_t, int);
+/**
+ * gen_pool_add - add a new chunk of special memory to the pool
+ * @pool: pool to add new memory chunk to
+ * @addr: starting address of memory chunk to add to pool
+ * @size: size in bytes of the memory chunk to add to pool
+ * @nid: node id of the node the chunk structure and bitmap should be
+ *   allocated on, or -1
+ *
+ * Add a new chunk of special memory to the specified pool.
+ */
+static inline int gen_pool_add(struct gen_pool *pool, unsigned long addr,
+			   size_t size, int nid)
+{
+	return gen_pool_add_virt(pool, addr, 0, size, nid);
+}
 extern void gen_pool_destroy(struct gen_pool *);
 extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
 extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 1923f14..83b069b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -39,17 +39,18 @@ struct gen_pool *gen_pool_create(int min_alloc_order, int nid)
 EXPORT_SYMBOL(gen_pool_create);
 
 /**
- * gen_pool_add - add a new chunk of special memory to the pool
+ * gen_pool_add_virt - add a new chunk of special memory to the pool
  * @pool: pool to add new memory chunk to
- * @addr: starting address of memory chunk to add to pool
+ * @virt: virtual starting address of memory chunk to add to pool
+ * @phys: physical starting address of memory chunk to add to pool
  * @size: size in bytes of the memory chunk to add to pool
  * @nid: node id of the node the chunk structure and bitmap should be
  *   allocated on, or -1
  *
  * Add a new chunk of special memory to the specified pool.
  */
-int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
-		 int nid)
+int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, unsigned long phys,
+		 size_t size, int nid)
 {
 	struct gen_pool_chunk *chunk;
 	int nbits = size >> pool->min_alloc_order;
@@ -61,8 +62,9 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
 		return -1;
 
 	spin_lock_init(&chunk->lock);
-	chunk->start_addr = addr;
-	chunk->end_addr = addr + size;
+	chunk->phys_addr = phys;
+	chunk->start_addr = virt;
+	chunk->end_addr = virt + size;
 
 	write_lock(&pool->lock);
 	list_add(&chunk->next_chunk, &pool->chunks);
@@ -70,7 +72,30 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
 
 	return 0;
 }
-EXPORT_SYMBOL(gen_pool_add);
+EXPORT_SYMBOL(gen_pool_add_virt);
+
+/**
+ * gen_pool_virt_to_phys - return the physical address of memory
+ * @pool: pool to allocate from
+ * @addr: starting address of memory
+ */
+unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long addr)
+{
+	struct list_head *_chunk;
+	struct gen_pool_chunk *chunk;
+
+	read_lock(&pool->lock);
+	list_for_each(_chunk, &pool->chunks) {
+		chunk = list_entry(_chunk, struct gen_pool_chunk, next_chunk);
+
+		if (addr >= chunk->start_addr && addr < chunk->end_addr)
+			return chunk->phys_addr + addr - chunk->start_addr;
+	}
+	read_unlock(&pool->loc

Re: [RFC PATCH v2] Consolidate SRAM support

2011-04-19 Thread Russell King - ARM Linux
On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote:
> Hi,
> 
>   I do post a patch to add the support to specify a virt and phys
>   address to the generic allocator so the pv-pool.c is not needed
>   we can just use the generic fucntion

You've talked about this before in the thread, but the patch never appeared.
--
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: [RFC PATCH v2] Consolidate SRAM support

2011-04-19 Thread Jean-Christophe PLAGNIOL-VILLARD
Hi,

I do post a patch to add the support to specify a virt and phys
address to the generic allocator so the pv-pool.c is not needed
we can just use the generic fucntion

I'll post a v3 updated again it

Best Regards,
J.
> --- /dev/null > +++ b/arch/arm/common/pv-pool.c
> @@ -0,0 +1,69 @@
> +/*
> + * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
> + * Copyright (C) 2009 David Brownell.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct pv_pool {
> + struct gen_pool *genpool;
> + void *cpu_base;
> + phys_addr_t phys_base;
> +};
> +
> +void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
> +{
> + void *addr = (void *)gen_pool_alloc(pool->genpool, len);
> +
> + if (phys)
> + *phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
> +  (phys_addr_t)-1ULL;
> +
> + return addr;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_alloc);
> +
> +void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
> +{
> + gen_pool_free(pool->genpool, (unsigned long)addr, len);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_free);
> +
> +struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
> + int min_alloc_order)
> +{
> + struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
> +
> + if (pool) {
> + pool->cpu_base = addr;
> + pool->phys_base = phys;
> + pool->genpool = gen_pool_create(min_alloc_order, -1);
> + if (!pool->genpool) {
> + kfree(pool);
> + pool = NULL;
> + } else {
> + WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
> + len, -1) < 0);
> + }
> + }
> +
> + return pool;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_create);
> +
> +void pv_pool_destroy(struct pv_pool *pool)
> +{
> + gen_pool_destroy(pool->genpool);
> + kfree(pool);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_destroy);
> diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
> new file mode 100644
> index 000..b7ae871
> --- /dev/null
> +++ b/arch/arm/include/asm/pv-pool.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASMARM_PV_POOL_H
> +#define __ASMARM_PV_POOL_H
> +
> +#include 
> +
> +struct pv_pool;
> +
> +void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
> +void pv_pool_free(struct pv_pool *, void *, size_t);
> +struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
> +void pv_pool_destroy(struct pv_pool *);
> +
> +/* Macro to copy a function into SRAM, using the fncpy API */
> +#define pv_pool_fncpy(pool, funcp, size) ({  \
> + size_t _sz = size;  \
> + void *_sram = pv_pool_alloc(pool, _sz, NULL);   \
> + (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);   \
> +})
> +
> +#endif
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 68fe4c2..5eca128 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = 
> {
>   .gpio_irq   = IRQ_DA8XX_GPIO0,
>   .serial_dev = &da8xx_serial_device,
>   .emac_pdata = &da8xx_emac_pdata,
> - .sram_dma   = DA8XX_ARM_RAM_BASE,
> + .sram_phys  = DA8XX_ARM_RAM_BASE,
>   .sram_len   = SZ_8K,
>   .reset_device   = &da8xx_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 76364d1..3df8730 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
>   .gpio_num   = 104,
>   .gpio_irq   = IRQ_DM355_GPIOBNK0,
>   .serial_dev = &dm355_serial_device,
> - .sram_dma   = 0x0001,
> + .sram_phys  = 0x0001,
>   .sram_len   = SZ_32K,
>   .reset_device   = &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 4604e72..d306034 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = 
> {
>   .gpio_unbanked  = 8,/* really 16 ... skip muxed GPIOs */
>   .serial_dev = &dm365_serial_device,
>   .emac_pdata = &dm365_emac_pdata,
> - .sram_dma   = 0x0001

[PATCH v2] arm: omap2: enable smc instruction for sleep34xx

2011-04-19 Thread oskar.andero
This fixes broken build when using binutils 2.21.

Signed-off-by: Oskar Andero 
---
 arch/arm/mach-omap2/Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a45cd64..512b152 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o 
smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)  += smartreflex-class3.o
 
 AFLAGS_sleep24xx.o :=-Wa,-march=armv6
-AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
 
 ifeq ($(CONFIG_PM_VERBOSE),y)
 CFLAGS_pm_bus.o+= -DDEBUG
-- 
1.7.3.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] arm: omap2: enable smc instruction for sleep34xx

2011-04-19 Thread Anderö, Oskar
> On Tue, Apr 19, 2011 at 12:13:26PM +0200, "Anderö, Oskar" wrote:
> > > > > Ping!
> > > > >
> > > > > Anyone else that gets bitten by the following when compiling
> > > > omap2plus_defconfig with gcc 4.5:
> > > > > arch/arm/mach-omap2/sleep34xx.S:150: Error: selected processor
> does
> > > not
> > > > support ARM mode `smc #1'
> > > > >
> > > > > -Oskar
> > > > >
> > > >
> > > > I can report that I get the exact same compile error as this.
> > > > OP patch worked beautifully.
> > > >
> > > > -Alex
> > >
> > > Can you check what options are being passed to the compiler
> > > and the assembler, and check for .arch / .arch_extension directives
> > > in the assembler input?
> > >
> > > i.e.,
> > >
> > > make V=1 CFLAGS_KERNEL='-v -save-temps' arch/arm/mach-
> omap2/sleep34xx.o
> > >
> > > ...and look at the output and the generated sleep34xx.s
> > >
> > > Maybe the options being passed to the compiler/assembler are wrong
> > > somewhere along the line.
> > Yes, the "+sec" extension of armv7-a (i.e. -march=armv7-a+sec) is
> missing and hence the smc instruction can't be used. This is what my
> patch fixes. I guess earlier versions of binutils silently ignored this.
> >
> > It's not visible in my patch, but plus_sec is declared as:
> > plus_sec := $(call as-instr,.arch_extension sec,+sec)
> 
> Ah right, I was slightly confused by the context.
> 
> You're right -- sleep34xx.S also needs this change in the Makefile,
> as per your patch.  This isn't new; the original patch focused on
> omap4, so I guess this file was just missed.
I will soon resubmit the patch (v2) with a slightly more correct git comment. 
Please, feel free to review it or ack it. ;)

-Oskar

--
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: [RFC PATCH] Consolidate SRAM support

2011-04-19 Thread Tomi Valkeinen
Hi Tony and Russell,

On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> * Tomi Valkeinen  [110418 09:57]:

> > So, I can make a patch that removes the SRAM support from omapfb, and
> > queue it up for the next merge window.
> 
> OK. That patch should probably go into Russell's tree along with
> other SRAM related patches to avoid conflicts.

Here's a simple patch to remove SRAM support from omapfb. Or more
precisely, this just disables it.

I started to remove the SRAM support from the drivers, but the patches
got quite big and will probably cause conflicts if they reside in
somebody else's tree than mine. So I believe it's easiest to divide SRAM
FB removal into this patch, handled by Russell (?), and then the rest,
handled by me.

Is there something else related to OMAP FB than the code removed in this
patch that is hindering the SRAM work?

 Tomi


>From 8a32eb1762d9ecead1aee08cbe955748d67999fd Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Tue, 19 Apr 2011 16:58:51 +0300
Subject: [PATCH] OMAP: Remove reserve_sram calls to omapfb

This patch removes calls from arch/arm/plat-omap/sram.c to
omapfb_reserve_sram() and omap_vram_reserve_sram(), effectively
disabling SRAM support for the old and new display drivers.

SRAM code in the display drivers will be removed in separate patches.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/plat-omap/sram.c |   13 -
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..e10eeed 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -32,7 +31,6 @@
 #include 
 
 #include "sram.h"
-#include "fb.h"
 
 /* XXX These "sideways" includes are a sign that something is wrong */
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
@@ -170,17 +168,6 @@ static void __init omap_detect_sram(void)
omap_sram_size = 0x4000;
}
}
-   reserved = omapfb_reserve_sram(omap_sram_start, omap_sram_base,
-  omap_sram_size,
-  omap_sram_start + SRAM_BOOTLOADER_SZ,
-  omap_sram_size - SRAM_BOOTLOADER_SZ);
-   omap_sram_size -= reserved;
-
-   reserved = omap_vram_reserve_sram(omap_sram_start, omap_sram_base,
-   omap_sram_size,
-   omap_sram_start + SRAM_BOOTLOADER_SZ,
-   omap_sram_size - SRAM_BOOTLOADER_SZ);
-   omap_sram_size -= reserved;
 
omap_sram_ceil = omap_sram_base + omap_sram_size;
 }
-- 
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 v3] ARM: omap2: mtd split nand_scan in ident and tail

2011-04-19 Thread Jan Weitzel
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 
Reviewed-by: Vimal Singh 
---
v2:
update commit message
v3:
Add Reviewed-by

 drivers/mtd/nand/omap2.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..288423f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1073,9 +1073,9 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
/* DIP switches on some boards change between 8 and 16 bit
 * bus widths for flash.  Try the other width if the first try fails.
 */
-   if (nand_scan(&info->mtd, 1)) {
+   if (nand_scan_ident(&info->mtd, 1, NULL)) {
info->nand.options ^= NAND_BUSWIDTH_16;
-   if (nand_scan(&info->mtd, 1)) {
+   if (nand_scan_ident(&info->mtd, 1, NULL)) {
err = -ENXIO;
goto out_release_mem_region;
}
@@ -1101,6 +1101,12 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
info->nand.ecc.layout = &omap_oobinfo;
}
 
+   /* second phase scan */
+   if (nand_scan_tail(&info->mtd)) {
+   err = -ENXIO;
+   goto out_release_mem_region;
+   }
+
 #ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
if (err > 0)
-- 
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


Re: Code for v2.6.39 merge window frozen, patches archived

2011-04-19 Thread Tony Lindgren
* Nicolas Pitre  [110419 06:24]:
> On Tue, 19 Apr 2011, Tony Lindgren wrote:
> 
> > Aaro and I speculated that boards using u-boot with uImage work,
> > while n900 is using zImage and fails with the same kernel probably
> > because of the different placement of compressed image in the
> > memory.
> 
> Could you try the following (by changing the argument to mkimage 
> accordingly).
>
> Try to load the kernel at the following offsets:
> 
> - 0x8000 from start of memory
> 
> - 0x10 from start of memory
> 
> - 0x300 from start of memory
> 
> and tell me if any of those behaves differently?

Hmm good idea, but no luck so far :( Did the tests with
setenv loadaddr in u-boot as that's what it seems to use.

v2.6.39-rc4 boots uImage with all those just fine. And with
the DT append and related patches, it always fails if DT data
is appended.

So for some reason loading a kernel on n900 with flasher -l
always fails (except for smaller kernels) and DT append with
data appended always fails.

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


Re: Code for v2.6.39 merge window frozen, patches archived

2011-04-19 Thread Nicolas Pitre
On Tue, 19 Apr 2011, Tony Lindgren wrote:

> Aaro and I speculated that boards using u-boot with uImage work,
> while n900 is using zImage and fails with the same kernel probably
> because of the different placement of compressed image in the
> memory.

Could you try the following (by changing the argument to mkimage 
accordingly).
Try to load the kernel at the following offsets:

- 0x8000 from start of memory

- 0x10 from start of memory

- 0x300 from start of memory

and tell me if any of those behaves differently?


Nicolas
--
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: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Arnd Bergmann
On Tuesday 19 April 2011, Kyungmin Park wrote:
> On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann  wrote:
> > On Tuesday 19 April 2011, Kyungmin Park wrote:
> >> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
> >> > On Monday 18 April 2011, Kyungmin Park wrote:
> >> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
> >> >> >
> >> >> > One missing piece is still a way for a platform to provide both
> >> >> > the iommu and the dma-mapping API in a unified driver. Right now,
> >> >> > you have to export both interface for a generic solution.
> >> >>
> >> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
> >> >> implementation into mm, but MM did't accept it.
> >> >
> >> > I'm confused. What do you mean with MM?
> >> linux/mm, Memory Management.
> >
> > I'm still confused. What were you suggesting to merge in there?
> > Do you have a link to a mailing list discussion?
> 
> First, Zach Pfeffer  sent the patch
> https://patchwork.kernel.org/patch/108736/
> 
> Second, Michal tried it.
> http://lkml.org/lkml/2010/9/6/41
> 
> http://lwn.net/Articles/403643/
> https://patchwork.kernel.org/patch/157451/

Ah, I did not realize you were talking about VCMM. I believe the main
reason what that patch was not received well is that it tried to add
yet another abstraction for IOMMUs when we already have too many of them.

It is essentially doing the opposite of what I was referring to above:
If we had added VCMM, each platform that has IOMMUs would now have to 
implement three interfaces: dma-mapping.h (struct dma_map_ops),
iommu.h (struct iommu_ops) and and vcm_driver.h (struct vcm_driver).

What I really meant was to unify the two we already have, so that
a platform only needs to implement e.g. iommu_ops and get the dma_mapping.h
interfaces for free.

Arnd
--
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: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Russell King - ARM Linux
On Tue, Apr 19, 2011 at 09:35:56PM +0900, Kyungmin Park wrote:
> On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann  wrote:
> > On Tuesday 19 April 2011, Kyungmin Park wrote:
> >> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
> >> > On Monday 18 April 2011, Kyungmin Park wrote:
> >> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
> >> >> >
> >> >> > One missing piece is still a way for a platform to provide both
> >> >> > the iommu and the dma-mapping API in a unified driver. Right now,
> >> >> > you have to export both interface for a generic solution.
> >> >>
> >> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
> >> >> implementation into mm, but MM did't accept it.
> >> >
> >> > I'm confused. What do you mean with MM?
> >> linux/mm, Memory Management.
> >
> > I'm still confused. What were you suggesting to merge in there?
> > Do you have a link to a mailing list discussion?
> 
> First, Zach Pfeffer  sent the patch
> https://patchwork.kernel.org/patch/108736/
> 
> Second, Michal tried it.
> http://lkml.org/lkml/2010/9/6/41
> 
> http://lwn.net/Articles/403643/
> https://patchwork.kernel.org/patch/157451/

This shows why ARM is in such a problem.  People love to create new
frameworks and infrastructure where they find existing stuff lacking,
rather than looking at what other architectures do and adapt.

As I'm sure has already mentioned, the kernel already has support for
IOMMUs in the DMA path with several non-ARM architectures, and this
support is managed through the existing DMA API.

When you want a device behind an IOMMU to perform DMA, the driver
uses the DMA API in the standard way as if there was no IOMMU there.
As part of the DMA API, particularly the SG list part, the DMA API
is allowed to coalesce the SG entries together if it can arrange
the IOMMU mappings to achieve a continguous mapping for the device.
Remember, dma_map_sg() is allowed to return _fewer_ entries in the
scatterlist than was passed to it for this very purpose.

In order to transition ARM over to this, we need to modify the
scatterlist structure by enabling CONFIG_NEED_SG_DMA_LENGTH.  We
then need to arrange for the DMA API to have the hooks _both_ into
the DMA cache coherency code (to ensure that the data hits memory)
and the IOMMU code (this part is missing from ARM.)  The current
abstractions in the generic header files don't allow for this.

I don't believe there's any need for any major new framework - and I
don't think I'm alone in thinking that, especially as this point has
been raised more than once when this framework has been submitted.

I see no reason why ARM should be any different from other architectures
which have IOMMUs, and I don't see why ARM should have to invent a whole
new framework to handle IOMMUs.  And I see no explanation why the
existing hooks are unsuitable - at least as the _initial_ starting point.

So, can you please explain why your IOMMU code can not be hidden behind
the DMA API.  (Please omit any complaints about the mechanics of hooking
it in there, such things are solvable.)

--
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

2011-04-19 Thread Michael Büsch
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.

-- 
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

2011-04-19 Thread Tomi Valkeinen
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.

 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] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Kyungmin Park
On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann  wrote:
> On Tuesday 19 April 2011, Kyungmin Park wrote:
>> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
>> > On Monday 18 April 2011, Kyungmin Park wrote:
>> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
>> >> >
>> >> > One missing piece is still a way for a platform to provide both
>> >> > the iommu and the dma-mapping API in a unified driver. Right now,
>> >> > you have to export both interface for a generic solution.
>> >>
>> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
>> >> implementation into mm, but MM did't accept it.
>> >
>> > I'm confused. What do you mean with MM?
>> linux/mm, Memory Management.
>
> I'm still confused. What were you suggesting to merge in there?
> Do you have a link to a mailing list discussion?

First, Zach Pfeffer  sent the patch
https://patchwork.kernel.org/patch/108736/

Second, Michal tried it.
http://lkml.org/lkml/2010/9/6/41

http://lwn.net/Articles/403643/
https://patchwork.kernel.org/patch/157451/

Thank you,
Kyungmin Park

>
>        Arnd
>
--
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

2011-04-19 Thread Michael Büsch
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.

-- 
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

2011-04-19 Thread Tony Lindgren
* Tomi Valkeinen  [110419 15:17]:
> Hi Tony, All,
> 
> Due to the recent SRAM discussion I started removing SRAM support from
> the new omapdss and omapfb driver, which was quite a simple task. Then I
> realized that the old omapfb driver also contains SRAM code, removing of
> which which wasn't such a simple task. I think I got that solved, but it
> needs still cleaning up.

OK
 
> 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.
> 
> What is the status of OMAP1 support in general? Is having a working
> framebuffer for OMAP1 boards something we need? 

There are people actively using omap1 boards with the framebuffer, so
let's not mess with that except to remove the SRAM support.
 
> Will there be a single kernel config containing OMAP1 and OMAP2+ support
> in the future? This will cause problems, as the old and new display
> drivers cannot coexist currently.

This will not happen any time soon (if ever) because of issues supporting
anything below ARMv6 together with ARMv6 and 7 in the same kernel binary.
 
> I have never worked with an OMAP1 board, and I don't own one, and thus I
> don't have any experience on OMAP1 display HW. This will make any work I
> do on OMAP1 omapfb slightly difficult, but if there's clear need for
> OMAP1 fb, then I think the only way to go is to convert the old omapfb
> driver to an OMAP1 framebuffer driver.

Yeh we can just make old omapfb depends on ARCH_OMAP1.
 
> But whatever is decided on OMAP1 fb, I'll start converting the OMAP2
> drivers to the new DSS2.

OK great.

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


The old omapfb support

2011-04-19 Thread Tomi Valkeinen
Hi Tony, All,

Due to the recent SRAM discussion I started removing SRAM support from
the new omapdss and omapfb driver, which was quite a simple task. Then I
realized that the old omapfb driver also contains SRAM code, removing of
which which wasn't such a simple task. I think I got that solved, but it
needs still cleaning up.

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.

What is the status of OMAP1 support in general? Is having a working
framebuffer for OMAP1 boards something we need? 

Will there be a single kernel config containing OMAP1 and OMAP2+ support
in the future? This will cause problems, as the old and new display
drivers cannot coexist currently.

I have never worked with an OMAP1 board, and I don't own one, and thus I
don't have any experience on OMAP1 display HW. This will make any work I
do on OMAP1 omapfb slightly difficult, but if there's clear need for
OMAP1 fb, then I think the only way to go is to convert the old omapfb
driver to an OMAP1 framebuffer driver.

But whatever is decided on OMAP1 fb, I'll start converting the OMAP2
drivers to the new DSS2.

 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] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Arnd Bergmann
On Tuesday 19 April 2011, Kyungmin Park wrote:
> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
> > On Monday 18 April 2011, Kyungmin Park wrote:
> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
> >> >
> >> > One missing piece is still a way for a platform to provide both
> >> > the iommu and the dma-mapping API in a unified driver. Right now,
> >> > you have to export both interface for a generic solution.
> >>
> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
> >> implementation into mm, but MM did't accept it.
> >
> > I'm confused. What do you mean with MM?
> linux/mm, Memory Management.

I'm still confused. What were you suggesting to merge in there?
Do you have a link to a mailing list discussion?

Arnd
--
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 6/7] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file

2011-04-19 Thread Tomi Valkeinen
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> An on-board panel named picodlp projector is available for OMAP4430 SDP.
> 
> Entry for this panel is being added in dss_devices in the board file.
> It also needs 4 GPIO pins and are defined and used in board file.
> picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
> 
> Signed-off-by: Mayuresh Janorkar 
> Signed-off-by: Mythri P K 
> ---
>  arch/arm/mach-omap2/board-4430sdp.c |   40 
> +++
>  1 files changed, 40 insertions(+), 0 deletions(-)
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 1503f0b..6827612
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mux.h"
>  #include "hsmmc.h"
> @@ -585,6 +586,7 @@ static struct i2c_board_info __initdata 
> sdp4430_i2c_boardinfo[] = {
>   .platform_data = &sdp4430_twldata,
>   },
>  };
> +

Unneeded change.

>  static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
>   {
>   I2C_BOARD_INFO("tmp105", 0x48),
> @@ -598,6 +600,7 @@ static struct i2c_board_info __initdata 
> sdp4430_i2c_4_boardinfo[] = {
>   I2C_BOARD_INFO("hmc5843", 0x1e),
>   },
>  };
> +

Unneeded change.

 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 5/7] OMAP: DSS: Adding initialization routine to picodlp panel

2011-04-19 Thread Tomi Valkeinen
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K 
> 
> picodlp_i2c_client needs to send commands over i2c as a part of 
> initialiazation.
> system controller dlp pico processor dpp2600 is used.
> It configures the splash screen of picodlp using a sequence of commands.
> A programmer's guide is available at:
> http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
> 
> API is defined for sending command over i2c as an i2c_write operation.
> 
> Signed-off-by: Mythri P K 
> Signed-off-by: Mayuresh Janorkar 
> ---
>  drivers/video/omap2/displays/panel-picodlp.c |  317 
> ++
>  1 files changed, 317 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/displays/panel-picodlp.c 
> b/drivers/video/omap2/displays/panel-picodlp.c
> index e361674..785e406 100644
> --- a/drivers/video/omap2/displays/panel-picodlp.c
> +++ b/drivers/video/omap2/displays/panel-picodlp.c
> @@ -32,7 +32,15 @@
>  #include 
>  #include 
>  
> +#include "panel-picodlp.h"
> +
>  #define DRIVER_NAME  "picodlp_i2c_driver"
> +
> +/* This defines the minit of data which is allowed into single write block */
> +#define MAX_I2C_WRITE_BLOCK_SIZE 32
> +#define PICO_MAJOR   1 /* 2 bits */
> +#define PICO_MINOR   1 /* 2 bits */
> +
>  struct picodlp_data {
>   struct mutex lock;
>   struct i2c_client *picodlp_i2c_client;
> @@ -50,6 +58,11 @@ struct i2c_device_id picodlp_i2c_id[] = {
>   { "picodlp_i2c_driver", 0 },
>  };
>  
> +struct picodlp_i2c_command {
> + u8 reg;
> + u32 value;
> +};
> +
>  static struct omap_video_timings pico_ls_timings = {
>   .x_res  = 864,
>   .y_res  = 480,
> @@ -70,6 +83,305 @@ static inline struct picodlp_panel_data
>   return (struct picodlp_panel_data *) dssdev->data;
>  }
>  
> +static int picodlp_i2c_write_block(struct i2c_client *client,
> + u8 *data, int len)
> +{
> + struct i2c_msg msg;
> + int i, r;
> +
> + struct picodlp_i2c_data *picodlp_i2c_data = i2c_get_clientdata(client);
> +
> + if (len < 1 || len > MAX_I2C_WRITE_BLOCK_SIZE) {
> + dev_err(&client->dev,
> + "too long syn_write_block len %d\n", len);
> + return -EIO;
> + }
> +
> + mutex_lock(&picodlp_i2c_data->xfer_lock);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = len;
> + msg.buf = data;
> +
> + r = i2c_transfer(client->adapter, &msg, 1);
> + mutex_unlock(&picodlp_i2c_data->xfer_lock);
> +
> + if (r == 1) {
> + for (i = 0; i < len; i++)
> + dev_dbg(&client->dev,
> + "addr %x bw 0x%02x[%d]: 0x%02x\n",
> + client->addr, data[0] + i, i, data[i]);
> + return 0;
> + }
> +
> + dev_err(&client->dev, " picodlp_i2c_write error\n");
> + return r;

This is, at least to my eyes, a bit uncommon way to do this. Usually the
error path is handled inside an if(), and the ok path is at the end of
the function.

> +}
> +
> +static int picodlp_i2c_write(struct i2c_client *client, u8 reg, u32 value)
> +{
> + u8 data[5];
> +
> + data[0] = reg;
> + data[1] = (value & 0xFF00) >> 24;
> + data[2] = (value & 0x00FF) >> 16;
> + data[3] = (value & 0xFF00) >> 8;
> + data[4] = (value & 0x00FF);
> +
> + return picodlp_i2c_write_block(client, data, 5);
> +}
> +
> +static int picodlp_i2c_write_array(struct i2c_client *client,
> + const struct picodlp_i2c_command commands[],
> + int count)
> +{
> + int i, r = 0;
> + for (i = 0; i < count; i++) {
> + r = picodlp_i2c_write(client, commands[i].reg,
> + commands[i].value);
> + if (r)
> + return r;
> + }
> + return r;
> +}
> +
> +/**
> + * picodlp_dpp2600_flash_dma - return parameter as 0 on success or error code
> + * Configure datapath for splash image operation
> + * dpp2600 : digitally programmable potentiometer
> + * It is a system controller used for picodlp
> + *
> + * @client:  i2c_client required for operations
> + * @flash_address:   splash image to be loaded from flash
> + * @flash_num_bytes: size in bytes for flash
> + * @cmt_seqz:select mailbox to load data to
> + *   0 = sequence/DRC,
> + *   1 = CMT/splash
> + * @table_number:table_number to load flash
> + *
> + * @return
> + *   0   -   no errors
> + *   -ENXIO  - invalid flash address specified
> + *   -EINVAL - invalid mailbox specified OR invalid table_number
> + *   OR mailbox combination
> + */
> +static int picodlp_dpp2600_flash_dma(struct i2c_client *client,
> + int flash_address, int flash_num_bytes, int cmt_seqz,
> + int table_number)
> +{
> +

Re: [PATCH 0/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x

2011-04-19 Thread Tony Lindgren
* Tony Lindgren  [110419 14:42]:
> * Mike Rapoport  [110419 14:32]:
> > Hi Tony,
> > 
> > On Mon, Apr 18, 2011 at 2:21 PM, Tony Lindgren  wrote:
> > > * Mike Rapoport  [110417 01:21]:
> > > Nice job Mike :)
> > 
> > There's a _lot_ of very similar code in different board files. If
> > you'd like to I can try to create something like
> > common-board-devices.c and move most of that code there. It's not the
> > real consolidation Linus wanted, but at least all the copy-pasted
> > device initialization code would be removed.
> 
> Yes please do if you can, that helps a lot. Also most beagle
> related boards could probably have a common board-beagle.c file.
> 
> Eventually the board configuration will come from device tree.
> But until that's available, we can consolidate the code within
> arch/arm/*omap*/ as the common platform init functions will still
> be needed with configuration coming from DT.

Oh one more thing, can you please repost this series with
linux-arm-kernel list also Cc'd? That way I can apply it
without having to repost it for review.

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 0/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x

2011-04-19 Thread Tony Lindgren
* Mike Rapoport  [110419 14:32]:
> Hi Tony,
> 
> On Mon, Apr 18, 2011 at 2:21 PM, Tony Lindgren  wrote:
> > * Mike Rapoport  [110417 01:21]:
> > Nice job Mike :)
> 
> There's a _lot_ of very similar code in different board files. If
> you'd like to I can try to create something like
> common-board-devices.c and move most of that code there. It's not the
> real consolidation Linus wanted, but at least all the copy-pasted
> device initialization code would be removed.

Yes please do if you can, that helps a lot. Also most beagle
related boards could probably have a common board-beagle.c file.

Eventually the board configuration will come from device tree.
But until that's available, we can consolidate the code within
arch/arm/*omap*/ as the common platform init functions will still
be needed with configuration coming from DT.

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


Re: [PATCH 4/7] OMAP: DSS: Add i2c client driver for picodlp

2011-04-19 Thread Tomi Valkeinen
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> The configurations and data transfer with picodlp panel happens through i2c.
> An i2c client with name "picodlp_i2c_driver" is registered inside panel.
> 
> Signed-off-by: Mythri P K 
> Signed-off-by: Mayuresh Janorkar 
> Signed-off-by: Mythri P K 
> ---
>  drivers/video/omap2/displays/panel-picodlp.c |  130 
> +-
>  1 files changed, 126 insertions(+), 4 deletions(-)



> @@ -65,8 +131,10 @@ static int picodlp_panel_power_on(struct omap_dss_device 
> *dssdev)
>   msleep(675);
>   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
>  
> - return 0;
> + picodlp_i2c_data =
> + i2c_get_clientdata(picod->picodlp_i2c_client);

This variable is not used 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: [PATCH 0/2] OMAP: convert boards that use SMSC911x to use gpmc-smsc911x

2011-04-19 Thread Mike Rapoport
Hi Tony,

On Mon, Apr 18, 2011 at 2:21 PM, Tony Lindgren  wrote:
> * Mike Rapoport  [110417 01:21]:
> Nice job Mike :)

There's a _lot_ of very similar code in different board files. If
you'd like to I can try to create something like
common-board-devices.c and move most of that code there. It's not the
real consolidation Linus wanted, but at least all the copy-pasted
device initialization code would be removed.


> 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
>



-- 
    Sincerely Yours,
        Mike.
--
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 4/7] OMAP: DSS: Add i2c client driver for picodlp

2011-04-19 Thread Tomi Valkeinen
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> The configurations and data transfer with picodlp panel happens through i2c.
> An i2c client with name "picodlp_i2c_driver" is registered inside panel.
> 
> Signed-off-by: Mythri P K 
> Signed-off-by: Mayuresh Janorkar 
> Signed-off-by: Mythri P K 
> ---
>  drivers/video/omap2/displays/panel-picodlp.c |  130 
> +-
>  1 files changed, 126 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/omap2/displays/panel-picodlp.c 
> b/drivers/video/omap2/displays/panel-picodlp.c
> index 4f12903..e361674 100644
> --- a/drivers/video/omap2/displays/panel-picodlp.c
> +++ b/drivers/video/omap2/displays/panel-picodlp.c
> @@ -1,8 +1,10 @@
>  /*
>   * picodlp panel driver
> + * picodlp_i2c_driver: i2c_client driver
>   *
>   * Copyright (C) 2009-2011 Texas Instruments
>   * Author: Mythri P K 
> + * Mayuresh Janorkar 
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License version 2 as published 
> by
> @@ -23,13 +25,29 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  
> +#define DRIVER_NAME  "picodlp_i2c_driver"
>  struct picodlp_data {
>   struct mutex lock;
> + struct i2c_client *picodlp_i2c_client;
> +};
> +
> +static struct i2c_board_info picodlp_i2c_board_info = {
> + I2C_BOARD_INFO("picodlp_i2c_driver", 0x1b),
> +};

Can this be const?

> +struct picodlp_i2c_data {
> + struct mutex xfer_lock;
> +};
> +
> +struct i2c_device_id picodlp_i2c_id[] = {
> + { "picodlp_i2c_driver", 0 },
>  };

This should be static. Probably also const. 

>  static struct omap_video_timings pico_ls_timings = {
> @@ -46,9 +64,57 @@ static struct omap_video_timings pico_ls_timings = {
>   .vbp= 14,
>  };
>  
> +static inline struct picodlp_panel_data
> + *get_panel_data(const struct omap_dss_device *dssdev)
> +{
> + return (struct picodlp_panel_data *) dssdev->data;
> +}
> +
> +static int picodlp_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct picodlp_i2c_data *picodlp_i2c_data;
> +
> + picodlp_i2c_data = kzalloc(sizeof(struct picodlp_i2c_data), GFP_KERNEL);
> +
> + if (!picodlp_i2c_data)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, picodlp_i2c_data);
> +
> + return 0;
> +}
> +
> +static int picodlp_i2c_remove(struct i2c_client *client)
> +{
> + struct picodlp_i2c_data *picodlp_i2c_data =
> + i2c_get_clientdata(client);
> +
> + kfree(picodlp_i2c_data);
> + i2c_unregister_device(client);
> + return 0;
> +}
> +
> +static struct i2c_driver picodlp_i2c_driver = {
> + .driver = {
> + .name   = "picodlp_i2c_driver",
> + },
> + .probe  = picodlp_i2c_probe,
> + .remove = picodlp_i2c_remove,
> + .id_table   = picodlp_i2c_id,
> +};
> +
>  static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
>  {
> - int r;
> + int r = 0;
> + struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
> + struct picodlp_panel_data *picodlp_pdata;
> + struct picodlp_i2c_data *picodlp_i2c_data;

Local variables don't need to be very long. The reader knows this is
pico dlp driver, so prepending the variable names with "picodlp_" is
quite extra and only make the code more difficult to read.

> + picodlp_pdata = get_panel_data(dssdev);
> + gpio_set_value(picodlp_pdata->display_sel_gpio, 1);
> + gpio_set_value(picodlp_pdata->park_gpio, 1);
> + gpio_set_value(picodlp_pdata->phy_reset_gpio, 1);

Are these GIOs related to i2c? I can't find these from the DLP
documents, at least with these names.

>   if (dssdev->platform_enable) {
>   r = dssdev->platform_enable(dssdev);
> @@ -65,8 +131,10 @@ static int picodlp_panel_power_on(struct omap_dss_device 
> *dssdev)
>   msleep(675);
>   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
>  
> - return 0;
> + picodlp_i2c_data =
> + i2c_get_clientdata(picod->picodlp_i2c_client);
>  
> + return r;
>  err:
>   if (dssdev->platform_disable)
>   dssdev->platform_disable(dssdev);
> @@ -85,6 +153,11 @@ static void picodlp_panel_power_off(struct 
> omap_dss_device *dssdev)
>  static int picodlp_panel_probe(struct omap_dss_device *dssdev)
>  {
>   struct picodlp_data *picod;
> + struct picodlp_panel_data *picodlp_pdata;
> + struct i2c_adapter *adapter;
> + struct i2c_client *picodlp_i2c_client;
> + struct picodlp_i2c_data *picodlp_i2c_data;
> + int r = 0, picodlp_adapter_id;
>  
>   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF |
>   OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IVS;
> @@ -96,8 +169,38 @@ static int picodlp_panel_probe(struct omap_dss_device 
> *dssdev)
>   return -ENOMEM;

Re: [PATCH 3/7] OMAP: DSS: Adding a picodlp panel driver

2011-04-19 Thread Tomi Valkeinen
On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K 
> 
> A projector panel named picodlp is supported by OMAP.
> panel driver is required to be added with the name picodlp_panel.
> 
> It is a WVGA panel with resolution 864 X 480 and panel timing data
> is defined in the panel driver.
> 
> picodlp makes use of parallel (DPI) interface multiplexed with secondary lcd
> in case of OMAP4.
> 
> Signed-off-by: Mythri P K 
> Signed-off-by: Mayuresh Janorkar 
> ---
>  drivers/video/omap2/displays/panel-picodlp.c |  228 
> ++
>  1 files changed, 228 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
> 
> diff --git a/drivers/video/omap2/displays/panel-picodlp.c 
> b/drivers/video/omap2/displays/panel-picodlp.c
> new file mode 100644
> index 000..4f12903
> --- /dev/null
> +++ b/drivers/video/omap2/displays/panel-picodlp.c
> @@ -0,0 +1,228 @@
> +/*
> + * picodlp panel driver
> + *
> + * Copyright (C) 2009-2011 Texas Instruments
> + * Author: Mythri P K 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +struct picodlp_data {
> + struct mutex lock;
> +};
> +
> +static struct omap_video_timings pico_ls_timings = {
> + .x_res  = 864,
> + .y_res  = 480,
> + .hsw= 7,
> + .hfp= 11,
> + .hbp= 7,
> +
> + .pixel_clock= 19200,
> +
> + .vsw= 2,
> + .vfp= 3,
> + .vbp= 14,
> +};
> +
> +static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
> +{
> + int r;
> +
> + if (dssdev->platform_enable) {
> + r = dssdev->platform_enable(dssdev);
> + if (r)
> + return r;
> + }
> +
> + r = omapdss_dpi_display_enable(dssdev);
> + if (r) {
> + dev_err(&dssdev->dev, "failed to enable DPI\n");
> + goto err;
> + }
> + /* after enabling, wait for some initialize sync interrupts */
> + msleep(675);
> + dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> +
> + return 0;
> +
> +err:
> + if (dssdev->platform_disable)
> + dssdev->platform_disable(dssdev);
> +
> + return r;
> +}

Why is the msleep needed there? It's a huge sleep, and can't find
information about it from the documents you gave links to. I think I've
asked this three times already.

Also, it's rather strange to sleep at the end of the function. Normally
you would sleep between two actions.

 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 v4 0/4] OMAP: DMA: mstandby mode and runtime pm support

2011-04-19 Thread Tony Lindgren
* G, Manjunath Kondaiah  [110328 07:29]:
> 
> G, Manjunath Kondaiah (4):
>   OMAP2+: PM: omap device: API's for handling mstandby mode
>   OMAP2+: DMA: prevent races while setting M idle mode to nostandby
>   OMAP: PM: DMA: Enable runtime pm
>   OMAP: DMA: Fix: context restore during off mode
> 
>  arch/arm/mach-omap1/dma.c |1 +
>  arch/arm/mach-omap2/dma.c |   16 ++
>  arch/arm/mach-omap2/omap_hwmod.c  |   42 ++
>  arch/arm/plat-omap/dma.c  |  196 
> +
>  arch/arm/plat-omap/include/plat/dma.h |1 +
>  arch/arm/plat-omap/include/plat/omap_device.h |2 +
>  arch/arm/plat-omap/include/plat/omap_hwmod.h  |4 +-
>  arch/arm/plat-omap/omap_device.c  |   62 
>  8 files changed, 291 insertions(+), 33 deletions(-)

With the DMA code too we need to do the cleanup to move it
to drivers/dma before adding new features.

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] arm: omap2: enable smc instruction for sleep34xx

2011-04-19 Thread Dave Martin
On Tue, Apr 19, 2011 at 12:13:26PM +0200, "Anderö, Oskar" wrote:
> > > > Ping!
> > > >
> > > > Anyone else that gets bitten by the following when compiling
> > > omap2plus_defconfig with gcc 4.5:
> > > > arch/arm/mach-omap2/sleep34xx.S:150: Error: selected processor does
> > not
> > > support ARM mode `smc #1'
> > > >
> > > > -Oskar
> > > >
> > >
> > > I can report that I get the exact same compile error as this.
> > > OP patch worked beautifully.
> > >
> > > -Alex
> > 
> > Can you check what options are being passed to the compiler
> > and the assembler, and check for .arch / .arch_extension directives
> > in the assembler input?
> > 
> > i.e.,
> > 
> > make V=1 CFLAGS_KERNEL='-v -save-temps' arch/arm/mach-omap2/sleep34xx.o
> > 
> > ...and look at the output and the generated sleep34xx.s
> > 
> > Maybe the options being passed to the compiler/assembler are wrong
> > somewhere along the line.
> Yes, the "+sec" extension of armv7-a (i.e. -march=armv7-a+sec) is missing and 
> hence the smc instruction can't be used. This is what my patch fixes. I guess 
> earlier versions of binutils silently ignored this.
> 
> It's not visible in my patch, but plus_sec is declared as:
> plus_sec := $(call as-instr,.arch_extension sec,+sec)

Ah right, I was slightly confused by the context.

You're right -- sleep34xx.S also needs this change in the Makefile,
as per your patch.  This isn't new; the original patch focused on
omap4, so I guess this file was just missed.

Cheers
---Dave

> 
> The following patch added the same extension for some of the other files, but 
> I guess sleep34xx.S was missed or maybe added later:
> commit fe297dde5ae8f8bf67d3a87759289a99b48ecb2c
> Author: John Rigby 
> Date:   Wed Dec 1 05:57:51 2010 +
> 
> OMAP4: enable smc instruction in new assembler versions
> 
> New assemblers need -march=armv7-a+sec on command line or
> .arch_extension sec inline to enable use of the smc instruction.
> 
> 
> -Oskar
--
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] arm: omap2: enable smc instruction for sleep34xx

2011-04-19 Thread Anderö, Oskar
> > > Ping!
> > >
> > > Anyone else that gets bitten by the following when compiling
> > omap2plus_defconfig with gcc 4.5:
> > > arch/arm/mach-omap2/sleep34xx.S:150: Error: selected processor does
> not
> > support ARM mode `smc #1'
> > >
> > > -Oskar
> > >
> >
> > I can report that I get the exact same compile error as this.
> > OP patch worked beautifully.
> >
> > -Alex
> 
> Can you check what options are being passed to the compiler
> and the assembler, and check for .arch / .arch_extension directives
> in the assembler input?
> 
> i.e.,
> 
> make V=1 CFLAGS_KERNEL='-v -save-temps' arch/arm/mach-omap2/sleep34xx.o
> 
> ...and look at the output and the generated sleep34xx.s
> 
> Maybe the options being passed to the compiler/assembler are wrong
> somewhere along the line.
Yes, the "+sec" extension of armv7-a (i.e. -march=armv7-a+sec) is missing and 
hence the smc instruction can't be used. This is what my patch fixes. I guess 
earlier versions of binutils silently ignored this.

It's not visible in my patch, but plus_sec is declared as:
plus_sec := $(call as-instr,.arch_extension sec,+sec)

The following patch added the same extension for some of the other files, but I 
guess sleep34xx.S was missed or maybe added later:
commit fe297dde5ae8f8bf67d3a87759289a99b48ecb2c
Author: John Rigby 
Date:   Wed Dec 1 05:57:51 2010 +

OMAP4: enable smc instruction in new assembler versions

New assemblers need -march=armv7-a+sec on command line or
.arch_extension sec inline to enable use of the smc instruction.


-Oskar
--
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: Code for v2.6.39 merge window frozen, patches archived

2011-04-19 Thread Tony Lindgren
* Tony Lindgren  [110413 08:06]:
> * Nicolas Pitre  [110413 17:46]:
> > On Wed, 13 Apr 2011, Tony Lindgren wrote:
> > > 
> > > With the device tree append patch reverting commit
> > > d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> > > 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..
> > 
> > You cannot use the DT append patch without 6d7d0ae515 in place.  The 
> > later is a prerequisite for the former.
> 
> OK.
>  
> > > Anyways, that might be another way to reproduce the problem if these
> > > issues are related.
> > 
> > I've started to instrument the problematic CONFIG_KERNEL_LZMA case.  So 
> > far this is still a mystery.
> > 
> > Do you have problems with the DT append patch even with 
> > CONFIG_KERNEL_GZIP=y?
> 
> Yup. The devicetree data gets trashed by decompress_kernel
> with CONFIG_KERNEL_GZIP too with the append patch.
> 
> DT data before decompress_kernel:
> edfe0dd0 2c01 3800 f000
> 
> DT data after decompress_kernel:
> 1000 0001 3800 f000
> 
> So first 8 (not 16 bytes like I mentioned earlier) get trashed.

Aaro and I speculated that boards using u-boot with uImage work,
while n900 is using zImage and fails with the same kernel probably
because of the different placement of compressed image in the
memory.

Also boards using u-boot with uImage fail with the DT append
patch if some DT data is appended to zImage before mkimage.

Hardcoding the uncompressed image size about 2MB larger in
arch/arm/boot/Makefile makes booting n900 work. This will not
solve the DT append problem, or at least would require padding
the uncompressed image size accordingly before appending DT
data..

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] cbus: tahvo: Remove dead code from tahvo-usb.c

2011-04-19 Thread Felipe Balbi
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 

FWIW:

Reviewied-by: Felipe Balbi 

-- 
balbi
--
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] cbus: tahvo: Select USB_OTG_UTILS

2011-04-19 Thread Felipe Balbi
On Tue, Apr 19, 2011 at 11:19:38AM +0300, Jarkko Nikula wrote:
> tahvo-usb.c is using otg_set_transceiver which is built only if
> CONFIG_USB_OTG_UTILS is set.
> 
> Signed-off-by: Jarkko Nikula 

FWIW:

Reviewied-by: Felipe Balbi 

-- 
balbi
--
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: omap2/3: Use generic irq chip

2011-04-19 Thread Tony Lindgren
Use generic irq chip for omap2 & 3.

Note that this patch also leaves out the spurious IRQ warning
for omap3.

This warning should no longer be needed as the interrupt handlers
for various devices have implemented the necessayr read-back of
the posted write.

Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -73,83 +73,18 @@ static u32 intc_bank_read_reg(struct omap_irq_bank *bank, 
u16 reg)
return __raw_readl(bank->base_reg + reg);
 }
 
-static int previous_irq;
-
-/*
- * On 34xx we can get occasional spurious interrupts if the ack from
- * an interrupt handler does not get posted before we unmask. Warn about
- * the interrupt handlers that need to flush posted writes.
- */
-static int omap_check_spurious(unsigned int irq)
-{
-   u32 sir, spurious;
-
-   sir = intc_bank_read_reg(&irq_banks[0], INTC_SIR);
-   spurious = sir >> 7;
-
-   if (spurious) {
-   printk(KERN_WARNING "Spurious irq %i: 0x%08x, please flush "
-   "posted write for irq %i\n",
-   irq, sir, previous_irq);
-   return spurious;
-   }
-
-   return 0;
-}
-
 /* XXX: FIQ and additional INTC support (only MPU at the moment) */
 static void omap_ack_irq(struct irq_data *d)
 {
intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
 }
 
-static void omap_mask_irq(struct irq_data *d)
-{
-   unsigned int irq = d->irq;
-   int offset = irq & (~(IRQ_BITS_PER_REG - 1));
-
-   if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
-   int spurious = 0;
-
-   /*
-* INT_34XX_GPT12_IRQ is also the spurious irq. Maybe because
-* it is the highest irq number?
-*/
-   if (irq == INT_34XX_GPT12_IRQ)
-   spurious = omap_check_spurious(irq);
-
-   if (!spurious)
-   previous_irq = irq;
-   }
-
-   irq &= (IRQ_BITS_PER_REG - 1);
-
-   intc_bank_write_reg(1 << irq, &irq_banks[0], INTC_MIR_SET0 + offset);
-}
-
-static void omap_unmask_irq(struct irq_data *d)
-{
-   unsigned int irq = d->irq;
-   int offset = irq & (~(IRQ_BITS_PER_REG - 1));
-
-   irq &= (IRQ_BITS_PER_REG - 1);
-
-   intc_bank_write_reg(1 << irq, &irq_banks[0], INTC_MIR_CLEAR0 + offset);
-}
-
 static void omap_mask_ack_irq(struct irq_data *d)
 {
-   omap_mask_irq(d);
+   irq_gc_mask_disable_reg(d);
omap_ack_irq(d);
 }
 
-static struct irq_chip omap_irq_chip = {
-   .name   = "INTC",
-   .irq_ack= omap_mask_ack_irq,
-   .irq_mask   = omap_mask_irq,
-   .irq_unmask = omap_unmask_irq,
-};
-
 static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
 {
unsigned long tmp;
@@ -186,11 +121,31 @@ int omap_irq_pending(void)
return 0;
 }
 
+static __init void
+omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num)
+{
+   struct irq_chip_generic *gc;
+   struct irq_chip_type *ct;
+
+   gc = irq_alloc_generic_chip("INTC", 1, irq_start, base,
+   handle_level_irq);
+   ct = gc->chip_types;
+   ct->chip.irq_ack = omap_mask_ack_irq;
+   ct->chip.irq_mask = irq_gc_mask_disable_reg;
+   ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
+
+   ct->regs.ack = INTC_CONTROL;
+   ct->regs.enable = INTC_MIR_CLEAR0;
+   ct->regs.disable = INTC_MIR_SET0;
+   irq_setup_generic_chip(gc, IRQ_MSK(num),
+   IRQ_NOREQUEST | IRQ_NOPROBE, 0);
+}
+
 void __init omap_init_irq(void)
 {
unsigned long nr_of_irqs = 0;
unsigned int nr_banks = 0;
-   int i;
+   int i, j;
 
for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
unsigned long base = 0;
@@ -215,17 +170,15 @@ void __init omap_init_irq(void)
 
omap_irq_bank_init_one(bank);
 
+   for (i = 0, j= 0; i < bank->nr_irqs; i += 32, j += 0x20)
+   omap_alloc_gc(bank->base_reg + j, i, 32);
+
nr_of_irqs += bank->nr_irqs;
nr_banks++;
}
 
printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
   nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
-
-   for (i = 0; i < nr_of_irqs; i++) {
-   irq_set_chip_and_handler(i, &omap_irq_chip, handle_level_irq);
-   set_irq_flags(i, IRQF_VALID);
-   }
 }
 
 #ifdef CONFIG_ARCH_OMAP3
--
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 16/19] OMAP: DSS2: Taal: Add sysfs file for ESD interval

2011-04-19 Thread Tomi Valkeinen
Implement sysfs support to configure the ESD interval.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/displays/panel-taal.c |   42 +
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 2787a51..3192dd7 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -635,18 +635,60 @@ static ssize_t show_cabc_available_modes(struct device 
*dev,
return len < PAGE_SIZE ? len : PAGE_SIZE - 1;
 }
 
+static ssize_t taal_store_esd_interval(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct omap_dss_device *dssdev = to_dss_device(dev);
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+
+   unsigned long t;
+   int r;
+
+   r = strict_strtoul(buf, 10, &t);
+   if (r)
+   return r;
+
+   mutex_lock(&td->lock);
+   taal_cancel_esd_work(dssdev);
+   td->esd_interval = t;
+   if (td->enabled)
+   taal_queue_esd_work(dssdev);
+   mutex_unlock(&td->lock);
+
+   return count;
+}
+
+static ssize_t taal_show_esd_interval(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct omap_dss_device *dssdev = to_dss_device(dev);
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+   unsigned t;
+
+   mutex_lock(&td->lock);
+   t = td->esd_interval;
+   mutex_unlock(&td->lock);
+
+   return snprintf(buf, PAGE_SIZE, "%u\n", t);
+}
+
 static DEVICE_ATTR(num_dsi_errors, S_IRUGO, taal_num_errors_show, NULL);
 static DEVICE_ATTR(hw_revision, S_IRUGO, taal_hw_revision_show, NULL);
 static DEVICE_ATTR(cabc_mode, S_IRUGO | S_IWUSR,
show_cabc_mode, store_cabc_mode);
 static DEVICE_ATTR(cabc_available_modes, S_IRUGO,
show_cabc_available_modes, NULL);
+static DEVICE_ATTR(esd_interval, S_IRUGO | S_IWUSR,
+   taal_show_esd_interval, taal_store_esd_interval);
 
 static struct attribute *taal_attrs[] = {
&dev_attr_num_dsi_errors.attr,
&dev_attr_hw_revision.attr,
&dev_attr_cabc_mode.attr,
&dev_attr_cabc_available_modes.attr,
+   &dev_attr_esd_interval.attr,
NULL,
 };
 
-- 
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 19/19] OMAP: DSS2: Taal: Implement ULPS functionality

2011-04-19 Thread Tomi Valkeinen
ULPS is a low power state where the DSI lanes are kept at ground. This
patch implements ULPS by having a DSI bus inactivity timer which
triggers the entry to ULPS. ULPS exit will happen automatically when the
driver needs to do something on the DSI lanes.

The ulps_timeout is configurable from board file or via sysfs.
Additionally another sysfs file, "ulps", can be used to check the
current ULPS state, or to manually enter or exit ULPS.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/plat-omap/include/plat/nokia-dsi-panel.h |2 +
 drivers/video/omap2/displays/panel-taal.c |  310 -
 2 files changed, 305 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h 
b/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
index aaa1c14..36ba7bd 100644
--- a/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
+++ b/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
@@ -9,6 +9,7 @@
  * @use_ext_te: use external TE
  * @ext_te_gpio: external TE GPIO
  * @esd_interval: interval of ESD checks, 0 = disabled (ms)
+ * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
  * @max_backlight_level: maximum backlight level
  * @set_backlight: pointer to backlight set function
  * @get_backlight: pointer to backlight get function
@@ -22,6 +23,7 @@ struct nokia_dsi_panel_data {
int ext_te_gpio;
 
unsigned esd_interval;
+   unsigned ulps_timeout;
 
int max_backlight_level;
int (*set_backlight)(struct omap_dss_device *dssdev, int level);
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 9626e49..78ad355 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -67,6 +67,8 @@ static irqreturn_t taal_te_isr(int irq, void *data);
 static void taal_te_timeout_work_callback(struct work_struct *work);
 static int _taal_enable_te(struct omap_dss_device *dssdev, bool enable);
 
+static int taal_panel_reset(struct omap_dss_device *dssdev);
+
 struct panel_regulator {
struct regulator *regulator;
const char *name;
@@ -232,6 +234,10 @@ struct taal_data {
struct delayed_work esd_work;
unsigned esd_interval;
 
+   bool ulps_enabled;
+   unsigned ulps_timeout;
+   struct delayed_work ulps_work;
+
struct panel_config *panel_config;
 };
 
@@ -242,6 +248,7 @@ static inline struct nokia_dsi_panel_data
 }
 
 static void taal_esd_work(struct work_struct *work);
+static void taal_ulps_work(struct work_struct *work);
 
 static void hw_guard_start(struct taal_data *td, int guard_msec)
 {
@@ -437,6 +444,107 @@ static void taal_cancel_esd_work(struct omap_dss_device 
*dssdev)
cancel_delayed_work(&td->esd_work);
 }
 
+static void taal_queue_ulps_work(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+
+   if (td->ulps_timeout > 0)
+   queue_delayed_work(td->workqueue, &td->ulps_work,
+   msecs_to_jiffies(td->ulps_timeout));
+}
+
+static void taal_cancel_ulps_work(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+
+   cancel_delayed_work(&td->ulps_work);
+}
+
+static int taal_enter_ulps(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
+   int r;
+
+   if (td->ulps_enabled)
+   return 0;
+
+   taal_cancel_ulps_work(dssdev);
+
+   r = _taal_enable_te(dssdev, false);
+   if (r)
+   goto err;
+
+   disable_irq(gpio_to_irq(panel_data->ext_te_gpio));
+
+   omapdss_dsi_display_disable(dssdev, false, true);
+
+   td->ulps_enabled = true;
+
+   return 0;
+
+err:
+   dev_err(&dssdev->dev, "enter ULPS failed");
+   taal_panel_reset(dssdev);
+
+   td->ulps_enabled = false;
+
+   taal_queue_ulps_work(dssdev);
+
+   return r;
+}
+
+static int taal_exit_ulps(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
+   int r;
+
+   if (!td->ulps_enabled)
+   return 0;
+
+   r = omapdss_dsi_display_enable(dssdev);
+   if (r)
+   goto err;
+
+   omapdss_dsi_vc_enable_hs(td->channel, true);
+
+   r = _taal_enable_te(dssdev, true);
+   if (r)
+   goto err;
+
+   enable_irq(gpio_to_irq(panel_data->ext_te_gpio));
+
+   taal_queue_ulps_work(dssdev);
+
+   td->ulps_enabled = false;
+
+   return 0;
+
+err:
+   dev_err(&dssdev->dev, "exit ULPS failed");
+   r = taal_panel_reset(dssdev);
+
+   enable_irq(gpio_to_irq(panel_data->ext_te_gpio));
+   td->ulps_enabled = false;
+
+   taal_queue_ulps_work(dssdev);
+
+   return r;
+}
+
+static int taal_wake_up(struct om

[PATCH 17/19] OMAP: DSS2: Taal: Separate panel reset

2011-04-19 Thread Tomi Valkeinen
Separate panel reset code to a function of its own. This will keep the
code cleaner in the future when panel reset is called from multiple
locations.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/displays/panel-taal.c |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 3192dd7..2f7a223 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1018,6 +1018,15 @@ static void taal_power_off(struct omap_dss_device 
*dssdev)
td->enabled = 0;
 }
 
+static int taal_panel_reset(struct omap_dss_device *dssdev)
+{
+   dev_err(&dssdev->dev, "performing LCD reset\n");
+
+   taal_power_off(dssdev);
+   taal_hw_reset(dssdev);
+   return taal_power_on(dssdev);
+}
+
 static int taal_enable(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
@@ -1582,9 +1591,7 @@ static void taal_esd_work(struct work_struct *work)
 err:
dev_err(&dssdev->dev, "performing LCD reset\n");
 
-   taal_power_off(dssdev);
-   taal_hw_reset(dssdev);
-   taal_power_on(dssdev);
+   taal_panel_reset(dssdev);
 
dsi_bus_unlock();
 
-- 
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 18/19] OMAP: DSS2: Taal: Rename esd_wq to workqueue

2011-04-19 Thread Tomi Valkeinen
ESD workqueue will be shared with other functionality also. Rename
"esd_wq" to "workqueue" to better reflect its usage.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/displays/panel-taal.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 2f7a223..9626e49 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -227,7 +227,8 @@ struct taal_data {
 
bool intro_printed;
 
-   struct workqueue_struct *esd_wq;
+   struct workqueue_struct *workqueue;
+
struct delayed_work esd_work;
unsigned esd_interval;
 
@@ -425,7 +426,7 @@ static void taal_queue_esd_work(struct omap_dss_device 
*dssdev)
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
 
if (td->esd_interval > 0)
-   queue_delayed_work(td->esd_wq, &td->esd_work,
+   queue_delayed_work(td->workqueue, &td->esd_work,
msecs_to_jiffies(td->esd_interval));
 }
 
@@ -768,8 +769,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
if (r)
goto err_reg;
 
-   td->esd_wq = create_singlethread_workqueue("taal_esd");
-   if (td->esd_wq == NULL) {
+   td->workqueue = create_singlethread_workqueue("taal_esd");
+   if (td->workqueue == NULL) {
dev_err(&dssdev->dev, "can't create ESD workqueue\n");
r = -ENOMEM;
goto err_wq;
@@ -868,7 +869,7 @@ err_irq:
 err_gpio:
backlight_device_unregister(bldev);
 err_bl:
-   destroy_workqueue(td->esd_wq);
+   destroy_workqueue(td->workqueue);
 err_wq:
free_regulators(panel_config->regulators, panel_config->num_regulators);
 err_reg:
@@ -900,7 +901,7 @@ static void __exit taal_remove(struct omap_dss_device 
*dssdev)
backlight_device_unregister(bldev);
 
taal_cancel_esd_work(dssdev);
-   destroy_workqueue(td->esd_wq);
+   destroy_workqueue(td->workqueue);
 
/* reset, to be sure that the panel is in a valid state */
taal_hw_reset(dssdev);
-- 
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 15/19] OMAP: DSS2: Taal: Clean up ESD queueing

2011-04-19 Thread Tomi Valkeinen
Separate the code which queues/cancels ESD work into their own
functions.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/displays/panel-taal.c |   36 ++--
 1 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index cdb28a8..2787a51 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -420,6 +420,22 @@ static int taal_set_update_window(struct taal_data *td,
return r;
 }
 
+static void taal_queue_esd_work(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+
+   if (td->esd_interval > 0)
+   queue_delayed_work(td->esd_wq, &td->esd_work,
+   msecs_to_jiffies(td->esd_interval));
+}
+
+static void taal_cancel_esd_work(struct omap_dss_device *dssdev)
+{
+   struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+
+   cancel_delayed_work(&td->esd_work);
+}
+
 static int taal_bl_update_status(struct backlight_device *dev)
 {
struct omap_dss_device *dssdev = dev_get_drvdata(&dev->dev);
@@ -841,7 +857,7 @@ static void __exit taal_remove(struct omap_dss_device 
*dssdev)
taal_bl_update_status(bldev);
backlight_device_unregister(bldev);
 
-   cancel_delayed_work(&td->esd_work);
+   taal_cancel_esd_work(dssdev);
destroy_workqueue(td->esd_wq);
 
/* reset, to be sure that the panel is in a valid state */
@@ -983,9 +999,7 @@ static int taal_enable(struct omap_dss_device *dssdev)
if (r)
goto err;
 
-   if (td->esd_interval > 0)
-   queue_delayed_work(td->esd_wq, &td->esd_work,
-   msecs_to_jiffies(td->esd_interval));
+   taal_queue_esd_work(dssdev);
 
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
@@ -1006,7 +1020,7 @@ static void taal_disable(struct omap_dss_device *dssdev)
 
mutex_lock(&td->lock);
 
-   cancel_delayed_work(&td->esd_work);
+   taal_cancel_esd_work(dssdev);
 
dsi_bus_lock();
 
@@ -1034,7 +1048,7 @@ static int taal_suspend(struct omap_dss_device *dssdev)
goto err;
}
 
-   cancel_delayed_work(&td->esd_work);
+   taal_cancel_esd_work(dssdev);
 
dsi_bus_lock();
 
@@ -1076,9 +1090,7 @@ static int taal_resume(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
} else {
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-   if (td->esd_interval > 0)
-   queue_delayed_work(td->esd_wq, &td->esd_work,
-   msecs_to_jiffies(td->esd_interval));
+   taal_queue_esd_work(dssdev);
}
 
mutex_unlock(&td->lock);
@@ -1521,8 +1533,7 @@ static void taal_esd_work(struct work_struct *work)
 
dsi_bus_unlock();
 
-   queue_delayed_work(td->esd_wq, &td->esd_work,
-  msecs_to_jiffies(td->esd_interval));
+   taal_queue_esd_work(dssdev);
 
mutex_unlock(&td->lock);
return;
@@ -1535,8 +1546,7 @@ err:
 
dsi_bus_unlock();
 
-   queue_delayed_work(td->esd_wq, &td->esd_work,
-  msecs_to_jiffies(td->esd_interval));
+   taal_queue_esd_work(dssdev);
 
mutex_unlock(&td->lock);
 }
-- 
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 12/19] OMAP: DSS2: DSI: Add DSI pad muxing support

2011-04-19 Thread Tomi Valkeinen
Add dsi_mux_pads function pointer to omap_dss_board_info, and use the
function pointer in DSI code to configure the DSI pads either to normal
DSI operation, or to pull down when in ULPS.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/plat-omap/include/plat/display.h |1 +
 drivers/video/omap2/dss/dsi.c |   15 +++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index a65479c..bd0f08e 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -235,6 +235,7 @@ struct omap_dss_board_info {
int num_devices;
struct omap_dss_device **devices;
struct omap_dss_device *default_device;
+   void (*dsi_mux_pads)(bool enable);
 };
 
 #if defined(CONFIG_OMAP2_DSS_MODULE) || defined(CONFIG_OMAP2_DSS)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d15014e..f1e14ca 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -244,6 +244,8 @@ static struct
void __iomem*base;
int irq;
 
+   void (*dsi_mux_pads)(bool enable);
+
struct dsi_clock_info current_cinfo;
 
bool vdds_dsi_enabled;
@@ -2035,6 +2037,9 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
 
DSSDBGF();
 
+   if (dsi.dsi_mux_pads)
+   dsi.dsi_mux_pads(true);
+
dsi_enable_scp_clk();
 
/* A dummy read using the SCP interface to any DSIPHY register is
@@ -2122,6 +2127,8 @@ err_cio_pwr:
dsi_cio_disable_lane_override();
 err_scp_clk_dom:
dsi_disable_scp_clk();
+   if (dsi.dsi_mux_pads)
+   dsi.dsi_mux_pads(false);
return r;
 }
 
@@ -2129,6 +2136,8 @@ static void dsi_cio_uninit(void)
 {
dsi_cio_power(DSI_COMPLEXIO_POWER_OFF);
dsi_disable_scp_clk();
+   if (dsi.dsi_mux_pads)
+   dsi.dsi_mux_pads(false);
 }
 
 static int _dsi_wait_reset(void)
@@ -3993,10 +4002,16 @@ static void dsi_calc_clock_param_ranges(void)
 
 static int dsi_init(struct platform_device *pdev)
 {
+   struct omap_display_platform_data *dss_plat_data;
+   struct omap_dss_board_info *board_info;
u32 rev;
int r, i;
struct resource *dsi_mem;
 
+   dss_plat_data = pdev->dev.platform_data;
+   board_info = dss_plat_data->board_data;
+   dsi.dsi_mux_pads = board_info->dsi_mux_pads;
+
spin_lock_init(&dsi.irq_lock);
spin_lock_init(&dsi.errors_lock);
dsi.errors = 0;
-- 
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 14/19] OMAP: DSS2: Taal: Implement configurable ESD interval

2011-04-19 Thread Tomi Valkeinen
ESD check in Taal driver is currently on/off feature with hardcoded
interval. This patch changes it to a configurable interval, which can be
set from the board file.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-4430sdp.c   |2 +-
 arch/arm/plat-omap/include/plat/nokia-dsi-panel.h |4 ++--
 drivers/video/omap2/displays/panel-taal.c |   20 ++--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 1503f0b..570e83f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -753,7 +753,7 @@ static struct nokia_dsi_panel_data dsi1_panel = {
.reset_gpio = 102,
.use_ext_te = false,
.ext_te_gpio= 101,
-   .use_esd_check  = false,
+   .esd_interval   = 0,
.set_backlight  = dsi1_panel_set_backlight,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h 
b/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
index 01ab657..aaa1c14 100644
--- a/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
+++ b/arch/arm/plat-omap/include/plat/nokia-dsi-panel.h
@@ -8,7 +8,7 @@
  * @name: panel name
  * @use_ext_te: use external TE
  * @ext_te_gpio: external TE GPIO
- * @use_esd_check: perform ESD checks
+ * @esd_interval: interval of ESD checks, 0 = disabled (ms)
  * @max_backlight_level: maximum backlight level
  * @set_backlight: pointer to backlight set function
  * @get_backlight: pointer to backlight get function
@@ -21,7 +21,7 @@ struct nokia_dsi_panel_data {
bool use_ext_te;
int ext_te_gpio;
 
-   bool use_esd_check;
+   unsigned esd_interval;
 
int max_backlight_level;
int (*set_backlight)(struct omap_dss_device *dssdev, int level);
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index d68119e..cdb28a8 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -63,8 +63,6 @@
 #define DCS_GET_ID20xdb
 #define DCS_GET_ID30xdc
 
-#define TAAL_ESD_CHECK_PERIOD  msecs_to_jiffies(5000)
-
 static irqreturn_t taal_te_isr(int irq, void *data);
 static void taal_te_timeout_work_callback(struct work_struct *work);
 static int _taal_enable_te(struct omap_dss_device *dssdev, bool enable);
@@ -231,6 +229,7 @@ struct taal_data {
 
struct workqueue_struct *esd_wq;
struct delayed_work esd_work;
+   unsigned esd_interval;
 
struct panel_config *panel_config;
 };
@@ -700,6 +699,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
}
td->dssdev = dssdev;
td->panel_config = panel_config;
+   td->esd_interval = panel_data->esd_interval;
 
mutex_init(&td->lock);
 
@@ -963,7 +963,6 @@ static void taal_power_off(struct omap_dss_device *dssdev)
 static int taal_enable(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
int r;
 
dev_dbg(&dssdev->dev, "enable\n");
@@ -984,9 +983,9 @@ static int taal_enable(struct omap_dss_device *dssdev)
if (r)
goto err;
 
-   if (panel_data->use_esd_check)
+   if (td->esd_interval > 0)
queue_delayed_work(td->esd_wq, &td->esd_work,
-   TAAL_ESD_CHECK_PERIOD);
+   msecs_to_jiffies(td->esd_interval));
 
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
@@ -1056,7 +1055,6 @@ err:
 static int taal_resume(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
int r;
 
dev_dbg(&dssdev->dev, "resume\n");
@@ -1078,9 +1076,9 @@ static int taal_resume(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
} else {
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-   if (panel_data->use_esd_check)
+   if (td->esd_interval > 0)
queue_delayed_work(td->esd_wq, &td->esd_work,
-   TAAL_ESD_CHECK_PERIOD);
+   msecs_to_jiffies(td->esd_interval));
}
 
mutex_unlock(&td->lock);
@@ -1523,7 +1521,8 @@ static void taal_esd_work(struct work_struct *work)
 
dsi_bus_unlock();
 
-   queue_delayed_work(td->esd_wq, &td->esd_work, TAAL_ESD_CHECK_PERIOD);
+   queue_delayed_work(td->esd_wq, &td->esd_work,
+  msecs_to_jiffies(td->esd_interval));
 
mutex_unlock(&td->lock);
return;
@@ -1536,7 +1535,8 @@ err:
 
dsi_bus_unlock();
 
-   queue_delayed_work(td->esd_wq, &td->esd_work, TAAL_ESD_CHECK_PERIOD);
+   queue_de

[PATCH 10/19] OMAP: DSS2: DSI: wait for TXCLKESC domain to come out of reset

2011-04-19 Thread Tomi Valkeinen
Add dsi_cio_wait_tx_clk_esc_reset() function which waits for the
TXCLKESC domains to come out of reset.

Things have worked fine without this, but better be safe than sorry.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   65 +
 1 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9f450af..8d85635 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1969,6 +1969,65 @@ static void dsi_cio_disable_lane_override(void)
REG_FLD_MOD(DSI_DSIPHY_CFG10, 0, 22, 17); /* REGLPTXSCPDAT4TO0DXDY */
 }
 
+static int dsi_cio_wait_tx_clk_esc_reset(struct omap_dss_device *dssdev)
+{
+   int t;
+   int bits[3];
+   bool in_use[3];
+
+   if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
+   bits[0] = 28;
+   bits[1] = 27;
+   bits[2] = 26;
+   } else {
+   bits[0] = 24;
+   bits[1] = 25;
+   bits[2] = 26;
+   }
+
+   in_use[0] = false;
+   in_use[1] = false;
+   in_use[2] = false;
+
+   if (dssdev->phy.dsi.clk_lane != 0)
+   in_use[dssdev->phy.dsi.clk_lane - 1] = true;
+   if (dssdev->phy.dsi.data1_lane != 0)
+   in_use[dssdev->phy.dsi.data1_lane - 1] = true;
+   if (dssdev->phy.dsi.data2_lane != 0)
+   in_use[dssdev->phy.dsi.data2_lane - 1] = true;
+
+   t = 10;
+   while (true) {
+   u32 l;
+   int i;
+   int ok;
+
+   l = dsi_read_reg(DSI_DSIPHY_CFG5);
+
+   ok = 0;
+   for (i = 0; i < 3; ++i) {
+   if (!in_use[i] || (l & (1 << bits[i])))
+   ok++;
+   }
+
+   if (ok == 3)
+   break;
+
+   if (--t == 0) {
+   for (i = 0; i < 3; ++i) {
+   if (!in_use[i] || (l & (1 << bits[i])))
+   continue;
+
+   DSSERR("CIO TXCLKESC%d domain not coming " \
+   "out of reset\n", i);
+   }
+   return -EIO;
+   }
+   }
+
+   return 0;
+}
+
 static int dsi_cio_init(struct omap_dss_device *dssdev)
 {
int r;
@@ -2028,6 +2087,10 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_if_enable(false);
REG_FLD_MOD(DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
 
+   r = dsi_cio_wait_tx_clk_esc_reset(dssdev);
+   if (r)
+   goto err_tx_clk_esc_rst;
+
if (dsi.ulps_enabled) {
/* Keep Mark-1 state for 1ms (as per DSI spec) */
ktime_t wait = ns_to_ktime(1000 * 1000);
@@ -2050,6 +2113,8 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
 
return 0;
 
+err_tx_clk_esc_rst:
+   REG_FLD_MOD(DSI_CLK_CTRL, 0, 20, 20); /* LP_CLK_ENABLE */
 err_cio_pwr_dom:
dsi_cio_power(DSI_COMPLEXIO_POWER_OFF);
 err_cio_pwr:
-- 
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 13/19] OMAP: DSS2: DSI: ensure VDDS_DSI is disabled on exit

2011-04-19 Thread Tomi Valkeinen
The panel drivers can leave the VDDS_DSI regulator enabled, even when
the panel is disabled, to ensure that the DSI pins are powered.

This patch ensures that VDDS_DSI is disabled on DSI module unload.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index f1e14ca..9c5715a 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4090,6 +4090,11 @@ err1:
 static void dsi_exit(void)
 {
if (dsi.vdds_dsi_reg != NULL) {
+   if (dsi.vdds_dsi_enabled) {
+   regulator_disable(dsi.vdds_dsi_reg);
+   dsi.vdds_dsi_enabled = false;
+   }
+
regulator_put(dsi.vdds_dsi_reg);
dsi.vdds_dsi_reg = NULL;
}
-- 
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 11/19] OMAP: DSS2: DSI: add parameter to enter ulps on disable

2011-04-19 Thread Tomi Valkeinen
Add parameter to omapdss_dsi_display_disable() which the panel driver
can use to tell if the DSI lanes should be put to ULPS before disabling
the interface.

This can be used to skip ULPS entry in cases where the panel doesn't
care about ULPS state, for example when the panel will be reset, or when
the display interface will be enabled again right after the disable.

This will speed up the operation considerably in cases where entering
ULPS would fail with timeout, and the panel driver isn't even interested
in entering ULPS.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/plat-omap/include/plat/display.h |2 +-
 drivers/video/omap2/displays/panel-taal.c |4 ++--
 drivers/video/omap2/dss/dsi.c |8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 205c6de..a65479c 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -592,7 +592,7 @@ void omap_dsi_release_vc(struct omap_dss_device *dssdev, 
int channel);
 
 int omapdss_dsi_display_enable(struct omap_dss_device *dssdev);
 void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
-   bool disconnect_lanes);
+   bool disconnect_lanes, bool enter_ulps);
 
 int omapdss_dpi_display_enable(struct omap_dss_device *dssdev);
 void omapdss_dpi_display_disable(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 74ce9f8..d68119e 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -932,7 +932,7 @@ err:
 
taal_hw_reset(dssdev);
 
-   omapdss_dsi_display_disable(dssdev, true);
+   omapdss_dsi_display_disable(dssdev, true, false);
 err0:
return r;
 }
@@ -955,7 +955,7 @@ static void taal_power_off(struct omap_dss_device *dssdev)
taal_hw_reset(dssdev);
}
 
-   omapdss_dsi_display_disable(dssdev, true);
+   omapdss_dsi_display_disable(dssdev, true, false);
 
td->enabled = 0;
 }
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d85635..d15014e 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3763,9 +3763,9 @@ err0:
 }
 
 static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
-   bool disconnect_lanes)
+   bool disconnect_lanes, bool enter_ulps)
 {
-   if (!dsi.ulps_enabled)
+   if (enter_ulps && !dsi.ulps_enabled)
dsi_enter_ulps();
 
/* disable interface */
@@ -3848,7 +3848,7 @@ err0:
 EXPORT_SYMBOL(omapdss_dsi_display_enable);
 
 void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
-   bool disconnect_lanes)
+   bool disconnect_lanes, bool enter_ulps)
 {
DSSDBG("dsi_display_disable\n");
 
@@ -3858,7 +3858,7 @@ void omapdss_dsi_display_disable(struct omap_dss_device 
*dssdev,
 
dsi_display_uninit_dispc(dssdev);
 
-   dsi_display_uninit_dsi(dssdev, disconnect_lanes);
+   dsi_display_uninit_dsi(dssdev, disconnect_lanes, enter_ulps);
 
enable_clocks(0);
dsi_enable_pll_clock(0);
-- 
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 08/19] OMAP: DSS2: DSI: implement enable/disable SCP clk

2011-04-19 Thread Tomi Valkeinen
SCP clock is needed for CIO on OMAP3, and for CIO and PLL on OMAP4.
Current driver enables the CIO clock always when DSI display is
initialized. However, if a DPI display tries to use DSI PLL, the SCP
clock is never enabled.

This patch implements simple ref counting enable/disable functions for
SCP clock.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   33 -
 1 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a6b6ca6..9a0f9e4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -305,6 +305,8 @@ static struct
unsigned long  regm_dispc_max, regm_dsi_max;
unsigned long  fint_min, fint_max;
unsigned long lpdiv_max;
+
+   unsigned scp_clk_refcount;
 } dsi;
 
 #ifdef DEBUG
@@ -1073,6 +1075,18 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device 
*dssdev)
return 0;
 }
 
+static void dsi_enable_scp_clk(void)
+{
+   if (dsi.scp_clk_refcount++ == 0)
+   REG_FLD_MOD(DSI_CLK_CTRL, 1, 14, 14); /* CIO_CLK_ICG */
+}
+
+static void dsi_disable_scp_clk(void)
+{
+   WARN_ON(dsi.scp_clk_refcount == 0);
+   if (--dsi.scp_clk_refcount == 0)
+   REG_FLD_MOD(DSI_CLK_CTRL, 0, 14, 14); /* CIO_CLK_ICG */
+}
 
 enum dsi_pll_power_state {
DSI_PLL_POWER_OFF   = 0x0,
@@ -1458,6 +1472,10 @@ int dsi_pll_init(struct omap_dss_device *dssdev, bool 
enable_hsclk,
 
enable_clocks(1);
dsi_enable_pll_clock(1);
+   /*
+* Note: SCP CLK is not required on OMAP3, but it is required on OMAP4.
+*/
+   dsi_enable_scp_clk();
 
if (!dsi.vdds_dsi_enabled) {
r = regulator_enable(dsi.vdds_dsi_reg);
@@ -1503,6 +1521,7 @@ err1:
dsi.vdds_dsi_enabled = false;
}
 err0:
+   dsi_disable_scp_clk();
enable_clocks(0);
dsi_enable_pll_clock(0);
return r;
@@ -1510,9 +1529,6 @@ err0:
 
 void dsi_pll_uninit(bool disconnect_lanes)
 {
-   enable_clocks(0);
-   dsi_enable_pll_clock(0);
-
dsi.pll_locked = 0;
dsi_pll_power(DSI_PLL_POWER_OFF);
if (disconnect_lanes) {
@@ -1520,6 +1536,11 @@ void dsi_pll_uninit(bool disconnect_lanes)
regulator_disable(dsi.vdds_dsi_reg);
dsi.vdds_dsi_enabled = false;
}
+
+   dsi_disable_scp_clk();
+   enable_clocks(0);
+   dsi_enable_pll_clock(0);
+
DSSDBG("PLL uninit done\n");
 }
 
@@ -3611,8 +3632,7 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
int r;
 
/* The SCPClk is required for both PLL and CIO registers on OMAP4 */
-   /* CIO_CLK_ICG, enable L3 clk to CIO */
-   REG_FLD_MOD(DSI_CLK_CTRL, 1, 14, 14);
+   dsi_enable_scp_clk();
 
_dsi_print_reset_status();
 
@@ -3668,6 +3688,7 @@ err2:
 err1:
dsi_pll_uninit(true);
 err0:
+   dsi_disable_scp_clk();
return r;
 }
 
@@ -3688,6 +3709,7 @@ static void dsi_display_uninit_dsi(struct omap_dss_device 
*dssdev,
dss_select_dsi_clk_source(OMAP_DSS_CLK_SRC_FCK);
dsi_cio_uninit();
dsi_pll_uninit(disconnect_lanes);
+   dsi_disable_scp_clk();
 }
 
 static int dsi_core_init(void)
@@ -4013,6 +4035,7 @@ err_dsi:
 static int omap_dsi1hw_remove(struct platform_device *pdev)
 {
dsi_exit();
+   WARN_ON(dsi.scp_clk_refcount > 0);
return 0;
 }
 
-- 
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 09/19] OMAP: DSS2: DSI: fix CIO init and uninit

2011-04-19 Thread Tomi Valkeinen
Use dsi_enable_scp_clk and dsi_disable_scp_clk in CIO init and uninit,
and improve the CIO init by adding a few status checks and error
handling.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   54 ++---
 1 files changed, 29 insertions(+), 25 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9a0f9e4..9f450af 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1971,13 +1971,12 @@ static void dsi_cio_disable_lane_override(void)
 
 static int dsi_cio_init(struct omap_dss_device *dssdev)
 {
-   int r = 0;
+   int r;
u32 l;
 
DSSDBGF();
 
-   if (dsi.ulps_enabled)
-   DSSDBG("manual ulps exit\n");
+   dsi_enable_scp_clk();
 
/* A dummy read using the SCP interface to any DSIPHY register is
 * required after DSIPHY reset to complete the reset of the DSI complex
@@ -1985,17 +1984,13 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_read_reg(DSI_DSIPHY_CFG5);
 
if (wait_for_bit_change(DSI_DSIPHY_CFG5, 30, 1) != 1) {
-   DSSERR("ComplexIO PHY not coming out of reset.\n");
-   r = -ENODEV;
-   goto err;
+   DSSERR("CIO SCP Clock domain not coming out of reset.\n");
+   r = -EIO;
+   goto err_scp_clk_dom;
}
 
dsi_set_lane_config(dssdev);
 
-   dsi_if_enable(true);
-   dsi_if_enable(false);
-   REG_FLD_MOD(DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
-
/* set TX STOP MODE timer to maximum for this operation */
l = dsi_read_reg(DSI_TIMING1);
l = FLD_MOD(l, 1, 15, 15);  /* FORCE_TX_STOP_MODE_IO */
@@ -2005,6 +2000,8 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_write_reg(DSI_TIMING1, l);
 
if (dsi.ulps_enabled) {
+   DSSDBG("manual ulps exit\n");
+
/* ULPS is exited by Mark-1 state for 1ms, followed by
 * stop state. DSS HW cannot do this via the normal
 * ULPS exit sequence, as after reset the DSS HW thinks
@@ -2019,7 +2016,17 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
 
r = dsi_cio_power(DSI_COMPLEXIO_POWER_ON);
if (r)
-   goto err;
+   goto err_cio_pwr;
+
+   if (wait_for_bit_change(DSI_COMPLEXIO_CFG1, 29, 1) != 1) {
+   DSSERR("CIO PWR clock domain not coming out of reset.\n");
+   r = -ENODEV;
+   goto err_cio_pwr_dom;
+   }
+
+   dsi_if_enable(true);
+   dsi_if_enable(false);
+   REG_FLD_MOD(DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
 
if (dsi.ulps_enabled) {
/* Keep Mark-1 state for 1ms (as per DSI spec) */
@@ -2035,24 +2042,28 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
/* FORCE_TX_STOP_MODE_IO */
REG_FLD_MOD(DSI_TIMING1, 0, 15, 15);
 
-   if (wait_for_bit_change(DSI_COMPLEXIO_CFG1, 29, 1) != 1) {
-   DSSERR("ComplexIO not coming out of reset.\n");
-   r = -ENODEV;
-   goto err;
-   }
-
dsi_cio_timings();
 
dsi.ulps_enabled = false;
 
DSSDBG("CIO init done\n");
-err:
+
+   return 0;
+
+err_cio_pwr_dom:
+   dsi_cio_power(DSI_COMPLEXIO_POWER_OFF);
+err_cio_pwr:
+   if (dsi.ulps_enabled)
+   dsi_cio_disable_lane_override();
+err_scp_clk_dom:
+   dsi_disable_scp_clk();
return r;
 }
 
 static void dsi_cio_uninit(void)
 {
dsi_cio_power(DSI_COMPLEXIO_POWER_OFF);
+   dsi_disable_scp_clk();
 }
 
 static int _dsi_wait_reset(void)
@@ -3631,11 +3642,6 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
 {
int r;
 
-   /* The SCPClk is required for both PLL and CIO registers on OMAP4 */
-   dsi_enable_scp_clk();
-
-   _dsi_print_reset_status();
-
r = dsi_pll_init(dssdev, true, true);
if (r)
goto err0;
@@ -3688,7 +3694,6 @@ err2:
 err1:
dsi_pll_uninit(true);
 err0:
-   dsi_disable_scp_clk();
return r;
 }
 
@@ -3709,7 +3714,6 @@ static void dsi_display_uninit_dsi(struct omap_dss_device 
*dssdev,
dss_select_dsi_clk_source(OMAP_DSS_CLK_SRC_FCK);
dsi_cio_uninit();
dsi_pll_uninit(disconnect_lanes);
-   dsi_disable_scp_clk();
 }
 
 static int dsi_core_init(void)
-- 
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 07/19] OMAP: DSS2: DSI: fix _dsi_print_reset_status

2011-04-19 Thread Tomi Valkeinen
The bits for TXCLKESCx reset have changed for OMAP3630 and OMAP4.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   17 +++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 61d9f3c..a6b6ca6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -960,6 +960,7 @@ static inline void dsi_enable_pll_clock(bool enable)
 static void _dsi_print_reset_status(void)
 {
u32 l;
+   int b0, b1, b2;
 
if (!dss_debug)
return;
@@ -977,9 +978,21 @@ static void _dsi_print_reset_status(void)
l = dsi_read_reg(DSI_COMPLEXIO_CFG1);
printk("CIO (%d) ", FLD_GET(l, 29, 29));
 
+   if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
+   b0 = 28;
+   b1 = 27;
+   b2 = 26;
+   } else {
+   b0 = 24;
+   b1 = 25;
+   b2 = 26;
+   }
+
l = dsi_read_reg(DSI_DSIPHY_CFG5);
-   printk("PHY (%x, %d, %d, %d)\n",
-   FLD_GET(l, 28, 26),
+   printk("PHY (%x%x%x, %d, %d, %d)\n",
+   FLD_GET(l, b0, b0),
+   FLD_GET(l, b1, b1),
+   FLD_GET(l, b2, b2),
FLD_GET(l, 29, 29),
FLD_GET(l, 30, 30),
FLD_GET(l, 31, 31));
-- 
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 06/19] OMAP: DSS2: Add FEAT_DSI_REVERSE_TXCLKESC

2011-04-19 Thread Tomi Valkeinen
OMAP3430 has RESETDONETXCLKESCx bits in the order following bitnumber
order for lanes 0, 1, 2: 28, 27, 26. OMAP3630 and later have them in
saner order: 24, 25, 26 (and 27, 28 for OMAP4).

This patch adds a dss_feature that can be used to differentiate between
those two orders of RESETDONETXCLKESCx bits.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dss_features.c |2 +-
 drivers/video/omap2/dss/dss_features.h |1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 5f3a7c4..502a953 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -253,7 +253,7 @@ static struct omap_dss_features omap3430_dss_features = {
FEAT_LCDENABLESIGNAL | FEAT_PCKFREEENABLE |
FEAT_FUNCGATED | FEAT_ROWREPEATENABLE |
FEAT_LINEBUFFERSPLIT | FEAT_RESIZECONF |
-   FEAT_DSI_PLL_FREQSEL,
+   FEAT_DSI_PLL_FREQSEL | FEAT_DSI_REVERSE_TXCLKESC,
 
.num_mgrs = 2,
.num_ovls = 3,
diff --git a/drivers/video/omap2/dss/dss_features.h 
b/drivers/video/omap2/dss/dss_features.h
index 1093e8d..5668fec 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -45,6 +45,7 @@ enum dss_feat_id {
FEAT_DSI_PLL_FREQSEL= 1 << 14,
FEAT_DSI_DCS_CMD_CONFIG_VC  = 1 << 15,
FEAT_DSI_VC_OCP_WIDTH   = 1 << 16,
+   FEAT_DSI_REVERSE_TXCLKESC   = 1 << 17,
 };
 
 /* DSS register field id */
-- 
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 05/19] OMAP: DSS2: DSI: rename complexio related functions

2011-04-19 Thread Tomi Valkeinen
Rename ComplexIO from dsi_complexio_xxx to dsi_cio_xxx for brevity.
Also, add cio prefix for couple of functions that didn't have it, but
are cio related.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   38 +++---
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 54fc0f6..61d9f3c 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1738,13 +1738,13 @@ void dsi_dump_regs(struct seq_file *s)
 #undef DUMPREG
 }
 
-enum dsi_complexio_power_state {
+enum dsi_cio_power_state {
DSI_COMPLEXIO_POWER_OFF = 0x0,
DSI_COMPLEXIO_POWER_ON  = 0x1,
DSI_COMPLEXIO_POWER_ULPS= 0x2,
 };
 
-static int dsi_complexio_power(enum dsi_complexio_power_state state)
+static int dsi_cio_power(enum dsi_cio_power_state state)
 {
int t = 0;
 
@@ -1764,7 +1764,7 @@ static int dsi_complexio_power(enum 
dsi_complexio_power_state state)
return 0;
 }
 
-static void dsi_complexio_config(struct omap_dss_device *dssdev)
+static void dsi_set_lane_config(struct omap_dss_device *dssdev)
 {
u32 r;
 
@@ -1816,7 +1816,7 @@ static inline unsigned ddr2ns(unsigned ddr)
return ddr * 1000 * 1000 / (ddr_clk / 1000);
 }
 
-static void dsi_complexio_timings(void)
+static void dsi_cio_timings(void)
 {
u32 r;
u32 ths_prepare, ths_prepare_ths_zero, ths_trail, ths_exit;
@@ -1886,7 +1886,7 @@ static void dsi_complexio_timings(void)
dsi_write_reg(DSI_DSIPHY_CFG2, r);
 }
 
-static void dsi_enable_lane_override(struct omap_dss_device *dssdev,
+static void dsi_cio_enable_lane_override(struct omap_dss_device *dssdev,
enum dsi_lane lanes)
 {
int clk_lane   = dssdev->phy.dsi.clk_lane;
@@ -1927,7 +1927,7 @@ static void dsi_enable_lane_override(struct 
omap_dss_device *dssdev,
REG_FLD_MOD(DSI_DSIPHY_CFG10, 1, 27, 27); /* ENLPTXSCPDAT */
 }
 
-static void dsi_disable_lane_override(void)
+static void dsi_cio_disable_lane_override(void)
 {
/* Disable lane override */
REG_FLD_MOD(DSI_DSIPHY_CFG10, 0, 27, 27); /* ENLPTXSCPDAT */
@@ -1935,12 +1935,12 @@ static void dsi_disable_lane_override(void)
REG_FLD_MOD(DSI_DSIPHY_CFG10, 0, 22, 17); /* REGLPTXSCPDAT4TO0DXDY */
 }
 
-static int dsi_complexio_init(struct omap_dss_device *dssdev)
+static int dsi_cio_init(struct omap_dss_device *dssdev)
 {
int r = 0;
u32 l;
 
-   DSSDBG("dsi_complexio_init\n");
+   DSSDBGF();
 
if (dsi.ulps_enabled)
DSSDBG("manual ulps exit\n");
@@ -1956,7 +1956,7 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
goto err;
}
 
-   dsi_complexio_config(dssdev);
+   dsi_set_lane_config(dssdev);
 
dsi_if_enable(true);
dsi_if_enable(false);
@@ -1979,11 +1979,11 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
 * manually.
 */
 
-   dsi_enable_lane_override(dssdev,
+   dsi_cio_enable_lane_override(dssdev,
DSI_CLK_P | DSI_DATA1_P | DSI_DATA2_P);
}
 
-   r = dsi_complexio_power(DSI_COMPLEXIO_POWER_ON);
+   r = dsi_cio_power(DSI_COMPLEXIO_POWER_ON);
if (r)
goto err;
 
@@ -1995,7 +1995,7 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
 
/* Disable the override. The lanes should be set to Mark-11
 * state by the HW */
-   dsi_disable_lane_override();
+   dsi_cio_disable_lane_override();
}
 
/* FORCE_TX_STOP_MODE_IO */
@@ -2007,7 +2007,7 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
goto err;
}
 
-   dsi_complexio_timings();
+   dsi_cio_timings();
 
dsi.ulps_enabled = false;
 
@@ -2016,9 +2016,9 @@ err:
return r;
 }
 
-static void dsi_complexio_uninit(void)
+static void dsi_cio_uninit(void)
 {
-   dsi_complexio_power(DSI_COMPLEXIO_POWER_OFF);
+   dsi_cio_power(DSI_COMPLEXIO_POWER_OFF);
 }
 
 static int _dsi_wait_reset(void)
@@ -2892,7 +2892,7 @@ static int dsi_enter_ulps(void)
dsi_unregister_isr_cio(dsi_completion_handler, &completion,
DSI_CIO_IRQ_ULPSACTIVENOT_ALL0);
 
-   dsi_complexio_power(DSI_COMPLEXIO_POWER_ULPS);
+   dsi_cio_power(DSI_COMPLEXIO_POWER_ULPS);
 
dsi_if_enable(false);
 
@@ -3622,7 +3622,7 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
if (r)
goto err2;
 
-   r = dsi_complexio_init(dssdev);
+   r = dsi_cio_init(dssdev);
if (r)
goto err2;
 
@@ -3648,7 +3648,7 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
 
return 0;
 err3:
-   dsi_complexio_uninit();
+   dsi_cio_uninit();
 err2:
dss_select_dispc_clk_so

[PATCH 04/19] OMAP: DSS2: DSI: add option to leave DSI lanes powered on

2011-04-19 Thread Tomi Valkeinen
The DSI pins are powered by VDDS_DSI. If VDDS_DSI is off, the DSI pins
are floating even if they are pinmuxed to, say, safe mode and there's a
pull down/up.

This patch gives the panel drivers an option to leave the VDDS_DSI power
enabled while the DSS itself is turned off. This can be used to keep the
DSI lanes in a valid state while DSS is off, if the DSI pins are muxed
for pull down (not done in this patch).

There will be a slight power consumption increase (~100 uA?) when the
VDDS_DSI is left on, but because this option is used when the panel is
left on, the regulator consumption is negligible compared to panel power
consumption.

When the panel is fully turned off the VDDS_DSI is also turned off.

As an added bonus this will give us faster start up time when starting
up the DSS and the regulator is already enabled.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/plat-omap/include/plat/display.h |3 +-
 drivers/video/omap2/displays/panel-taal.c |4 +-
 drivers/video/omap2/dss/dpi.c |4 +-
 drivers/video/omap2/dss/dsi.c |   35 +++-
 drivers/video/omap2/dss/dss.h |2 +-
 5 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 43b887b..205c6de 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -591,7 +591,8 @@ int omap_dsi_set_vc_id(struct omap_dss_device *dssdev, int 
channel, int vc_id);
 void omap_dsi_release_vc(struct omap_dss_device *dssdev, int channel);
 
 int omapdss_dsi_display_enable(struct omap_dss_device *dssdev);
-void omapdss_dsi_display_disable(struct omap_dss_device *dssdev);
+void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
+   bool disconnect_lanes);
 
 int omapdss_dpi_display_enable(struct omap_dss_device *dssdev);
 void omapdss_dpi_display_disable(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 490998f..74ce9f8 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -932,7 +932,7 @@ err:
 
taal_hw_reset(dssdev);
 
-   omapdss_dsi_display_disable(dssdev);
+   omapdss_dsi_display_disable(dssdev, true);
 err0:
return r;
 }
@@ -955,7 +955,7 @@ static void taal_power_off(struct omap_dss_device *dssdev)
taal_hw_reset(dssdev);
}
 
-   omapdss_dsi_display_disable(dssdev);
+   omapdss_dsi_display_disable(dssdev, true);
 
td->enabled = 0;
 }
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 17d28d7..ba0b8da 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -206,7 +206,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device 
*dssdev)
 
 err4:
if (dpi_use_dsi_pll(dssdev))
-   dsi_pll_uninit();
+   dsi_pll_uninit(true);
 err3:
if (dpi_use_dsi_pll(dssdev))
dss_clk_disable(DSS_CLK_SYSCK);
@@ -227,7 +227,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device 
*dssdev)
 
if (dpi_use_dsi_pll(dssdev)) {
dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
-   dsi_pll_uninit();
+   dsi_pll_uninit(true);
dss_clk_disable(DSS_CLK_SYSCK);
}
 
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 5303548..54fc0f6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -246,6 +246,7 @@ static struct
 
struct dsi_clock_info current_cinfo;
 
+   bool vdds_dsi_enabled;
struct regulator *vdds_dsi_reg;
 
struct {
@@ -1445,9 +1446,12 @@ int dsi_pll_init(struct omap_dss_device *dssdev, bool 
enable_hsclk,
enable_clocks(1);
dsi_enable_pll_clock(1);
 
-   r = regulator_enable(dsi.vdds_dsi_reg);
-   if (r)
-   goto err0;
+   if (!dsi.vdds_dsi_enabled) {
+   r = regulator_enable(dsi.vdds_dsi_reg);
+   if (r)
+   goto err0;
+   dsi.vdds_dsi_enabled = true;
+   }
 
/* XXX PLL does not come out of reset without this... */
dispc_pck_free_enable(1);
@@ -1481,21 +1485,28 @@ int dsi_pll_init(struct omap_dss_device *dssdev, bool 
enable_hsclk,
 
return 0;
 err1:
-   regulator_disable(dsi.vdds_dsi_reg);
+   if (dsi.vdds_dsi_enabled) {
+   regulator_disable(dsi.vdds_dsi_reg);
+   dsi.vdds_dsi_enabled = false;
+   }
 err0:
enable_clocks(0);
dsi_enable_pll_clock(0);
return r;
 }
 
-void dsi_pll_uninit(void)
+void dsi_pll_uninit(bool disconnect_lanes)
 {
enable_clocks(0);
dsi_enable_pll_clock(0);
 
dsi.pll_locked = 0;
dsi_pll_power(DSI_PLL_POWER_OFF);
-   regulator_disable(dsi.vdds_dsi_reg);
+

[PATCH 03/19] OMAP: DSS2: DSI: implement ULPS enter and exit

2011-04-19 Thread Tomi Valkeinen
Entering ULPS (Ultra Low Power State) happens by sending ULPS entry
sequence to the DSI peripheral and pulling the DSI lines down.

Exiting ULPS happens by sending ULPS exit sequence.

We can send the ULPS entry sequence by using OMAP DSS HW's ULPS support,
but we cannot use the ULPS exit support from DSS HW. DSS HW refuses to
send the ULPS exit sequence if it thinks that the lanes are not in ULPS.
After being in OFF mode the DSS HW has been reset, and so it does not
know that the lanes are actually in ULPS.

Thus we need to use the lane override support and manually send the ULPS
exit sequence. Luckily the sequence is very simple.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |  141 +++-
 1 files changed, 123 insertions(+), 18 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 013621e..5303548 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -268,6 +269,7 @@ static struct
struct dsi_update_region update_region;
 
bool te_enabled;
+   bool ulps_enabled;
 
struct workqueue_struct *workqueue;
 
@@ -1925,9 +1927,13 @@ static void dsi_disable_lane_override(void)
 static int dsi_complexio_init(struct omap_dss_device *dssdev)
 {
int r = 0;
+   u32 l;
 
DSSDBG("dsi_complexio_init\n");
 
+   if (dsi.ulps_enabled)
+   DSSDBG("manual ulps exit\n");
+
/* A dummy read using the SCP interface to any DSIPHY register is
 * required after DSIPHY reset to complete the reset of the DSI complex
 * I/O. */
@@ -1941,11 +1947,49 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
 
dsi_complexio_config(dssdev);
 
-   r = dsi_complexio_power(DSI_COMPLEXIO_POWER_ON);
+   dsi_if_enable(true);
+   dsi_if_enable(false);
+   REG_FLD_MOD(DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
+
+   /* set TX STOP MODE timer to maximum for this operation */
+   l = dsi_read_reg(DSI_TIMING1);
+   l = FLD_MOD(l, 1, 15, 15);  /* FORCE_TX_STOP_MODE_IO */
+   l = FLD_MOD(l, 1, 14, 14);  /* STOP_STATE_X16_IO */
+   l = FLD_MOD(l, 1, 13, 13);  /* STOP_STATE_X4_IO */
+   l = FLD_MOD(l, 0x1fff, 12, 0);  /* STOP_STATE_COUNTER_IO */
+   dsi_write_reg(DSI_TIMING1, l);
+
+   if (dsi.ulps_enabled) {
+   /* ULPS is exited by Mark-1 state for 1ms, followed by
+* stop state. DSS HW cannot do this via the normal
+* ULPS exit sequence, as after reset the DSS HW thinks
+* that we are not in ULPS mode, and refuses to send the
+* sequence. So we need to send the ULPS exit sequence
+* manually.
+*/
+
+   dsi_enable_lane_override(dssdev,
+   DSI_CLK_P | DSI_DATA1_P | DSI_DATA2_P);
+   }
 
+   r = dsi_complexio_power(DSI_COMPLEXIO_POWER_ON);
if (r)
goto err;
 
+   if (dsi.ulps_enabled) {
+   /* Keep Mark-1 state for 1ms (as per DSI spec) */
+   ktime_t wait = ns_to_ktime(1000 * 1000);
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   schedule_hrtimeout(&wait, HRTIMER_MODE_REL);
+
+   /* Disable the override. The lanes should be set to Mark-11
+* state by the HW */
+   dsi_disable_lane_override();
+   }
+
+   /* FORCE_TX_STOP_MODE_IO */
+   REG_FLD_MOD(DSI_TIMING1, 0, 15, 15);
+
if (wait_for_bit_change(DSI_COMPLEXIO_CFG1, 29, 1) != 1) {
DSSERR("ComplexIO not coming out of reset.\n");
r = -ENODEV;
@@ -1954,23 +1998,7 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
 
dsi_complexio_timings();
 
-   /*
-  The configuration of the DSI complex I/O (number of data lanes,
-  position, differential order) should not be changed while
-  DSS.DSI_CLK_CRTRL[20] LP_CLK_ENABLE bit is set to 1. For the
-  hardware to recognize a new configuration of the complex I/O (done
-  in DSS.DSI_COMPLEXIO_CFG1 register), it is recommended to follow
-  this sequence: First set the DSS.DSI_CTRL[0] IF_EN bit to 1, next
-  reset the DSS.DSI_CTRL[0] IF_EN to 0, then set DSS.DSI_CLK_CTRL[20]
-  LP_CLK_ENABLE to 1, and finally, set again the DSS.DSI_CTRL[0] IF_EN
-  bit to 1. If the sequence is not followed, the DSi complex I/O
-  configuration is undetermined.
-  */
-   dsi_if_enable(1);
-   dsi_if_enable(0);
-   REG_FLD_MOD(DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
-   dsi_if_enable(1);
-   dsi_if_enable(0);
+   dsi.ulps_enabled = false;
 
DSSDBG("CIO init done\n");
 err:
@@ -2793,6 +2821,80 @@ int dsi_vc_set_max_rx_packet_size(int channel, u16 len)
 }

[PATCH 02/19] OMAP: DSS2: DSI: Remove CIO LDO status check

2011-04-19 Thread Tomi Valkeinen
CIO LDO status check seems to be broken on OMAP3630+ chips, and it's
also quite unclear what LDO status actually tells and when its status
changes.

This patch removes the whole check on the grounds that if there's a
problem with the LDO, we should anyway catch the problem as we check the
CIO power state and CIO reset status.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c  |8 
 drivers/video/omap2/dss/dss_features.c |4 ++--
 drivers/video/omap2/dss/dss_features.h |5 ++---
 3 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d245c5c..013621e 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1952,14 +1952,6 @@ static int dsi_complexio_init(struct omap_dss_device 
*dssdev)
goto err;
}
 
-   if (dss_has_feature(FEAT_DSI_LDO_STATUS)) {
-   if (wait_for_bit_change(DSI_COMPLEXIO_CFG1, 21, 1) != 1) {
-   DSSERR("ComplexIO LDO power down.\n");
-   r = -ENODEV;
-   goto err;
-   }
-   }
-
dsi_complexio_timings();
 
/*
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 6a1b130..5f3a7c4 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -253,7 +253,7 @@ static struct omap_dss_features omap3430_dss_features = {
FEAT_LCDENABLESIGNAL | FEAT_PCKFREEENABLE |
FEAT_FUNCGATED | FEAT_ROWREPEATENABLE |
FEAT_LINEBUFFERSPLIT | FEAT_RESIZECONF |
-   FEAT_DSI_PLL_FREQSEL | FEAT_DSI_LDO_STATUS,
+   FEAT_DSI_PLL_FREQSEL,
 
.num_mgrs = 2,
.num_ovls = 3,
@@ -273,7 +273,7 @@ static struct omap_dss_features omap3630_dss_features = {
FEAT_PRE_MULT_ALPHA | FEAT_FUNCGATED |
FEAT_ROWREPEATENABLE | FEAT_LINEBUFFERSPLIT |
FEAT_RESIZECONF | FEAT_DSI_PLL_PWR_BUG |
-   FEAT_DSI_PLL_FREQSEL |FEAT_DSI_LDO_STATUS,
+   FEAT_DSI_PLL_FREQSEL,
 
.num_mgrs = 2,
.num_ovls = 3,
diff --git a/drivers/video/omap2/dss/dss_features.h 
b/drivers/video/omap2/dss/dss_features.h
index d03f558..1093e8d 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -43,9 +43,8 @@ enum dss_feat_id {
/* DSI-PLL power command 0x3 is not working */
FEAT_DSI_PLL_PWR_BUG= 1 << 13,
FEAT_DSI_PLL_FREQSEL= 1 << 14,
-   FEAT_DSI_LDO_STATUS = 1 << 15,
-   FEAT_DSI_DCS_CMD_CONFIG_VC  = 1 << 16,
-   FEAT_DSI_VC_OCP_WIDTH   = 1 << 17,
+   FEAT_DSI_DCS_CMD_CONFIG_VC  = 1 << 15,
+   FEAT_DSI_VC_OCP_WIDTH   = 1 << 16,
 };
 
 /* DSS register field id */
-- 
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 01/19] OMAP: DSS2: DSI: Add lane override functions

2011-04-19 Thread Tomi Valkeinen
DSI_DSIPHY_CFG10 register can be used to override DSI lane state. Add
functions to configure and enable the override, and to disable the
override.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   58 +
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 2666b6b..d245c5c 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -90,6 +90,7 @@ struct dsi_reg { u16 idx; };
 #define DSI_DSIPHY_CFG1DSI_REG(0x200 + 0x0004)
 #define DSI_DSIPHY_CFG2DSI_REG(0x200 + 0x0008)
 #define DSI_DSIPHY_CFG5DSI_REG(0x200 + 0x0014)
+#define DSI_DSIPHY_CFG10   DSI_REG(0x200 + 0x0028)
 
 /* DSI_PLL_CTRL_SCP */
 
@@ -208,6 +209,15 @@ enum dsi_vc_mode {
DSI_VC_MODE_VP,
 };
 
+enum dsi_lane {
+   DSI_CLK_P   = 1 << 0,
+   DSI_CLK_N   = 1 << 1,
+   DSI_DATA1_P = 1 << 2,
+   DSI_DATA1_N = 1 << 3,
+   DSI_DATA2_P = 1 << 4,
+   DSI_DATA2_N = 1 << 5,
+};
+
 struct dsi_update_region {
u16 x, y, w, h;
struct omap_dss_device *device;
@@ -1863,6 +1873,54 @@ static void dsi_complexio_timings(void)
dsi_write_reg(DSI_DSIPHY_CFG2, r);
 }
 
+static void dsi_enable_lane_override(struct omap_dss_device *dssdev,
+   enum dsi_lane lanes)
+{
+   int clk_lane   = dssdev->phy.dsi.clk_lane;
+   int data1_lane = dssdev->phy.dsi.data1_lane;
+   int data2_lane = dssdev->phy.dsi.data2_lane;
+   int clk_pol= dssdev->phy.dsi.clk_pol;
+   int data1_pol  = dssdev->phy.dsi.data1_pol;
+   int data2_pol  = dssdev->phy.dsi.data2_pol;
+
+   u32 l = 0;
+
+   if (lanes & DSI_CLK_P)
+   l |= 1 << ((clk_lane - 1) * 2 + (clk_pol ? 0 : 1));
+   if (lanes & DSI_CLK_N)
+   l |= 1 << ((clk_lane - 1) * 2 + (clk_pol ? 1 : 0));
+
+   if (lanes & DSI_DATA1_P)
+   l |= 1 << ((data1_lane - 1) * 2 + (data1_pol ? 0 : 1));
+   if (lanes & DSI_DATA1_N)
+   l |= 1 << ((data1_lane - 1) * 2 + (data1_pol ? 1 : 0));
+
+   if (lanes & DSI_DATA2_P)
+   l |= 1 << ((data2_lane - 1) * 2 + (data2_pol ? 0 : 1));
+   if (lanes & DSI_DATA2_N)
+   l |= 1 << ((data2_lane - 1) * 2 + (data2_pol ? 1 : 0));
+
+   /*
+* Bits in REGLPTXSCPDAT4TO0DXDY:
+* 17: DY0 18: DX0
+* 19: DY1 20: DX1
+* 21: DY2 22: DX2
+*/
+
+   /* Set the lane override configuration */
+   REG_FLD_MOD(DSI_DSIPHY_CFG10, l, 22, 17); /* REGLPTXSCPDAT4TO0DXDY */
+
+   /* Enable lane override */
+   REG_FLD_MOD(DSI_DSIPHY_CFG10, 1, 27, 27); /* ENLPTXSCPDAT */
+}
+
+static void dsi_disable_lane_override(void)
+{
+   /* Disable lane override */
+   REG_FLD_MOD(DSI_DSIPHY_CFG10, 0, 27, 27); /* ENLPTXSCPDAT */
+   /* Reset the lane override configuration */
+   REG_FLD_MOD(DSI_DSIPHY_CFG10, 0, 22, 17); /* REGLPTXSCPDAT4TO0DXDY */
+}
 
 static int dsi_complexio_init(struct omap_dss_device *dssdev)
 {
-- 
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 00/19] OMAP: DSS2: ULPS support

2011-04-19 Thread Tomi Valkeinen
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.

 Tomi

Tomi Valkeinen (19):
  OMAP: DSS2: DSI: Add lane override functions
  OMAP: DSS2: DSI: Remove CIO LDO status check
  OMAP: DSS2: DSI: implement ULPS enter and exit
  OMAP: DSS2: DSI: add option to leave DSI lanes powered on
  OMAP: DSS2: DSI: rename complexio related functions
  OMAP: DSS2: Add FEAT_DSI_REVERSE_TXCLKESC
  OMAP: DSS2: DSI: fix _dsi_print_reset_status
  OMAP: DSS2: DSI: implement enable/disable SCP clk
  OMAP: DSS2: DSI: fix CIO init and uninit
  OMAP: DSS2: DSI: wait for TXCLKESC domain to come out of reset
  OMAP: DSS2: DSI: add parameter to enter ulps on disable
  OMAP: DSS2: DSI: Add DSI pad muxing support
  OMAP: DSS2: DSI: ensure VDDS_DSI is disabled on exit
  OMAP: DSS2: Taal: Implement configurable ESD interval
  OMAP: DSS2: Taal: Clean up ESD queueing
  OMAP: DSS2: Taal: Add sysfs file for ESD interval
  OMAP: DSS2: Taal: Separate panel reset
  OMAP: DSS2: Taal: Rename esd_wq to workqueue
  OMAP: DSS2: Taal: Implement ULPS functionality

 arch/arm/mach-omap2/board-4430sdp.c   |2 +-
 arch/arm/plat-omap/include/plat/display.h |4 +-
 arch/arm/plat-omap/include/plat/nokia-dsi-panel.h |6 +-
 drivers/video/omap2/displays/panel-taal.c |  420 +++--
 drivers/video/omap2/dss/dpi.c |4 +-
 drivers/video/omap2/dss/dsi.c |  427 +
 drivers/video/omap2/dss/dss.h |2 +-
 drivers/video/omap2/dss/dss_features.c|4 +-
 drivers/video/omap2/dss/dss_features.h|6 +-
 9 files changed, 764 insertions(+), 111 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


Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Kyungmin Park
On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
> On Monday 18 April 2011, Kyungmin Park wrote:
>> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
>> >
>> > One missing piece is still a way for a platform to provide both
>> > the iommu and the dma-mapping API in a unified driver. Right now,
>> > you have to export both interface for a generic solution.
>>
>> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
>> implementation into mm, but MM did't accept it.
>
> I'm confused. What do you mean with MM?
linux/mm, Memory Management.

Thank you,
Kyungmin Park
>
>> So now it's implemented at each SoCs. I think it's good chance to make
>> a generic IOMMU feature for ARM consolidation.
>>
>> Before this idea, can you review our implementation at above URL?
>
> I've commented on the main implementation for the IOMMU now.
>
>        Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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] cbus: tahvo: Select USB_OTG_UTILS

2011-04-19 Thread Jarkko Nikula
tahvo-usb.c is using otg_set_transceiver which is built only if
CONFIG_USB_OTG_UTILS is set.

Signed-off-by: Jarkko Nikula 
---
 drivers/cbus/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/cbus/Kconfig b/drivers/cbus/Kconfig
index 2667dff..d845a7e 100644
--- a/drivers/cbus/Kconfig
+++ b/drivers/cbus/Kconfig
@@ -23,6 +23,7 @@ config CBUS_TAHVO
 
 config CBUS_TAHVO_USB
depends on CBUS_TAHVO && USB
+   select USB_OTG_UTILS
tristate "Support for Tahvo USB transceiver"
---help---
  If you want Tahvo support for USB transceiver, say Y or M here.
-- 
1.7.4.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] cbus: tahvo: Remove dead code from tahvo-usb.c

2011-04-19 Thread Jarkko Nikula
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 
---
 drivers/cbus/tahvo-usb.c |   48 +-
 1 files changed, 1 insertions(+), 47 deletions(-)

diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
index f6b3c1a..be0333f 100644
--- a/drivers/cbus/tahvo-usb.c
+++ b/drivers/cbus/tahvo-usb.c
@@ -236,47 +236,6 @@ static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, 
NULL);
 
 int vbus_active = 0;
 
-#if 0
-
-static int host_suspend(struct tahvo_usb *tu)
-{
-   struct device   *dev;
-
-   if (!tu->otg.host)
-   return -ENODEV;
-
-   /* Currently ASSUMES only the OTG port matters;
-* other ports could be active...
-*/
-   dev = tu->otg.host->controller;
-   return dev->driver->suspend(dev, PMSG_SUSPEND);
-}
-
-static int host_resume(struct tahvo_usb *tu)
-{
-   struct device   *dev;
-
-   if (!tu->otg.host)
-   return -ENODEV;
-
-   dev = tu->otg.host->controller;
-   return dev->driver->resume(dev);
-}
-
-#else
-
-static int host_suspend(struct tahvo_usb *tu)
-{
-   return 0;
-}
-
-static int host_resume(struct tahvo_usb *tu)
-{
-   return 0;
-}
-
-#endif
-
 static void check_vbus_state(struct tahvo_usb *tu)
 {
int reg, prev_state;
@@ -303,7 +262,6 @@ static void check_vbus_state(struct tahvo_usb *tu)
case OTG_STATE_A_IDLE:
/* Session is now valid assuming the USB hub is driving 
Vbus */
tu->otg.state = OTG_STATE_A_HOST;
-   host_resume(tu);
break;
default:
break;
@@ -355,7 +313,6 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
 
 static void tahvo_usb_stop_host(struct tahvo_usb *tu)
 {
-   host_suspend(tu);
tu->otg.state = OTG_STATE_A_IDLE;
 }
 
@@ -403,8 +360,6 @@ static void tahvo_usb_power_off(struct tahvo_usb *tu)
if (tu->otg.gadget)
usb_gadget_vbus_disconnect(tu->otg.gadget);
 
-   host_suspend(tu);
-
/* Disable OTG and interrupts */
if (TAHVO_MODE(tu) == TAHVO_MODE_PERIPHERAL)
id = OTG_ID;
@@ -521,8 +476,7 @@ static int tahvo_usb_set_host(struct otg_transceiver *otg, 
struct usb_bus *host)
if (TAHVO_MODE(tu) == TAHVO_MODE_HOST) {
tu->otg.host = NULL;
tahvo_usb_become_host(tu);
-   } else
-   host_suspend(tu);
+   }
 
tu->otg.host = host;
 
-- 
1.7.4.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 12/14] PM / UNICORE32: Use struct syscore_ops instead of sysdevs for PM

2011-04-19 Thread Guan Xuetao


> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Monday, April 18, 2011 5:14 AM
> To: LKML
> Cc: Greg KH; Kay Sievers; Linux PM mailing list; Russell King; 
> linux-omap@vger.kernel.org; Kevin Hilman; linux-arm-
> ker...@lists.infradead.org; Ben Dooks; Mike Frysinger; Ralf Baechle; 
> Hans-Christian Egtvedt; Guan Xuetao; Benjamin Herrenschmidt;
> linuxppc-...@lists.ozlabs.org; Jiri Kosina; Konrad Rzeszutek Wilk; Jeremy 
> Fitzhardinge
> Subject: [PATCH 12/14] PM / UNICORE32: Use struct syscore_ops instead of 
> sysdevs for PM
> 
> From: Rafael J. Wysocki 
> 
> Make some UNICORE32 architecture's code use struct syscore_ops
> objects for power management instead of sysdev classes and sysdevs.
> 
> This simplifies the code and reduces the kernel's memory footprint.
> It also is necessary for removing sysdevs from the kernel entirely in
> the future.
> 
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Guan Xuetao 

--
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 1/3] cbus: tahvo: Fix build breakage caused by deprecated initializer removal

2011-04-19 Thread Jarkko Nikula
On Tue, 19 Apr 2011 00:07:24 -0700
Tony Lindgren  wrote:

> * Jarkko Nikula  [110418 12:18]:
> > Use DEFINE_SPINLOCK() for static spinlock initialization as the commit
> > d04fa5a "locking: Remove deprecated lock initializers" removes the
> > deprecated SPIN_LOCK_UNLOCKED. Since tahvo_lock is not used elsewhere than
> > tahvo.c it can be removed from tahvo.h too.
> 
> Thanks pushed all three. Looks like TAHVO_USB still fails
> to compile as the otg_set_transceiver may not be compiled.
> 
True, it fails if CONFIG_OTG_UTILS is not set and it was selected
by musb in my config. I'll send a Kconfig fix for that.


-- 
Jarkko
--
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 1/3] cbus: tahvo: Fix build breakage caused by deprecated initializer removal

2011-04-19 Thread Tony Lindgren
* Jarkko Nikula  [110418 12:18]:
> Use DEFINE_SPINLOCK() for static spinlock initialization as the commit
> d04fa5a "locking: Remove deprecated lock initializers" removes the
> deprecated SPIN_LOCK_UNLOCKED. Since tahvo_lock is not used elsewhere than
> tahvo.c it can be removed from tahvo.h too.

Thanks pushed all three. Looks like TAHVO_USB still fails
to compile as the otg_set_transceiver may not be compiled.

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