Someone copy pasted the comment from the SNB code w/o reading it.
We never actually implemented the workaround to disable RCPB unit
clock gating on IVB. It would have been needed for early steppings,
but we don't care about those anymore, so just remove the stale
comment.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableRCCUnitClockGating is only relevant for SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaDisableRCCUnitClockGating is only relevant for SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Can't find any mention of WaDisableVDSUnitClockGating ever being
relevant for SNB. Remove it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A lot of the WM functions are only reading from that structure and are
already using const. While converting the code to use dev_priv instead
of dev, I noticed a few places where we can give that hint.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.
Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".
The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:
$ git grep "i915\." -- drivers/gpu/drm/i915
v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaApplyL3ControlAndL3ChickenMode is only listed for IVB and HSW in
W/A database and BSpec.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The w/a database lists both WaPsdDispatchEnable and
WaDisablePSDDualDispatchEnable for VLV. They appear to be the same
thing, so list both names.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The debug message telling FBC1 has been enabled is missing a newline.
Add it.
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>
On CTG and IVB+ we don't try to preserve any bits from the
DPFC_CONTROL register. Follow suit on ILK/SNB.
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 set up all the bits for DPFC_CONTROL but forgot to actually
write them to the register. Oops.
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>
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>
Make the FBC plane macros take the plane as a parameter.
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>
The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit.
CTG docs clearly state that it should be set only when tracking
back buffer modification in persistent mode. The bit is supposed
to be set by software after the first CPU modification to the
back buffer, and it would get automagically cleared by the hardware
on the next page flip.
Since we only track front buffer modification we don't need to set
this bit. GTT modification tracking still appears to work on ILK
and SNB with the bit unset. I don't have a CTG to verify how that
behaves.
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>
The ILK/SNB docs are a bit unclear what the persistent mode does, but
the CTG docs clearly state that it was meant to be used when we're
tracking back buffer modifications. We never do that, so leave it in
non-persistent mode.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use nuking instead of render tracking on IVB+, so there's
no point in writing IVB_FBC_RT_BASE.
v2: Drop the IVB_FBC_RT_BASE write too
v3: Move the SNB stuff elsewhere, leaving only IVB+ here
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>
Because whatever.*
* This should contain a fairly long list of issues and still
unresolved resgressions, but I didn't really get a vote.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those are two distinct concepts. Just use a comment to remind us to
remove that W/A at some point.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Conflicts are getting out of hand, and now we have to shuffle even
more in -next which was also shuffled in -fixes (the call for
drm_mode_config_reset needs to move yet again).
So do a proper backmerge. I wanted to wait with this for the 3.13
relaese, but alas let's just do this now.
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_pm.c
Besides the conflict around the forcewake get/put (where we chaged the
called function in -fixes and added a new parameter in -next) code all
the current conflicts are of the adjacent lines changed type.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE}
macros when enabling/disabling self-refresh on 915GM.
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>
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't frob the fifo split we don't actually need it. This is
different for some gen3 devices where we need the full fifo for self
refresh mode.
Cc: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.
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>
This was introduced in:
commit 7c4a395ff8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Oct 9 19:17:56 2013 +0300
drm/i915: Don't re-compute pipe watermarks except for the affected pipe
and I missed fixing it in:
commit fec8cba306
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Nov 27 11:10:26 2013 -0800
drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
It's needed for ILK+ platforms to fastboot without crashing on a divide
by 0 after a DPMS on action.
Note: Ville mentioned in his review that this confusion seems to go
down to the original introduction of this code in
commit 801bcfffbb
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri May 31 10:08:35 2013 -0300
drm/i915: properly set HSW WM_PIPE registers
So it seems to have been missed both in the fastboot patch and in the
3d mode suppport (where only crtc_htotal reflects the real pipe
width).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add note based on Ville's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on PCH
platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We forgot to intialize the watermark vfuncs for BDW, and hence the
watermarks were never updated.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like I forgot to update the ILK/SNB/IVB watermark patches to deal
with BDW. Add the relevant BDW checks to make sure we take the HSW
codepaths on BDW as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I need the tricky do_switch fix before I can merge the final piece of
the ppgtt enabling puzzle. Otherwise the conflict will be a real pain
to resolve since the do_switch hunk from -fixes must be placed at the
exact right place within a hunk in the next patch.
Conflicts:
drivers/gpu/drm/i915/i915_gem_context.c
drivers/gpu/drm/i915/i915_gem_execbuffer.c
drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We now have a very clear method of disabling LP1+ wartermarks,
and we can actually detect if we actually did disable them, or
if they were already disabled. Use that to clean up the
WaCxSRDisabledForSpriteScaling:ivb handling.
I was hoping to apply the workaround in a way that wouldn't
require a blocking wait, but sadly IVB really does appear to
require LP1+ watermarks to be off for an entire frame before
enabling sprite scaling. Simply disabling LP1+ watermarks
during the previous frame is not enough, no matter how early
in the frame we do it :(
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new HSW watermark code can now handle ILK/SNB/IVB as well, so
switch them over. Kill the old code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ILK doesn't like if we just write the LP1+ watermarks registers with 0.
We need to just disable the watermarks by clearing the enable bit. Use
that method also when disabling LP1+ watermarks in init_clock_gating.
It looks like disabling the sprite LP1 watermarks can cause underruns
even if we just toggle the WM1S_LP_EN bit. So treat that bit like the
actual watermark numbers and avoid setting it to 0 immediately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Linetime watermarks don't exist on ILK/SNB/IVB, so don't compute them
except on HSW.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ILK has a bunch of issues with FBC. First of all, BSpec tells us that
FBC WM should never be enabled. Secondly when FBC is enabled
with FBC WM disabled, LP2+ watermarks must be disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Multi-pipe LP1+ watermarks are a HSW+ feature, so let's not do it on
earlier generations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On ILK disabling LP1+ watermarks must be done carefully to avoid
underruns. If we just write 0 to the register in the middle of the scan
cycle we often get an underrun. So instead we have to leave the actual
watermark levels in the register intact, and just toggle the enable bit.
Presumably the hardware takes a while to get out of low power mode, and
so the watermark level need to stay valid until that time.
We also have to be careful with the WM1S_LP_EN bit. It seems the
hardware more or less treats it like the actual watermarks numbers, and
so we must not toggle it too soon. Just leave it alone when disabling
the LP1+ watermarks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ILK/SNB don't have LP2+ watermarks for sprites. Also the LP1 sprite
watermark register has its own enable bit. Take these differences
into account when programming the LP1+ registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On ILK/SNB only LP0/1 watermarks can be enabled when sprites are
enabled, and on ILK/SNB/IVB sprite scaling is limited to LP0 only.
So we can avoid computing the extra levels we're never going to use.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a new function ilk_wm_lp_latency() which will tell us what to write
into the WM_LPx register latency field. HSW is different from erlier
gens in this regard.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On IVB the display data buffer partitioning control lives in the
DISP_ARB_CTL2 register. Add the relevant defines/code for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
we want to enable/disable PC8. On the case where we're enabling PC8
this works fine, but on the case where we disable PC8 due to a non-eDP
monitor being enabled, we first enable the power well and then disable
PC8. Although wrong, this doesn't seem to be causing any problems now,
and we don't even see anything in dmesg. But the patches for runtime
D3 turn this problem into a real bug, so we need to fix it.
This fixes the "modeset-non-lpsp" subtest from the "pm_pc8" test from
intel-gpu-tools.
v2: - Rebase (i915_disable_power_well).
v3: - More reabase.
v4: - Rebase on top of -fixes instead of -nightly.
This is commit d62292c8f7 in -next, but
we need it in -fixes to address Dave's report.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reported-by: Dave Jones <davej@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
WaVSRefCountFullforceMissDisable and
WaDSRefCountFullforceMissDisable
VS is a carry-over from HSW, and DS is likely not used by anyone yet.
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Line of 106 chars is too long. Really.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
