aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_pm.c
Commit message (Collapse)AuthorAge
...
* | drm/i915: WaPsdDispatchEnable seems to be another name for ↵Ville Syrjälä2014-01-27
| | | | | | | | | | | | | | | | | | | | | | | | WaDisablePSDDualDispatchEnable 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>
* | drm/i915: We implement WaDisableL3Bank2xClockGate:vlvVille Syrjälä2014-01-27
| | | | | | | | | | | | 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>
* | drm/i915: Fix FBC1 enable messageVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't preserve DPFC_CONTROL bits ILK/SNBVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Actually write the correct bits to DPFC_CONTROL on CTGVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Use 1/2 compression ratio limit for 16bpp on FBC2Ville Syrjälä2014-01-25
| | | | | | | | | | | | 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>
* | drm/i915: Improve FBC plane defines a bitVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't set DPFC_HT_MODIFY bit on CTG/ILK/SNBVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't set persistent FBC mode on ILK/SNBVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't write IVB_FBC_RT_BASEVille Syrjälä2014-01-25
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'topic/ppgtt' into drm-intel-next-queuedDaniel Vetter2014-01-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * \ Merge commit drm-intel-fixes into topic/ppgttDaniel Vetter2013-12-18
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | drm/i915: Make pin count per VMABen Widawsky2013-12-18
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Don't use i915_preliminary_hw_support to mean pre-productionDamien Lespiau2014-01-24
| |_|/ |/| | | | | | | | | | | | | | | | | | | | 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>
* | | Merge commit origin/master into drm-intel-nextDaniel Vetter2014-01-16
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | drm/i915: get a PC8 reference when enabling the power wellPaulo Zanoni2013-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 d62292c8f778772d1b6ec125d461c8c16fdc0417 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>
| * | | Merge tag 'drm-intel-fixes-2013-12-11' of ↵Dave Airlie2013-12-11
| |\ \ \ | | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just a bunch of regression fixes plus a few patches for long-standing issues in gem corner-cases that we've hunted down in the past weeks. Since apparently people hit those in the wild (and we also have nice igts for them) I've opted for -fixes and cc: stable. There's 1-2 things oustanding on top of this where I'm still waiting on confirmation from testing, but nothing really scary. * tag 'drm-intel-fixes-2013-12-11' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: don't update the dri1 breadcrumb with modesetting drm/i915: Repeat eviction search after idling the GPU drm/i915: Fix use-after-free in do_switch drm/i915: fix pm init ordering drm/i915: Hold mutex across i915_gem_release drm/i915: Skip clock checks on BDW drm/i915: Do not clobber config status after a forced restore of hw state drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
| | * | drm/i915: fix pm init orderingDaniel Vetter2013-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Shovel a bit more of the the code into the setup function, and call it earlier. Otherwise lockdep is unhappy since we cancel the delayed resume work before it's initialized. While at it also shovel the pc8 setup code into the same functions. I wanted to also ditch the header declaration of the hws pc8 functions, but for unfathomable reasons that stuff is in intel_display.c instead of intel_pm.c. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980 Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | Merge branch 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie2013-12-11
| |\ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes As promised bdw fixes come separate for now. Just a few minior things. * 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell drm/i915/bdw: Limit GTT to 2GB drm/i915/bdw: Add comment about gen8 HWS PGA drm/i915/bdw: Free correct number of ppgtt pages drm/i915/bdw: Do gen6 style reset for gen8 drm/i915/bdw: GEN8 backlight support drm/i915/bdw: Add BDW to ULT macro
| * | | drm/i915: use crtc_htotal in watermark calculations to match fastboot v2Jesse Barnes2013-11-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This value is more correct, and matches what we read out in the fastboot code. Without this, the watermark code will panic after the first mode setting activity after a fastboot. v2: fix up HSW ->clock usage too (Ville) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Fix 915GM self-refresh enable/disableVille Syrjälä2014-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: i830M has watermarks like i855Daniel Vetter2014-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Drop I915_ prefix from HAS_FBCDaniel Vetter2014-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: use crtc_htotal when calculating ilk watermarksJesse Barnes2014-01-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was introduced in: commit 7c4a395ff8f441acb7876281c6777624e6410349 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 fec8cba306f974f3a4491176994de5d821273643 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 801bcfffbb0721d7131e930f9a46103e539c43a4 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>
* | | | drm/i915: Simplify watermark/init_clock_gating setupVille Syrjälä2014-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Enable watermarks for BDWVille Syrjälä2014-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Fix watermark code for BDWVille Syrjälä2014-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: s/haswell_update_wm/ilk_update_wm/Imre Deak2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: simplify platform specific code in hsw_write_wm_valuesImre Deak2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Try to fix the messy IVB sprite scaling workaroundVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Move ILK/SNB/IVB over to the HSW WM codeVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Disable LP1+ watermarks safely in initVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Linetime watermarks are a HSW featureVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Disable FBC WM on ILK, and disable LP2+ when FBC is enabledVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Don't merge LP1+ watermarks on ILK/SNB/IVB when multiple pipes are ↵Ville Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | enabled 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>
* | | | drm/i915: Fix LP1+ watermark disabling ILKVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Fix LP1 sprite watermarks for ILK/SNBVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Avoid computing invalid WM levels when sprites/scaling is enabledVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Add ILK/SNB/IVB WM latency field supportVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Add IVB DDB partitioning controlVille Syrjälä2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flagDamien Lespiau2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915/bdw: Implement ff workaroundsBen Widawsky2013-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | drm/i915/bdw: Force all Data Cache Data Port access to be Non-CoherentBen Widawsky2013-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I stumbled on to some unimplemented errata. To be honest, I am not really sure of the impact, just that the docs say to do. No w/a name for this one. v2: v1 was a stale thing which should have never seen the light of day. (Haihao) Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Rework the FBC interval/stall stuff a bitVille Syrjälä2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update the FBC_CONTROL on FBC1 to make it easier for people to experiment with different numbers. Also fix the interval mask for FBC1. v2: Rebased Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: FBC_CONTROL2 is gen4 onlyVille Syrjälä2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't touch 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>
* | | | drm/i915: Gen2 FBC1 CFB pitch wants 32B unitsVille Syrjälä2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On gen2 the compressed frame buffer pitch is specified in 32B units rather than the 64B units used on gen3+. 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>
* | | | drm/i915: touch VGA MSR after we enable the power wellPaulo Zanoni2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes regression introduced by: commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41 Author: Paulo Zanoni <paulo.r.zanoni at intel.com> Date: Wed Jul 3 17:12:13 2013 -0300 drm/i915: switch disable_power_well default value to 1 The bug I'm seeing can be reproduced with: - Have vgacon configured/enabled - Make sure the power well gets disabled, then enabled. You can check this by seeing the messages print by hsw_set_power_well - Stop your display manager - echo 0 > /sys/class/vtconsole/vtcon1/bind I can easily reproduce this by blacklising snd_hda_intel and booting with eDP+HDMI. If you do this and then look at dmesg, you'll see we're printing infinite "Unclaimed register" messages. This is happening because we're stuck on an infinite loop inside console_unlock(), which is calling many functions from vgacon.c. And the code that's triggering the error messages is from vgacon_set_cursor_size(). After we re-enable the power well, every time we read/write the VGA address 0x3d5 we get an "unclaimed register" interrupt (ERR_INT) and print error messages. If we write anything to the VGA MSR register (it doesn't really matter which value you write to bit 0), any reads/writes to 0x3d5 _don't_ trigger the "unclaimed register" errors anymore (even if MSR bit 0 is zero). So what happens with the current code is that when we unbind i915 and bind vgacon, we call console_unlock(). Function console_unlock() is responsible for printing any messages that were supposed to be print when the console was locked, so it calls the TTY layer, which calls the console layer, which calls vgacon to print the messages. At this point, vgacon eventually calls vgacon_set_cursor_size(), which touches 0x3d5, which triggers unclaimed register interrupts. The problem is that when we get these interrupts, we print the error messages, so we add more work to console_unlock(), which will try to print it again, and then call vgacon again, trigger a new interrupt, which will put more stuff to the buffer, and then we'll be stuck at console_unlock() forever. If you patch intel_uncore.c to not print anything when we detect unclaimed registers, we won't get into the console_unlock() infinite loop and the driver unbind will work just fine. We will still be getting interrupts every time vgacon touches those registers, but we will survive. This is a valid experiment, but IMHO it's not the real fix: if we don't print any error messages we will still keep getting the interrupts, and if we disable ERR_INT we won't get the interrupt anymore, but we will also stop getting all the other error interrupts. I talked about this problem with the HW engineer and his recommendation is "So don't do any VGA I/O or memory access while the power well is disabled, and make to re-program MSR after enabling the power well and before using VGA I/O or memory accesses.". Notice that this is just a partial fix to fd.o #67813. This fixes the case where the power well is already enabled when we unbind, not when it's disabled when we unbind. V2: - Rebase (first version was sent in September). V3: - Complete rewrite of the same fix: smaller implementation, improved commit message. Testcase: igt/drv_module_reload Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: extract hsw_power_well_post_{enable, disable}Paulo Zanoni2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to add more code to the post_enable function. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: add initial Runtime PM functionsPaulo Zanoni2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the initial infrastructure to allow a Runtime PM implementation that sets the device to its D3 state. The patch just adds the necessary callbacks and the initial infrastructure. We still don't have any platform that actually uses this infrastructure, we still don't call get/put in all the places we need to, and we don't have any function to save/restore the state of the registers. This is not a problem since no platform uses the code added by this patch. We have a few people simultaneously working on runtime PM, so this initial code could help everybody make their plans. V2: - Move some functions to intel_pm.c - Remove useless pm_runtime_allow() call at init - Remove useless pm_runtime_mark_last_busy() call at get - Use pm_runtime_get_sync() instead of 2 calls - Add a WARN to check if we're really awake V3: - Rebase. V4: - Don't need to call pci_{save,restore}_state and pci_set_power_sate, since they're already called by the PCI layer - Remove wrong pm_runtime_enable() call at init_runtime_pm Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: get a PC8 reference when enabling the power wellPaulo Zanoni2013-12-10
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-10 07:59:30 -0400