Generally we call stuff with i9xx_ when it's valid for gen3+. But
gen3 and early gen4 only support hdmi with sdvo cards, and writing
infoframes works completely different there.
v2: Use g4x instead of gm45 - it applies to the desktop variant, too.
v3: Properly align the paramters of g4x_write_infoframe again, noticed
by Paulo Zanoni.
Acked-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simplifies things because for all the infoframes we care about,
we always send them on each vblank. Also, this gets rid of one
of the hw specific functions mislabelled with the intel_ prefix -
hsw will completely change how this works!
Acked-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The principle of intel_mark_busy() is that we want to spot the
transition of when the display engine is being used in order to bump
powersaving modes and increase display clocks. As such it is only
important when the display is changing, i.e. when rendering to the
scanout or other sprite/plane, and these are characterised by being
pinned.
v2: Mark the whole device as busy on execbuffer and pageflips as well
and rebase against dinq for the minor bug fix to be immediately
applicable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: fix compile fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake
and newer, so now we use PIPEFRAME.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Ditch the check for disable pipe from the new ilk wait for
vblank function to keep it consisten with existing behaviour.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like Gen 4, IBX has a "Port Select" field on the DIP register,
but the ports are different.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
IBX does not need the workaround used in cpt_write_infoframe that
requires the AVI frame to be enabled while being updated.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The registers are on the PCH, so use the PCH name instead of the CPU
name. Also, the way this function is implemented is really only for
CPT and PPT. For now, both functions have the same implementations:
the next patch will fix ibx_write_infoframe.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Better safe than sorry. Currently we never change the frequency and
use the same for every infoframe type, so the only way to reproduce a
bug would be with the BIOS doing something.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That's what the VIDEO_DIP_CTL documentation says we need to do. Except
when it's the AVI InfoFrame and we're ironlake_write_infoframe.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will allow us to disable an infoframe without changing its
frequency.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Should prevent bugs when changing the port.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make sure we're doing the right thing, just like we do on gen5+.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't use intermediate variables, change the value of 'val' as we go
through the function. The new style looks more similar to the rest of
our code. IMHO, it's also easier to read and change.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gen3+ is 13 bits (12:0), and on gen2 only 12 (11:0). For both the high
bits are marked reserved, read-only so continue to mask them. Bit 31
is not reserved and has a meaning.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge of drm-next to resolve a few ugly conflicts and to get a few
fixes from 3.4-rc6 (which drm-next has already merged). Note that this
merge also restricts the stencil cache lra evict policy workaround to
snb (as it should) - I had to frob the code anyway because the
CM0_MASK_SHIFT define died in the masked bit cleanups.
We need the backmerge to get Paulo Zanoni's infoframe regression fix
for gm45 - further bugfixes from him touch the same area and would
needlessly conflict.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJPpvY9AAoJEHm+PkMAQRiGpEoIAJgbu+Y8gITnBK/wh9O6zy3S
5jie5KK4YWdbJsvO58WbNr3CyVIwGIqQ2dUZLiU59aBVLarlGw8xor0MmW+cZwhp
6fBHaf0qDYAV0MZjD+mnnExOiCRyISa2lPmsfu9dAWywh5KGe6/oAP6/qcXIyok3
KZyl3qQf4ENpaZPHwZPXCEkUvtuyHgNiszN+QXEadA3s19Ot4VGe9A3VGw+GNrSm
JqFIq3acQAbKa5BYaqf7TQC02v2FI7//eqt6QHxTqbE6a7LGbTvLfX3HlJ2mnfqa
1R6QHhM4y4OZDHbaMT2raHZ8WuLXzhehJzhP8Co7AHFOKwVKOb5XbcUr2RrukMU=
=HkMd
-----END PGP SIGNATURE-----
Merge tag 'v3.4-rc6' into drm-intel-next
Conflicts:
drivers/gpu/drm/i915/intel_display.c
Ok, this is a fun story of git totally messing things up. There
/shouldn't/ be any conflict in here, because the fixes in -rc6 do only
touch functions that have not been changed in -next.
The offending commits in drm-next are 14415745b2..1fa611065 which
simply move a few functions from intel_display.c to intel_pm.c. The
problem seems to be that git diff gets completely confused:
$ git diff 14415745b2..1fa611065
is a nice mess in intel_display.c, and the diff leaks into totally
unrelated functions, whereas
$git diff --minimal 14415745b2..1fa611065
is exactly what we want.
Unfortunately there seems to be no way to teach similar smarts to the
merge diff and conflict generation code, because with the minimal diff
there really shouldn't be any conflicts. For added hilarity, every
time something in that area changes the + and - lines in the diff move
around like crazy, again resulting in new conflicts. So I fear this
mess will stay with us for a little longer (and might result in
another backmerge down the road).
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
cc1: warning: include/drm: No such file or directory [enabled by default]
It's reproducible if you build with O=/some/obj/dir and W=1.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was mostly already fixed but this one change is needed to match Kirill's
original submission
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add the opregion support and bring us in line with the opregion functionality in the
reference driver code. We can't share this with i915 currently because there are
hardcoded assumptions about dev_priv etc in both versions.
[airlied: include opregion.h fix]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While trying to fix up gen4 gpu reset in
commit f49f058619
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Sat Sep 11 01:19:14 2010 -0700
drm/i915: Actually set the reset bit in i965_reset
a little confusion about when wait_for times out has been introduced -
wait for loops _until_ the condition is true.
This fixes gpu reset on my gm45, testing with my hangman code shows
that it's now fairly reliable - it only died after well over 100 reset
cycles.
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On gen4+ we don't reset the display unit, so resetting the complete
modeset state should not be necessary.
We can't do reset on gen3 anyway, which leaves us with gen2 reset:
According to Chris Wilson, that doesn't work so great, so he suggested
we just ignore that. If the need ever arrises, we can re-add it later
on.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... we actually use it.
Unfortunately we can't reset both at the same time without also
resetting the display unit, so do render and media separately.
Also replace magic constants with proper #defines.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only half of them even cared, and it's always the same one.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- reset the stop_rings infrastructure while resetting the hw to
avoid angering the hangcheck right away (and potentially declaring
the gpu permanently wedged).
- ignore reset failures when hanging due to the hangman - we don't
have reset code for all generations.
v2: Ensure that we only ignore reset failures when the hw reset is not
implemented and not when it failed.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Slightly cleans up the code and could be useful for e.g. Ben
Widawsky's hw context patches.
v2: New colours!
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- need_display is always true, scrap it.
- don't reacquire the mutex to do nothing after having restored the
gem state.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by writing (anything) to i915_error_state.
This way we can simulate a bunch of gpu hangs and run the error_state
capture code every time (without the need to reload the module).
To make that happen we need to abandon the simple seq_file wrappers
provided by the drm core. While at it put the new error_state
refcounting to some good use and associated the error_state to the
debugfs when opening the file. Otherwise the error_state could change
while someone is reading it. This should help greatly when we finally
get around to split up the giant single seq_file block that the
error_state file currently is into smaller parts.
v2: Actually squash all the fixes into the patch ...
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- reduce the irq disabled section, even for a debugfs file this was
way too long.
- always disable irqs when taking the lock.
v2: Thou shalt not mistake locking for reference counting, so:
- reference count the error_state to protect from concurent freeeing.
This will be only really used in the next patch.
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang detection
- error capture
- actual gpu reset
- reset of all the gem bookkeeping
- reinitialition of the entire gpu
This patch adds a debugfs to selectively stopping rings by ceasing to
update the hw tail pointer, which will result in the gpu no longer
updating it's head pointer and eventually to the hangcheck firing.
This way we can exercise the gpu hang code under controlled conditions
without a dying gpu taking down the entire systems.
Patch motivated by me forgetting to properly reinitialize ppgtt after
a gpu reset.
Usage:
echo $((1 << $ringnum)) > i915_ring_stop # stops one ring
echo 0xffffffff > i915_ring_stop # stops all, future-proof version
then run whatever testload is desired. i915_ring_stop automatically
resets after a gpu hang is detected to avoid hanging the gpu to fast
and declaring it wedged.
v2: Incorporate feedback from Chris Wilson.
v3: Add the missing cleanup.
v4: Fix up inconsistent size of ring_stop_read vs _write, noticed by
Eugeni Dodonov.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm_mode->dtd conversion used the crtc timings, whereas the
dtd->drm_mod did not set these. Use the standard mode information, not
the crtc timings, in both cases to make these two functions proper
inverses of each another.
Note that this also kills the risk that we handle interlaced timings
inconsistently because the drm core uses half-frames for crtc timings,
whereas we need full frames. But interlaced support is pretty decently
broken anyway for sdvo encoders, so no big deal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with
commit f9bef081c3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Apr 15 19:53:19 2012 +0200
drm/i915: don't clobber the special upscaling lvds timings
and
commit ca9bfa7eed
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jan 28 14:49:20 2012 +0100
drm/i915: fixup interlaced vertical timings confusion, part 1
we now only set the crtc timing fields in the encoder->mode_fixup
(lvds only) and in crtc->mode_fixup (for everyone else). And since
commit 75c13993db
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jan 28 23:48:46 2012 +0100
drm/i915: fixup overlay checks for interlaced modes
the only places we actually need the crtc timings is in the mode_set
function.
I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e. after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).
So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use family rather than DCE check for clarity, also always use
wb on APUs, there will never be AGP variants.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: enable dip before writing data on gen4
fixing dmi match for hp t5745 and hp st5747 thin client
drm/i915: Only enable IPS polling for gen5
drm/i915: Do not read non-existent DPLL registers on PCH hardware
Basically a straight cut/paste from the reference driver code then
cleaned up a spot.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we set a small text framebuffer and have a bigger scanout then we want
to send black not random bits for the overscan.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We are not yet ready for this and it makes a mess on some devices.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
