date:20120626

Re: [PATCHv10 1/7] I2C: OMAP: I2C register restore only if context is lost

2012-06-26 Thread Shubhrajyoti

On Monday 25 June 2012 06:00 PM, Felipe Balbi wrote:
 Cc: Kevin Hilman khil...@ti.com
  Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 how will this ever work with DT ? 
What you say makes sense however that is what currently
most of the omap drivers do.

Will check on this.
 I say we get rid of the OMAP-specific
 API and build this context lost status directly on dev_pm_info and
 have something like pm_runtime_lost_context() or something with pm QoS
 tell you if a device has lost its context.

 Also, your commit log doesn't really state any problems you might have
 reached before, or any improvements wrt latency coming out of suspend
 and so on.

 IMHO, drivers need a generic way to differentiate if they're resuming
 from OFF or RET, otherwise we will end up with a bunch of OMAP-specific
 hackery on all drivers


--
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 05/11] OMAPDSS: add clk_prepare and clk_unprepare

2012-06-26 Thread Tomi Valkeinen

On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:

  So as far as I see, clocks are never handled in atomic context. Is
  everything related to the base clk stuff already in mainline? Can I take
  the clk_prepare/unprepare patch into my omapdss tree?
 
 Well the Common Clk framework is already in mainline, but we still don;t
 have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so,
 clk_prepare/unprepare will just be stubs which do nothing.

But if I understood correctly, clk_prepare and clk_unprepare are anyway
no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?

My point was only to understand if I can safely take the patch into
omapdss tree, instead of it going through l-o, to avoid any possible
conflicts.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

2012-06-26 Thread Tomi Valkeinen

On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
 On 25 June 2012 19:19, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote:
 
   /* this accesses a register, but the HW is disabled? */
   dispc_read_reg(FOO);
  
   the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined.
 
  If CONFIG_PM_RUNTIME is indeed defined,  pm_runtime_enabled() will
  always return true after pm_runtime_enable()  unless someone disables
  it explicitly - omapdss or the RPM stack(during suspend/resume).
  OMAPDSS never does so in the lifetime of a driver.  So the only period
  in which pm_runtime_enabled() returns false, is when the platform is
  suspending, suspended or resuming.
 
  Right. So what happens in my example above?
 
  Normally if the driver does dispc_runtime_get() and dispc_read_reg(),
  the first call will enable the HW so the reg read works.
 
  But if the pm_runtime is disabled, say, during system suspend, with your
  patch dispc_runtime_get() will just return 0 without doing anything, and
  the dispc_read_reg() will crash because the HW is disabled (because
  nobody enabled it).
 
 Hmm, I am not sure if new calls would/should be made to dispc.c after
 the system has suspended and before resumed. That is, anything other
 than from runtime_resume/suspend callbacks of DSS, DISPC, HDMI, VENC
 and RFBI, which rightly don't touch any dss reg but only
 enable/disable a clock.

They do touch the registers. For example, dispc's callbacks save and
restore the registers. The HW should be fully functional during the
callbacks. The point of the callbacks is to suspend/resume the HW in
question, which of course requires accessing the HW.

 As we know, a subsystem should make sure any active work is cleared
 out before suspending and set some flag so that nothing runs until it
 has resumed. I don't say we can't crash the system with this patch,
 but then we would be violating rules of suspend-resume.

Let's go back a bit. I feel like I'm missing some pieces of information,
as I still don't quite grasp the problem.

In the patch you said this fixes an issue with HDMI. Can you tell more
about the problem? What code path is being run? Any error messages?

I tried system suspend with omap4-sdp and panda, with 3.5-rc2, but
neither board seems to wake up from the suspend. Does it work for you?

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: Panda ES board hang when using GPIO as interrupt

2012-06-26 Thread DebBarma, Tarun Kanti

On Tue, Jun 26, 2012 at 2:22 AM, Franky Lin fran...@broadcom.com wrote:
 Hi Kevin, Tarun,

 We are using the expansion connector A on Panda board to mount a SDIO WiFi
 dongle on MMC2 with a level triggered interrupt signal connected to GPIO
 138. It's been working fine until 3.5 rc1. The board hang randomly within 5
 mins during a network traffic test. After bisecting we found the culprit is
 [PATCH 8/8] gpio/omap: fix missing check in *_runtime_suspend() [1].

 I noticed Kevin raised some similar cases on other platforms and also
 provided two patches in the patch mail thread. But unfortunately those two
 patches doesn't help in our case. I tested the driver with 3.5-rc3 mainline
 kernel and the issue is still there. I can only fix the hang by either
 reverting the commit or disabling CONFIG_PM_RUNTIME. Also, the hang only
 happens on Panda ES board. Old Panda with 4430 works good.

 Any thoughts and suggestions?
I just had a quick look at the code. Can you please check if the
attached patch solves
the issue? I just boot tested on Panda and Blaze.
--
Tarun

From 0e1b322451b7a49487d2d17a147db1aa1d1119fa Mon Sep 17 00:00:00 2001
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Tue, 26 Jun 2012 12:13:47 +0530
Subject: [PATCH] gpio/omap: enabled_non_wakeup_gpios check skips
bank-saved_datain

Commit b3c64bc30af67ed328a8d919e41160942b870451
(gpio/omap: (re)fix wakeups on level-triggered GPIOs)
still skips update of bank-saved_datain in *_runtime_suspend()
which must be done irrespective of edge/level trigger types.
Therefore, move the enbaled_non_wakeup_gpios check after the
bank-saved_datain is updated.

Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
 drivers/gpio/gpio-omap.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..94ecdcf 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1177,9 +1177,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
__raw_writel(wake_hi | bank-context.risingdetect,
 bank-base + bank-regs-risingdetect);

-   if (!bank-enabled_non_wakeup_gpios)
-   goto update_gpio_context_count;
-
if (bank-power_mode != OFF_MODE) {
bank-power_mode = 0;
goto update_gpio_context_count;
@@ -1191,6 +1188,10 @@ static int omap_gpio_runtime_suspend(struct device *dev)
 */
bank-saved_datain = __raw_readl(bank-base +
bank-regs-datain);
+
+   if (!bank-enabled_non_wakeup_gpios)
+   goto update_gpio_context_count;
+
l1 = bank-context.fallingdetect;
l2 = bank-context.risingdetect;

-- 
1.7.0.4




 Thanks,
 Franky

 [1] http://article.gmane.org/gmane.linux.ports.arm.omap/75708/

From 0e1b322451b7a49487d2d17a147db1aa1d1119fa Mon Sep 17 00:00:00 2001
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Tue, 26 Jun 2012 12:13:47 +0530
Subject: [PATCH] gpio/omap: enabled_non_wakeup_gpios check skips bank-saved_datain

Commit b3c64bc30af67ed328a8d919e41160942b870451
(gpio/omap: (re)fix wakeups on level-triggered GPIOs)
still skips update of bank-saved_datain in *_runtime_suspend()
which must be done irrespective of edge/level trigger types.
Therefore, move the enbaled_non_wakeup_gpios check after the
bank-saved_datain is updated.

Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
 drivers/gpio/gpio-omap.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..94ecdcf 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1177,9 +1177,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
 		__raw_writel(wake_hi | bank-context.risingdetect,
 			 bank-base + bank-regs-risingdetect);
 
-	if (!bank-enabled_non_wakeup_gpios)
-		goto update_gpio_context_count;
-
 	if (bank-power_mode != OFF_MODE) {
 		bank-power_mode = 0;
 		goto update_gpio_context_count;
@@ -1191,6 +1188,10 @@ static int omap_gpio_runtime_suspend(struct device *dev)
 	 */
 	bank-saved_datain = __raw_readl(bank-base +
 		bank-regs-datain);
+
+	if (!bank-enabled_non_wakeup_gpios)
+		goto update_gpio_context_count;
+
 	l1 = bank-context.fallingdetect;
 	l2 = bank-context.risingdetect;
 
-- 
1.7.0.4

Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare

2012-06-26 Thread Rajendra Nayak


On Tuesday 26 June 2012 12:25 PM, Tomi Valkeinen wrote:

On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:


So as far as I see, clocks are never handled in atomic context. Is
everything related to the base clk stuff already in mainline? Can I take
the clk_prepare/unprepare patch into my omapdss tree?


Well the Common Clk framework is already in mainline, but we still don;t
have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so,
clk_prepare/unprepare will just be stubs which do nothing.


But if I understood correctly, clk_prepare and clk_unprepare are anyway
no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?


With CONFIG_COMMON_CLK enabled, they will do prepare use-counting with
a mutex lock/unlock around it.



My point was only to understand if I can safely take the patch into
omapdss tree, instead of it going through l-o, to avoid any possible
conflicts.


yes, I don't see any issues with it going through dss tree.



  Tomi



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver

2012-06-26 Thread Shilimkar, Santosh

On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
 On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:

 On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com  wrote:

 On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:


 +#if defined(CONFIG_OF)

      +static const struct of_device_id emif_of_match[] = {
      +             { .compatible = ti,emif-4d },
      +             { .compatible = ti,emif-4d5 },
      +             {},
      +};
      +MODULE_DEVICE_TABLE(of, emif_of_match);
      +#endif
      +
        static struct platform_driver emif_driver = {
             .remove         = __exit_p(emif_remove),
             .shutdown       = emif_shutdown,
             .driver = {
                     .name = emif,
      +#if defined(CONFIG_OF)
      +             .of_match_table = of_match_ptr(emif_of_match),
      +#endif



  Are these two still #if defined needed?

  Also, what about the IS_DEFINED macro?


 Yes. To avoid the build break in !DT build.


 No, infact of_match_ptr is there just so you can avoid a
 #ifdef around and not break !CONFIG_OF.


 Need to recheck but the build was throwing error becasue of
 emif_of_match
 mostly.


 You still need the first one. I meant the second one around
 'of_match_ptr' should be removed.

 With !CONFIG_OF, of_match_ptr(_ptr) is just defined as NULL.

Yep. That make sense too.
Will drop the second check.

regards
Santosh
--
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 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

2012-06-26 Thread Mohammed, Afzal

Hi Jon,

On Mon, Jun 25, 2012 at 21:42:14, Hunter, Jon wrote:
 On 06/22/2012 04:01 AM, Afzal Mohammed wrote:

  +static int hf, vhf, sync_read, sync_write, latency;
 
 I am wondering if we can remove hf, vhf, sync_read/write variables
 completely. We already have flags from sync_read/write and so we could
 just use the cfg-flags variable and remove sync_read/write variables.

For default frequency, sync_write can get turned off, so flag may or
may not be same as sync_write

 
 At the same time, we could create flags for ONENAND_FREQ_HF and
 ONENAND_FREQ_VHF or something like that. It could be nice to store the
 latency in onenand_data too. In other words, keep all the configuration
 in one place.

I have a feeling as though platform data fields should not be altered once
platform device is registered (as platform data being specific to the
board, thinking further, should they be const?, except for a case
where it is created by a common helper function for multiple boards with
varying capabilities of peripheral).

Other than sync_read, all others like hf, vhf, latency, sync_write are
updated during driver callback, so if we are going to put these in
platform private data fields, platform private data fields has to be
updated after platform device is registered.

Regards
Afzal
--
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] OMAPDSS: Check if RPM enabled before trying to change state

2012-06-26 Thread Jassi Brar

On 26 June 2012 12:49, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:

Normally if the driver does dispc_runtime_get() and dispc_read_reg(),
the first call will enable the HW so the reg read works.

But if the pm_runtime is disabled, say, during system suspend, with your
patch dispc_runtime_get() will just return 0 without doing anything, and
the dispc_read_reg() will crash because the HW is disabled (because
nobody enabled it).

Hmm, I am not sure if new calls would/should be made to dispc.c after
the system has suspended and before resumed. That is, anything other
than from runtime_resume/suspend callbacks of DSS, DISPC, HDMI, VENC
and RFBI, which rightly don't touch any dss reg but only
enable/disable a clock.

They do touch the registers. For example, dispc's callbacks save and
restore the registers. The HW should be fully functional during the
callbacks. The point of the callbacks is to suspend/resume the HW in
question, which of course requires accessing the HW.

DISPC being held by HDMI, VENC and RFBI would be the last to suspend
and first to resume. And it won't have its registers touched between
dispc_runtime_suspend() and dispc_runtime_resume(), which seems ok to
me (?)
HDMI, VENC and RFBI directly fooling around with DISPC regs would have
been a problem, which isn't the case.

As we know, a subsystem should make sure any active work is cleared
out before suspending and set some flag so that nothing runs until it
has resumed. I don't say we can't crash the system with this patch,
but then we would be violating rules of suspend-resume.

Let's go back a bit. I feel like I'm missing some pieces of information,
as I still don't quite grasp the problem.

In the patch you said this fixes an issue with HDMI. Can you tell more
about the problem? What code path is being run? Any error messages?

I tried system suspend with omap4-sdp and panda, with 3.5-rc2, but
neither board seems to wake up from the suspend. Does it work for you?

Something non-omapdss in vanilla breaks suspend/resume.
Without this patch I see the upstream's display broken after the
suspend attempt.
$ echo mem /sys/power/state

I work on TILT tree, which has suspend/resume working after some more
local patches.

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-3.4

I don't have SDP so not sure, but it should simply be testable with
Panda4460 and the omap4plus_defconfig there. Please feel free to ask
if you have any issue checking that out.

Thanks.
--
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 1/3] ARM: OMAP2+: nand: unify init functions

2012-06-26 Thread Mohammed, Afzal

Hi Jon,

On Mon, Jun 25, 2012 at 20:59:57, Hunter, Jon wrote:
 On 06/22/2012 04:00 AM, Afzal Mohammed wrote:
  Helper function for updating nand platform data has been
  added the capability to take timing structure arguement.
  Usage of omap_nand_flash_init() has been replaced by modifed
  one, omap_nand_flash_init was doing things similar to
  board_nand_init except that NAND CS# were being acquired
  based on bootloader setting. As CS# is hardwired for a given
  board, acquiring gpmc CS# has been removed, and updated with
  the value on board.
  
  NAND CS# used in beagle board was found to be CS0.
  Thomas Weber thomas.weber.li...@googlemail.com reported
  that value of devkit8000 to be CS0. Overo board was found
  to be using CS0 based on u-boot, while google grep says
  omap3touchbook too has CS0.

 Reviewed-by: Jon Hunter jon-hun...@ti.com

Thanks,
Afzal
--
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 v6 00/13] GPMC driver conversion

2012-06-26 Thread Mohammed, Afzal

Hi Tony,

On Fri, Jun 22, 2012 at 18:25:38, Mohammed, Afzal wrote:

 This series is based on 3.5-rc1, and is dependent on [1,2,3], and has
 been tested on omap3evm (smsc911x) rev G  C and beagle board(nand).
 Also using private patches, nand  onenand was tested on omap3evm,
 rev G  C respectively (as support for these were not in mainline)
 
 All boards will work using the old existing interface. Further patch
 series would convert all boards to use new interface.
 
 Many of GPMC peripherals depend on bootloader for configuration.
 This is going to be deprecated. feature-removal-schedule.txt will be
 updated in one of the upcoming patch series.
 
 Thanks to Tony  Jon for their various suggestions.
 
 [PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be
 reverted once all GPMC peripherals are migrated to use driver
 interface.

Please let me know your comments on this series.

Regards
Afzal
--
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] OMAPDSS: Check if RPM enabled before trying to change state

2012-06-26 Thread Tomi Valkeinen

On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:

 Something non-omapdss in vanilla breaks suspend/resume.

I was able to reproduce (probably) the same issue with omap3 overo. Does
this looks familiar:

[ 2267.140197] [ cut here ]
[ 2267.145172] WARNING: at drivers/video/omap2/dss/dispc.c:377 
dispc_runtime_get+0x60/0x7c [omapdss]
()
[ 2267.154846] Modules linked in: omapfb panel_generic_dpi omapdss cfbimgblt 
cfbfillrect cfbcopyarea
 [last unloaded: omapdss]
[ 2267.166595] [c001b61c] (unwind_backtrace+0x0/0xf0) from [c0040238] 
(warn_slowpath_common+0x4c
/0x64)
[ 2267.176605] [c0040238] (warn_slowpath_common+0x4c/0x64) from [c004026c] 
(warn_slowpath_null+0
x1c/0x24)
[ 2267.186859] [c004026c] (warn_slowpath_null+0x1c/0x24) from [bf0d7918] 
(dispc_runtime_get+0x60
/0x7c [omapdss])
[ 2267.197814] [bf0d7918] (dispc_runtime_get+0x60/0x7c [omapdss]) from 
[bf0e3148] (omapdss_dpi_d
isplay_enable+0x48/0x230 [omapdss])
[ 2267.210479] [bf0e3148] (omapdss_dpi_display_enable+0x48/0x230 [omapdss]) 
from [bf110034] (gen
eric_dpi_panel_check_timings+0x30/0x7c [panel_generic_dpi])
[ 2267.225311] [bf110034] (generic_dpi_panel_check_timings+0x30/0x7c 
[panel_generic_dpi]) from [b
f11008c] (generic_dpi_panel_resume+0xc/0x1c [panel_generic_dpi])
[ 2267.240722] [bf11008c] (generic_dpi_panel_resume+0xc/0x1c 
[panel_generic_dpi]) from [bf0de654
] (dss_resume_device+0x28/0x40 [omapdss])
[ 2267.253936] [bf0de654] (dss_resume_device+0x28/0x40 [omapdss]) from 
[c02bfb94] (bus_for_each_
dev+0x50/0x7c)
[ 2267.264678] [c02bfb94] (bus_for_each_dev+0x50/0x7c) from [c02c287c] 
(platform_pm_resume+0x2c/
0x50)
[ 2267.274566] [c02c287c] (platform_pm_resume+0x2c/0x50) from [c02c6da8] 
(dpm_run_callback.clone
.7+0x30/0xb0)
[ 2267.285186] [c02c6da8] (dpm_run_callback.clone.7+0x30/0xb0) from 
[c02c7b2c] (device_resume+0x
c8/0x188)
[ 2267.295471] [c02c7b2c] (device_resume+0xc8/0x188) from [c02c7f54] 
(dpm_resume+0xfc/0x21c)
[ 2267.304534] [c02c7f54] (dpm_resume+0xfc/0x21c) from [c02c8208] 
(dpm_resume_end+0xc/0x18)
[ 2267.313507] [c02c8208] (dpm_resume_end+0xc/0x18) from [c007fbcc] 
(suspend_devices_and_enter+0
x15c/0x2d0)
[ 2267.323913] [c007fbcc] (suspend_devices_and_enter+0x15c/0x2d0) from 
[c007fecc] (pm_suspend+0x
18c/0x208)
[ 2267.334259] [c007fecc] (pm_suspend+0x18c/0x208) from [c007f170] 
(state_store+0x120/0x134)
[ 2267.343292] [c007f170] (state_store+0x120/0x134) from [c0262850] 
(kobj_attr_store+0x14/0x20)
[ 2267.352661] [c0262850] (kobj_attr_store+0x14/0x20) from [c0169b6c] 
(sysfs_write_file+0x100/0x
184)
[ 2267.362457] [c0169b6c] (sysfs_write_file+0x100/0x184) from [c0109008] 
(vfs_write+0xb4/0x148)
[ 2267.371795] [c0109008] (vfs_write+0xb4/0x148) from [c0109290] 
(sys_write+0x40/0x70)
[ 2267.380310] [c0109290] (sys_write+0x40/0x70) from [c0013d60] 
(ret_fast_syscall+0x0/0x3c)
[ 2267.389282] ---[ end trace 54fe7eea726ac84d ]---
[ 2267.394592] dpm_run_callback(): platform_pm_resume+0x0/0x50 returns -13
[ 2267.401641] PM: Device omapdss failed to resume: error -13

I don't remember seeing that with earlier kernel versions, but I'm not
100% sure.

Looking at the log, I can see that both DSS and DISPC runtime_resume
callbacks are called early, and successfully. Later the system resume
callback tries to enable the displays that were enabled when the system
went to suspend, which fails because dispc_runtime_get() returns -EACCES
(and pm_runtime_enabled() returns false).

Interestingly, during suspend dispc_runtime_put() is called, and at that
point pm_runtime_enabled() also returns false, but pm_runtime_put_sync()
still returns 0 instead of -EACCES.

I'll need to study this more, but I don't think this is a problem
related to omapdss's handling of runtime PM, but rather handling system
suspend. omapdss's handling of system suspend is in a rather bad state.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state

2012-06-26 Thread Andy Green

On 06/26/12 16:32, the mail apparently from Jassi Brar included:

On 26 June 2012 12:49, Tomi Valkeinen tomi.valkei...@ti.com wrote:

On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote: