Now that we have this all nicely abstract into separate functions with
self-documenting names this is pointless. And as Yuly Novikov spotted
in the case of ilk-ivb also wrong since we use the pfit both for lvds
and eDP
Reported-By: Yuly Novikov <ynovikov@chromium.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ring names already have "ring" in it.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just move the lowfreq_avail logic out of the register writing as a
prep step for the next patch, which will coalesce all the pch pll
enabling into one spot.
Note that writing the reduced clock dividers to FP1 in a few more
cases (as this patch ends up doing) isn't really relevant since the
FP1 value only matters when we enable the low lock. Which despite
can only happen if we've actually enabled the reduced dotclock and
furthermore isn't even properly implemented on ilk+: Despite claims to
the contrary in the code switching between frequencies if fully
manual.
v2: Explain matters around the FP1 change to answer a question Damien
raised in his review.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Nowadays (i.e. with Valleyview) we also have edp on non-PCH_SPLIT
platforms, so just checking for LVDS is not good enough.
Secondly we have full pfit pipe config tracking, so we'll correctly
disable the pfit as part of the initial modeset.
For fastboot we need a bit of work here to correctly kill unsupported
configs (if e.g. the pfit is used on anything else than the built-in
panel). But since that's not yet supported we don't need to worry.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Again we don't really support different settings, so don't let the
BIOS sneak stuff through.
Since the motivation for this patch series is to ensure we have the
correct gamma table mode selected also add the required write to the
GAMMA_MODE register to select the 8bit legacy table.
And since I find lowercase letters in #defines offensive, also
bikeshed those.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same reasons as for the previous patch, just no bug report about
anything going wrong yet: We only support exactly the mode we program,
so don't leave any stale BIOS state behind.
Again this will be fun to properly track for fastboot.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dragging random garbage along from the BIOS isn't a good idea, since
we really only support exactly what we've set up.
In the specific case for the bug reporter the BIOS used the 10bit
gamma table, but since we only support an 8bit table the dark colors
ended up all wrong and the light ones all unadjusted.
Note that this has a nice implication for fastboot, it essentially
means that we have quite a bit more state to check and compare before
we can decide whether fastboot is possible.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65593
Reported-and-Tested-by: Thomas Hebb <tommyhebb@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After hang check timer has declared gpu to be hung,
rings are reset. In ring reset, when clearing
request list, do post mortem analysis to find out
the guilty batch buffer.
Select requests for further analysis by inspecting
the completed sequence number which has been updated
into the HWS page. If request was completed, it can't
be related to the hang.
For noncompleted requests mark the batch as guilty
if the ring was not waiting and the ring head was
stuck inside the buffer object or in the flush region
right after the batch. For everything else, mark
them as innocents.
v2: Fixed a typo in commit message (Ville Syrjälä)
v3: - more descriptive function parameters (Chris Wilson)
- use masked head address when inspecting if request is in ring
- s/hangcheck.last_action/hangcheck.action
- added comment about unmasked head hitting batch_obj range
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For guilty batchbuffer analysis later on when rings are reset,
store what state the ring was on when hang was declared.
This helps to weed out the waiting rings from the active ones.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order to track down a batch buffer and context which
caused the ring to hang, store reference to bo into the request struct.
Request can also cause gpu to hang after the batch in the flush section
in the ring. To detect this add start of the flush portion offset into the
request.
v2: Included comment about request vs batch_obj lifetimes (Chris Wilson)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only execbuffer needed all the parameters on i915_add_request().
By putting __i915_add_request behind macro, all current callsites
become cleaner. Following patch will introduce a new parameter
for __i915_add_request. With this patch, only the relevant callsite
will reflect the change making commit smaller and easier to understand.
v2: _i915_add_request as function name (Chris Wilson)
v3: change name __i915_add_request and fix ordering of params (Ben Widawsky)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get context hang statistics for specified context,
add i915_gem_context_get_hang_stats().
For arb-robustness, every context needs to have its own
hang statistics tracking. Added function will return
the user specified context statistics or in case of
default context, statistics from drm_i915_file_private.
v2: handle default context inside get_reset_state
v3: return struct pointer instead of passing it in as param
(Chris Wilson)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To count context losses, add struct i915_ctx_hang_stats for
both i915_hw_context and drm_i915_file_private.
drm_i915_file_private is used when there is no context.
v2: renamed and cleaned up the struct (Chris Wilson, Ian Romanick)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The specs are a bit unclear whether the per-plane trickle feed disable
control exists on VLV. There is another trickle feed disable control
in the MI_ARB register.
After some experimentation it turns out both the DSPCNTR trickle feed
bits and the MI_ARB bit can be toggled. However the DSPCNTR bits don't
seem to have any effect.
The MI_ARB bit, on the other hand, has a noticable effect. I performed
an experiment where I reduced the FIFO size via DSPARB and observed the
effect of the MI_ARB trickle feed bit on the display.
Using a 1920x1080-60 mode, with MI_ARB=0x4 the display started to have
problems with DSPARB=0x42424242, whereas with MI_ARB=0x0 the problems
didn't start until DSPARB=0x09090909. This seems to confirm that the
MI_ARB trickle feed bit actually does work.
So replace the use of the DSPCNTR trickle feed bits with MI_ARB
on VLV.
v2: Amend commit message with results from experimentation
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a nice comment saying that the pixel multiplier only sticks
once the vco is on and stable. The only problem is that the enable bit
wasn't set at all. This patch fixes this and so brings the ilk+ pch
pll code in line with the i8xx/i9xx pll code. Or at least improves
matters a lot.
This should fix sdvo on ilk-ivb for low-res modes.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just the plumbing, all the modeset and enable code has not yet been
switched over to use the new state. It seems to be decently broken
anyway, at least wrt to handling of the special pixel mutliplier
enabling sequence. Follow-up patches will clean up that mess.
Another missing piece is more careful handling (and fixup) of the fp1
alternate divisor state. The BIOS most likely doesn't bother to
program that one to what we expect. So we need to be more careful with
comparing that state, both for cross checking but also when checking
for dpll sharing when acquiring shared dpll. Otherwise fastboot will
deny a few shared dpll configurations which would otherwise work.
v2: We need to memcpy the pipe config dpll hw state into the pll, for
otherwise the cross-check code will get angry.
v3: Don't forget to read the pch pll state in the crtc get_pipe_config
function for ibx/ilk platforms.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have proper hw state reconstruction we should never have a
case where we don't have the software dpll state properly set up. So
add WARNs to the respective !pll cases in enable/disabel_shared_dpll.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply grew too large and needed to be split up into parts.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply grew too big. This also makes the fixup and restore logic in
setup_hw_state stand out a bit more clearly.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently still with an empty register state, this will follow in a
next step. This one here just creates the new vfunc and uses it for
cross-checking, initial state takeover and the dpll assert function.
And add a FIXME for the ddi pll readout code, which still needs to be
converted over.
v2:
- Add some hw state readout debug output.
- Also cross check the enabled crtc counting.
Note that I've botched up the patch ordering, and before this patch
we've read out the pll selection correctly, but did not reconstruct
the refcounts properly. See the bug link.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65673
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't try to store it in the DPLL_FP register.
Otherwise it looks like the limits for pineview are correct: It has
it's own clock computation code, which doesn't use an offset for n
divisors, and the register value based m limits look sane enough.
v2: Rebase on top of the pineview clock refactor and fixup up the
commit message: It's m1 pnv doens't care about, not m2!
Quoting Damien's review:
- "n can vary between 2 and 6, but we declare the 3-6 as limits.
- "p1 seems to be able to go up to 9
- "the m upper limit seems a bit big, but the docs are a bit shy on
that values for pnv.
"Otherwise, the change itself seems good:"
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't (yet) have proper pixel multiplier readout support on pch
split platforms, so the cross check will naturally fail.
v2: Fix spelling in the comment, spotted by Ville.
v3: Since the ordering constraint is pretty tricky between the crtc
get_pipe_config callback and the encoder->get_config callback add a
few comments about it. Prompted by a discussion with Chris Wilson on
irc about why this does work anywhere else than on i915g/gm.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Stéphane Marchesin found a bug where the fences were not being restored,
and in particular the fence pin_count was incorrect. Had we had a
warning in place, this bug would have come to light much earlier. Better
late than never?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is of no value to the developer reading the report, let alone the
bamboozled user.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we detect a ring is in a valid wait for another, just let it be.
Eventually it will either begin to progress again, or the entire system
will come grinding to a halt and then hangcheck will fire as soon as the
deadlock is detected.
This error was foretold by Ben in
commit 05407ff889
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu May 30 09:04:29 2013 +0300
drm/i915: detect hang using per ring hangcheck_score
"If ring B is waiting on ring A via semaphore, and ring A is making
progress, albeit slowly - the hangcheck will fire. The check will
determine that A is moving, however ring B will appear hung because
the ACTHD doesn't move. I honestly can't say if that's actually a
realistic problem to hit it probably implies the timeout value is too
low."
v2: Make sure we don't even incur the KICK cost whilst waiting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After kicking a ring, it should be free to make progress again and so
should not be accused of being stuck until hangcheck fires once more. In
order to catch a denial-of-service within a batch or across multiple
batches, we still do increment the hangcheck score - just not as
severely so that it takes multiple kicks to fail.
This should address part of Ben's justified criticism of
commit 05407ff889
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu May 30 09:04:29 2013 +0300
drm/i915: detect hang using per ring hangcheck_score
"There's also another corner case on the kick. If the seqno = 2
(though not stuck), and on the 3rd hangcheck, the ring is stuck, and
we try to kick it... we don't actually try to find out if the kick
helped."
v2: Make sure we catch DoS attempts with batches full of invalid WAITs.
v3: Preserve the ability to detect loops by always charging the ring
if it is busy on the same request.
v4: Make sure we queue another check if on a new batch
References: https://bugs.freedesktop.org/show_bug.cgi?id=65394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we reset and restart a ring, we also want to clear any existing
hangcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In case of intel_sdvo_get_active_outputs() failing, we end up reading a
value from the stack.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hw state readout code for the pipe config will now check
this for us, so rip out this hand-rolled complexity.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks at first like a bit of overkill, but
- Haswell actually wants different enable/disable functions for
different plls.
- And once we have full dpll hw state tracking we can move the full
register setup into the ->enable hook.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using ids in register macros is much more common in our driver. Also
this way we can reduce the platform specific stuff a bit.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
An id to match the idx (useful for register access macros) and a name
fore neater debug output.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the future this won't be just for pch plls, so move it into the
shared dpll init code.
v2: Bikeshed the uncessary {} away while applying to appease
checkpatch.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Well, the first step of a long road at least, it only reads out
the pipe -> shared dpll association thus far. Other state which needs
to follow:
- hw state of the dpll (on/off + dpll registers). Currently we just
read that out from the hw state, but that doesn't work too well when
the dpll is in use, but not yet fully enabled. We get away since
most likely it already has been enabled and so the correct state is
left behind in the registers. But that doesn't hold for atomic
modesets when we want to enable all pipes at once.
- Refcount reconstruction for each dpll.
- Cross-checking of all the above. For that we need to keep the dpll
register state both in the pipe and in the shared_dpll struct, so
that we can check that every pipe is still connected to a correctly
configured dpll.
Note that since the refcount resconstruction isn't done yet this will
spill a few WARNs at boot-up while trying to disable pch plls which
have bogus refcounts. But since there's still a pile of refactoring to
do I'd like to lock down the state handling as soon as possible hence
decided against reordering the patches to quiet these WARNs - after
all the issues they're complaining about have existed since forever,
as Jesse can testify by having pch pll states blow up consistently in
his fastboot patches ...
v2: We need to preserve the old shared_dpll since currently the
shared dpll refcount dropping/getting is done in ->mode_set. With
the usual pipe_config infrastructure the old dpll id is already lost
at that point, hence preserve it in the new config.
v3: Rebase on top of the ips patch from Paulo.
v4: We need to unconditionally take over the shared_dpll id from the
old pipe config when e.g. doing a direct pch port -> cpu edp
transition.
v5: Move the saving of the old shared_dpll id to an ealier patch.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bits are evenly space, so we can cut down on two big switch
blocks. This also greatly simplifies the hw state readout which
follows in the next patch.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the big sed-job prep work done this is now really simple. With
the exception that we only assign the right shared dpll id in the
->mode_set callback but also depend upon the old one still being
around.
Until that mess is fixed up we need to jump through a few hoops to
keep the old value save.
v2: Kill the funny whitespace spotted by Chris.
v3: Move the shared_dpll pipe config fixup into this patch as noticed
by Ville. Also unconditionally set the shared_dpll with the current
one, since otherwise we won't handle direct pch port -> cpu edp
transitions correctly.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dealing with discrete enum values is simpler for hw state readout and
pipe config computations than pointers - having neat names instead of
chasing pointers should look better in the code.
This isn't a that good reason for pch plls, but on haswell we actually
have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having
explicit names should help there.
Since this also adds the intel_crtc_to_shared_dpll helper to further
abstract away the crtc -> dpll relationship this will also help to
make the next patch simpler, which moves the shared dpll into the pipe
configuration.
Also note that for uniformity we have two special dpll ids: NONE for
pipes which need a shared pll but don't have one (yet) and private for
when there's a non-shared pll (e.g. per-pipe or per-port pll).
I've thought whether we should also add a 2nd enum for the type of the
pll we want (for really generic pll selection code) but thrown that
idea out again - likely there's too much platform craziness going on
to be able to share the pll selection logic much.
Since this touched all the shared_pll functions a bit I've also done
an s/intel_crtc/crtc/ replacement on a few of them.
v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use
it to check that the compute config stage assigns a dpll to every pipe.
But since that code isn't ready yet until we move the dpll selection out
of the ->mode_set callback, there's no use for it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For fastboot we need some support to read out the sharing state of
plls, at least for platforms where they can be shared (or freely
assigned at least). Now for ivb we already have pretty extensive
infrastructure for tracking pch plls, and it took us an aweful lot of
tries to get that remotely right. Note that hsw could also share plls,
but even now they're already freely assignable. So we need this on
more than just ivb.
So on top of the usual fastboot fun pll sharing seems to be an
additional step up in fragility. Hence a common infrastructure for all
shared/freely assignable display plls seems to be in order.
The plan is to have a bit of dpll hw state readout code, which can be
used individually, but also to fill in the pipe config. The hw state
cross check code will then use that information to make sure that
after every modeset every pipe still is connected to a pll which still
has the correct configuration - a lot of the pch pll sharing bugs
where due to incorrect sharing.
We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
job.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Before I start to make a complete mess out of this, crank up
the paranoia level a bit.
v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid
as spotted by Ville since we currently only put the dpll when we
already have the new pipe config. So a direct pch port -> cpu edp
transition will hit this.
v3: Now that I've lifted my blinders add the WARN_ON Ville requested.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simlar to how disable already works on haswell. This is possible
since we now carefully track the pch state in the pipe config.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We ->mode_set is called we can't just blindly reuse an existing pll
since that might be shared with a different, still active pch output.
v2: Only update the pll settings when the pch pll is know to be
unused, otherwise we can wreak havoc with a running pipe. Which in the
case of DP will likely result in a black screen due to loss of link
lock.
v3: Tighten up the asserts a bit more, especially make sure that the
pch pll is still enabled when we try to disable it. This would have
caught the bug fixed in this patch.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This makes, arguably, the condition on state easier to read.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hotplug_mask is no longer used as the hpd interrupt setup is now
handled in the core.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't enable the cursor until g4x_fixup_plane() had a chance to do
cast its magic spell.
Egbert writes:
"Today I had the chance to test this. First I tried
if I can still reproduce the blank with this patch
added when I disable my voodoo g4x_fixup_plane():
It turned out it still happens however very rarely
(like 1 out of 20 tries). When I reenabled my voodoo
the issue still occurred.
I had to switch two lines around, ie:
intel_enable_plane(dev_priv, plane, pipe);
if (IS_G4X(dev))
g4x_fixup_plane(dev_priv, pipe);
+ intel_crtc_update_cursor(crtc, true);
to avoid the blank screen issue - which is it didn't
happen in ~75 tries."
v2: Add a comment to remind people of the ordering constraints
Acked-by: Egbert Eich <eich@suse.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaFbcNukeOn3DBlt for IVB, HSW.
According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC.
Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that
follows each render submission."
v2: Chris noticed that flush_domains check was missing here and also suggested to do
LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the
module parameter check.
v3: Adding Wa name as Damien suggested.
v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from spec.
v5: Ville noticed than on blt a Cache Clean LRI should be used instead the Nuke one.
v6: Check for flush domain on blt (by Ville).
Check for scanout dirty (by Chris).
v7: Apply proper fbc_dirty implemented by Chris.
v8: remove unused variables.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is required for tracking render damage for use with FBC and will be
used in subsequent patches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull the code to disable trickle feed for all primary planes into a
separate function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We disable trickle feed in all the (relevant) clock gating functions,
except ironlake_init_clock_gating(). Copy paste the same code there as
well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to BSpec, trickle feed should be disabled for BW and
mobile CL. Those constraints seem to match all of our gen4 chipsets.
Trickle feed is disabled via the MI_ARB_STATE register instead of
per plane controls on gen4.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
