| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When switching to interruptible sleeps in the overlay code, I've
forgotten to recover from interruptions at one site. This
resulted in the overlay still running when it should have been
switched off. This in turn caused a hang on resume because it
tried to disable the (not-running) overlay in preparation for the
resume modeset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24980
Tested-by: maximlevitsky@gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
| |
|
|
|
|
|
|
| |
I've suspected some bug there wrt to suspend, but that was not
the case. Clean up the code anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
| |
|
|
|
|
|
|
|
|
| |
I've simply overlooked one case in the conversion to interruptible
sleeps. Rectify this.
Also delete a leftover debug printk.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
At least for the common case of userspace ioctls. When doing a
modeset operation, the wait is still uninterruptible. But considering
that failing to turn off the overlay when switching off the crtc it's
running on hangs the chip, it doesn't complicate matters _very_
much. There's just an unkillable X in addition to a black screen.
BUG() about it and explain in the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
| |
|
|
|
|
|
|
| |
As long as the gpu can keep up, neither the cpu (waiting for gpu)
nore the gpu (waiting for vblank to do an overlay flip) stalls.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
| |
|
|
|
|
|
|
|
| |
Now that the cache flushing of the memory based overlay regs works,
we can safely switch off the overlay. Beforehand it was only disabled
(like in userspace).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
This implements intel overlay support for kms via a device-specific
ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on
dri-devel). We've reached the conclusion that such an infrastructure
only makes sense when multiple kms overlay implementations exists,
which atm don't (and it doesn't look like this is gonna change).
Open issues:
- Runs in sync with the gpu, i.e. unnecessary waiting. I've decided
to wait on this because the hw tends to hang when changing something
in this area. I left some dummy functions as infrastructure.
- polyphase filtering uses a static table.
- uses uninterruptible sleeps. Unfortunately the alternatives may
unnecessarily wedged the hw if/when we timeout too early (and
userspace only overloaded the batch buffers with stuff worth a few
secs of gpu time).
Changes since v1:
- fix off-by-one misconception on my side. This fixes fullscreen
playback.
Changes since v2:
- add underrun detection as spec'ed for i965.
- flush caches properly, fixing visual corruptions.
Changes since v4:
- fix up cache flushing of overlay memory regs.
- killed require_pipe_a logic - it hangs the chip.
Tested-By: diego.abelenda@gmail.com (on a 865G)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt: Resolved against the MADVISE ioctl going in before this one]
Signed-off-by: Eric Anholt <eric@anholt.net>
|
