linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* DSS pm_runtime problem
@ 2011-05-05 15:59 Tomi Valkeinen
  2011-05-05 17:02 ` Tomi Valkeinen
  2011-05-05 17:03 ` Cousson, Benoit
  0 siblings, 2 replies; 4+ messages in thread
From: Tomi Valkeinen @ 2011-05-05 15:59 UTC (permalink / raw)
  To: Paul Walmsley, Cousson, Benoit; +Cc: lo-ml

Hi Paul, Benoit,

I've started testing pm runtime with DSS, and I encountered a problem.

I'm using latest -rc5 as a base, and it looks like
omap_hwmod:_wait_target_ready() does not succeed for dss_core hwmod.
This causes _enable() to fail, but omap_device_enable_hwmods() does not
check the return values so it looks like everything went well, until the
driver crashes as the DSS HW module was off.

Ideas about _wait_target_ready()? And omap_device_enable_hwmods() would
need some fixing, I wasted quite a while debugging this =).

 Tomi



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: DSS pm_runtime problem
  2011-05-05 15:59 DSS pm_runtime problem Tomi Valkeinen
@ 2011-05-05 17:02 ` Tomi Valkeinen
  2011-05-05 17:12   ` Cousson, Benoit
  2011-05-05 17:03 ` Cousson, Benoit
  1 sibling, 1 reply; 4+ messages in thread
From: Tomi Valkeinen @ 2011-05-05 17:02 UTC (permalink / raw)
  To: Paul Walmsley, Cousson, Benoit; +Cc: lo-ml

On Thu, 2011-05-05 at 18:59 +0300, Tomi Valkeinen wrote:
> Hi Paul, Benoit,
> 
> I've started testing pm runtime with DSS, and I encountered a problem.
> 
> I'm using latest -rc5 as a base, and it looks like
> omap_hwmod:_wait_target_ready() does not succeed for dss_core hwmod.
> This causes _enable() to fail, but omap_device_enable_hwmods() does not
> check the return values so it looks like everything went well, until the
> driver crashes as the DSS HW module was off.
> 
> Ideas about _wait_target_ready()? And omap_device_enable_hwmods() would
> need some fixing, I wasted quite a while debugging this =).

Ah, the HW needs dss_dss_clk to be enabled before calling
pm_runtime_get, otherwise _wait_target_ready() fails. Now that I think,
I guess Sumit mentioned this at some point.

Too bad, I was hoping I could enable the required opt clocks in
runtime_resume callback.

Shouldn't the hwmod code be able to enable/reset/etc the HW module
independently?

I wonder if this goes for all other DSS modules also...

 Tomi



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: DSS pm_runtime problem
  2011-05-05 15:59 DSS pm_runtime problem Tomi Valkeinen
  2011-05-05 17:02 ` Tomi Valkeinen
@ 2011-05-05 17:03 ` Cousson, Benoit
  1 sibling, 0 replies; 4+ messages in thread
From: Cousson, Benoit @ 2011-05-05 17:03 UTC (permalink / raw)
  To: Valkeinen, Tomi; +Cc: Paul Walmsley, lo-ml

Hi Tomi,

On 5/5/2011 5:59 PM, Valkeinen, Tomi wrote:
> Hi Paul, Benoit,
>
> I've started testing pm runtime with DSS, and I encountered a problem.
>
> I'm using latest -rc5 as a base, and it looks like
> omap_hwmod:_wait_target_ready() does not succeed for dss_core hwmod.
> This causes _enable() to fail, but omap_device_enable_hwmods() does not
> check the return values so it looks like everything went well, until the
> driver crashes as the DSS HW module was off.
>
> Ideas about _wait_target_ready()? And omap_device_enable_hwmods() would
> need some fixing, I wasted quite a while debugging this =).

The wait_target_ready is waiting for the PRCM status. It the status does 
not change, it is probably because some inputs clocks... like the 
optional ones are not enabled.

In your case, you have to enable the DSS fck before calling into PM 
runtime because hwmod does mark this clock as optional:-(


Regards,
Benoit

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: DSS pm_runtime problem
  2011-05-05 17:02 ` Tomi Valkeinen
@ 2011-05-05 17:12   ` Cousson, Benoit
  0 siblings, 0 replies; 4+ messages in thread
From: Cousson, Benoit @ 2011-05-05 17:12 UTC (permalink / raw)
  To: Valkeinen, Tomi; +Cc: Paul Walmsley, lo-ml

You were faster than me :-)

On 5/5/2011 7:02 PM, Valkeinen, Tomi wrote:
> On Thu, 2011-05-05 at 18:59 +0300, Tomi Valkeinen wrote:
>> Hi Paul, Benoit,
>>
>> I've started testing pm runtime with DSS, and I encountered a problem.
>>
>> I'm using latest -rc5 as a base, and it looks like
>> omap_hwmod:_wait_target_ready() does not succeed for dss_core hwmod.
>> This causes _enable() to fail, but omap_device_enable_hwmods() does not
>> check the return values so it looks like everything went well, until the
>> driver crashes as the DSS HW module was off.
>>
>> Ideas about _wait_target_ready()? And omap_device_enable_hwmods() would
>> need some fixing, I wasted quite a while debugging this =).
>
> Ah, the HW needs dss_dss_clk to be enabled before calling
> pm_runtime_get, otherwise _wait_target_ready() fails. Now that I think,
> I guess Sumit mentioned this at some point.
>
> Too bad, I was hoping I could enable the required opt clocks in
> runtime_resume callback.

I guess we should at some point control that clock from the fmwk. 
Unfortunately, we still do not have the good hwmod representation for 
the DSS for the moment.

I'm working on something for all these big subsystems like DSS, ISS, c2c 
to try to fix that. It will unfortunately not be there for 2.6.40 :-(

> Shouldn't the hwmod code be able to enable/reset/etc the HW module
> independently?

Yes, it should, but we have to change the fck / modulemode / opt_clk 
management for the DSS hwmod.

> I wonder if this goes for all other DSS modules also...

We do have some dependency between all DSS modules and the dss_core that 
are not handled today by the fmwk:-(

Regards,
Benoit

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-05-05 17:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-05 15:59 DSS pm_runtime problem Tomi Valkeinen
2011-05-05 17:02 ` Tomi Valkeinen
2011-05-05 17:12   ` Cousson, Benoit
2011-05-05 17:03 ` Cousson, Benoit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).