- 21 May, 2014 4 commits
-
-
Ville Syrjälä authored
Now that we've plugged the mmio vs. ring flip race, we shouldn't need these vblank waits in the modeset codepaths anymore. So get rid of them. v2: gen2 needs to wait for planes to turn off before disabling pipe 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>
-
Ville Syrjälä authored
Now that the vblank wait is gone from intel_enable_primary_plane(), hsw_enable_ips() needs to do the vblank wait itself. Signed-off-by:
-
Ville Syrjälä authored
Starting from ILK, mmio flips also cause a flip done interrupt to be signalled. This means if we first do a set_base and follow it immediately with the CS flip, we might mistake the flip done interrupt caused by the set_base as the flip done interrupt caused by the CS flip. The hardware has a flip counter which increments every time a mmio or CS flip is issued. It basically counts the number of DSPSURF register writes. This means we can sample the counter before we put the CS flip into the ring, and then when we get a flip done interrupt we can check whether the CS flip has actually performed the surface address update, or if the interrupt was caused by a previous but yet unfinished mmio flip. Even with the flip counter we still have a race condition of the CS flip base address update happens after the mmio flip done interrupt was raised but not yet processed by the driver. When the interrupt is eventually processed, the flip counter will already indicate that the CS flip has been executed, but it would not actually complete until the next start of vblank. We can use the DSPSURFLIVE register to check whether the hardware is actually scanning out of the buffer we expect, or if we managed hit this race window. This covers all the cases where the CS flip actually changes the base address. If the base address remains unchanged, we might still complete the CS flip before it has actually completed. But since the address didn't change anyway, the premature flip completion can't result in userspace overwriting data that's still being scanned out. CTG already has the flip counter and DSPSURFLIVE registers, and although the flip done interrupt is still limited to CS flips alone, the code now also checks the flip counter on CTG as well. v2: s/dspsurf/gtt_offset/ (Chris) Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027Signed-off-by:
-
Jesse Barnes authored
We really just want to go detect displays again and fire off a hotplug event if things have changed, not go through full hotplug processing. Requested-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 20 May, 2014 36 commits
-
-
Daniel Vetter authored
Since commit 2e82a720 Author: Imre Deak <imre.deak@intel.com> Date: Fri Jan 17 15:46:43 2014 +0200 drm/i915: don't disable DP port after a failed link training and commit 5d6a1116 Author: Imre Deak <imre.deak@intel.com> Date: Thu Jan 16 18:35:57 2014 +0200 drm/i915: don't disable the DP port if the link is lost we no longer call intel_dp_link_down from generic DP code, but only from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder disabling callback in intel_ddi.c. Hence the early return is no longer needed and the big comment just confusing, so let's rip it out. To ensure what we don't accidentally use this again on ddi encoders add a WARN_ON instead. Spotted while reading through intel_dp.c Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jani Nikula authored
Somehow a few functions have been dropped in the middle of backlight code. Move them around. No functional changes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Clear the reset domain after a succesful GPU reset on ilk. We already do that on gen4, so let's try to be a bit more consistent. And if ether render or media reset fails, we might use the leftover value in the register to pinpoint the culprit. Signed-off-by:
-
Ville Syrjälä authored
All the other bits in the GDSR register are read-only, so we don't have to preserve them when we perform a GPU reset. Signed-off-by:
-
Imre Deak authored
I'm trying to reduce the WARNs during driver reload and this was one of them. Also while at it remove the redundant condition from before unregister_shrinker(). v2: - fix the error path too and move the unregister to its logical place (Chris) - remove redundant condition from before unregister_shrinker() Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
The comments in i915_reg.h aren't proper kernel-doc comments, so replace the magic /** with just /* Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The following workarounds should be needed for pre-production hardware only: * WaDisablePwrmtrEvent:chv * WaSetMaskForGfxBusyness:chv * WaDisableGunitClockGating:chv * WaDisableFfDopClockGating:chv * WaDisableDopClockGating:chv Signed-off-by:
-
Ville Syrjälä authored
The spec only tells us to set individual bits here and there. So we use RMW for most things. Do the same for the swing calc init. Eventually we should optimize things to just blast the final value in with group access whenever possible. But to do that someone needs to take a good look at what's the reset value for each registers, and possibly if the BIOS manages to frob with some of them. For now use RMW access always. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Like PCS, TX group reads return 0xffffffff. So we need to target each lane separately if we want to use RMW cycles to update the registers. Signed-off-by:
-
Ville Syrjälä authored
All PCS groups access reads return 0xffffffff, so we can't use group access for RMW cycles. Instead target each spline separately. Signed-off-by:
-
Ville Syrjälä authored
The bits we've been setting so far only progagate the reset singal to the data lanes. To actaully force the reset signal we need to set another override bit. v2: Fix mispalced ';' (Mika) Reviewed-by:
-
Ville Syrjälä authored
Seems like we shouldn't leave the data lane resert deasserted when the port if disabled. So propagate the reset the data lanes in the encoder .post_disable() hook. Signed-off-by:
-
Ville Syrjälä authored
During the enable sequence we first enable the dclkp output to the display controller, and then enable the PLL. Do the opposite during the disable sequence. Signed-off-by:
-
Ville Syrjälä authored
We need to pick the correct data lanes based on the port not the pipe, so move the data lane deassert into the encoder .pre_enable() hook from the chv_enable_pll(). Signed-off-by:
-
Ville Syrjälä authored
Setup the pipe config dpll state correctly for CHV. Also add a assert_pipe_disabled() to chv_disable_pll(), and program the DPLL_MD registers in chv_enable_pll(). Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Fix the encoder .get_config hooks to report the correct active pipe for CHV. Signed-off-by:
-
Ville Syrjälä authored
CHV has three pipes so let's expose them all. Signed-off-by:
-
Ville Syrjälä authored
Unsurprisingly the cursor C regiters are also at a weird offset on CHV. Add more pipe offsets to handle them. This also gets rid of most of the differences between the i9xx vs. ivb cursor code. We can unify the remaining code as well, but I'll leave that for another patch. Signed-off-by:
-
Ville Syrjälä authored
On CHV the GMBUS port for port D is different from other gmch platforms which have port D. Fix it up. Signed-off-by:
-
Ville Syrjälä authored
On CHV pipe C can driver only port D, and pipes A and B can drivbe only ports B and C. Configure the crtc_mask appropriately to reflect that. v2: Moar braces (Jani) Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Rafael Barbalho authored
Add support for the third pipe in cherrview v2: Don't use spaces for indentation (Jani) Wrap long lines Reviewed-by:Rafael Barbalho <rafael.barbalho@intel.com> [vsyrjala: slightly massaged the patch] Signed-off-by:
-
Rafael Barbalho authored
Cherryview also needs this WA. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We implement the following workarounds: * WaDisableAsyncFlipPerfMode:chv * WaProgramMiArbOnOffAroundMiSetContext:chv v2: Drop WaDisableSemaphoreAndSyncFlipWait note Signed-off-by:
-
Ville Syrjälä authored
Reviewed-by:
-
Ville Syrjälä authored
This workaround is listed for CHV, but not for BDW. However BSpec notes that on BDW CSunit clock gating is always disabled irrespective of the relevant bit in the GEN6_UGCTL1 registers. For CHV however, such text is not present in BSpec, so it seems safer to just set the bit. Reviewed-by:
-
Ville Syrjälä authored
BDW has the same requirement but the w/a database doens't list this w/a for BDW. Seems to be another one of those "stick a bunch of known workarounds into this bag and write something on the label" type of things. Reviewed-by:
-
Ville Syrjälä authored
drm/i915/chv: Implement WaVSRefCountFullforceMissDisable:chv and WaDSRefCountFullforceMissDisable:chv Reviewed-by:
-
Ville Syrjälä authored
Reviewed-by:
-
Ville Syrjälä authored
Reviewed-by:
-
Daniel Vetter authored
Besides the fairly useless BUG_ON the logic is completely generic and cane be used on any platform what wants to reuse the shared dpll support code. Reviewed-by:
-
Daniel Vetter authored
This is the last piece of code which write state to the hardware in the ironalake ->crtc_mode_set callback. I think we could merge this with the pll->enable hook, but otoh the ordering requirements with the ldvs port are really tricky. Doing the FP0/1 writes up-front before we even prepare the lvds port (in the pre_pll_enable hook) like on i9xx seems safest. With this ilk+ platforms are now ready for runtime PM with DPMS. Since hsw/bdw also support runtime pm besides snb we need to first make the haswell code save before we can touch the core code. Reviewed-by:
-
Daniel Vetter authored
Instead of every time it isn't active: We only need to do that when the pll is currently unused, i.e. when pll->refcount == 0. For paranoia add a warning for the ibx case where plls have a fixed mapping and hence should always be unused after the call to intel_put_shared_dpll. v2: Simplify control flow and use struct assignment instead of memcpy as suggested by Damien. Reviewed-by:
-
