Bug 24980 - Usage of the overay cause s2ram failure unless it is running when the system is suspended
Summary: Usage of the overay cause s2ram failure unless it is running when the system ...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-07 11:38 UTC by maximlevitsky
Modified: 2017-07-24 23:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
kernel patch against drm-intel-next (2.50 KB, patch)
2009-11-29 03:10 UTC, Daniel Vetter
no flags Details | Splinter Review

Description maximlevitsky 2009-11-07 11:38:30 UTC
Using drm-intel-next and DRM_MODE_OVERLAY_LANDED in intel driver with all
master versions of everything.
This is G965 system.


If I never use overlay (it is enabled, but mplayer never runs), system suspends/resumes normally.

If I run it even once, and close the mplayer, system hangs on resume.

If I keep it running when suspending, system resumes normally even if was closed many times in between, I just need it to run when suspending.
Comment 1 maximlevitsky 2009-11-13 02:22:39 UTC
It could be that this is triggered by valid gart address in overlay registers that is set on first MI_OVERLAY_FLIP.

Then on resume, maybe gart isn't yet initialized, thus hardware fetches wrong data.
Just a speculation though, doesn't make much sense I admit.
However it would be nice to set OVADDR back to 0.
Comment 2 Daniel Vetter 2009-11-13 02:57:52 UTC
> --- Comment #1 from maximlevitsky@gmail.com  2009-11-13 02:22:39 PST ---
> It could be that this is triggered by valid gart address in overlay registers
> that is set on first MI_OVERLAY_FLIP.
> 
> Then on resume, maybe gart isn't yet initialized, thus hardware fetches wrong
> data.
> Just a speculation though, doesn't make much sense I admit.
> However it would be nice to set OVADDR back to 0.

When the overlay is not shown, the code switches of the complete overlay
hw unit with the MI_OVERLAY_FLIP command. So there shouldn't be any
hw-access going on before you switch on the overlay, again.

Just to check: With usermode-setting, suspend works after having used the
overlay? If not, there's a small difference in the kms overlay code vs.
the ums code that _might_ cause problems when the overlay is switched off.
Comment 3 Daniel Vetter 2009-11-27 10:51:47 UTC
If just noticed that I can reproduce this on my i855GM with the exact same
symptoms. There is a not all to clear-cut report of the same problem with
ums:

http://bugs.freedesktop.org/show_bug.cgi?id=24416

I'm now looking into this locally.

-Daniel
Comment 4 Daniel Vetter 2009-11-29 03:10:15 UTC
Created attachment 31546 [details] [review]
kernel patch against drm-intel-next

Can you please try out this patch. It should fix the resume problem, at least it is fixed now on my i855GM
Comment 5 maximlevitsky 2009-11-29 15:00:57 UTC
This patch fixes that issue.
Big thanks.

Sorry, really sorry for being lazy, and not testing things.
Comment 6 Daniel Vetter 2009-11-30 01:11:16 UTC
> --- Comment #5 from maximlevitsky@gmail.com  2009-11-29 15:00:57 PST ---
> This patch fixes that issue.
> Big thanks.

Great, I'll send off the patches to Eric asap. I'm closing this now, please
reopen in case it breaks again.

> Sorry, really sorry for being lazy, and not testing things.

Absolutely no problem for I was offline for the better part of two weeks,
too.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.