- 11 Jun, 2014 40 commits
-
-
Deepak S authored
On CHV, All the freq request should be even. So, we need to make sure we request the opcode accordingly. v2: Avoid vairable for freq request (ville) Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
CHV uses the gen8 shadow register mechanism so we shouldn't be checking the GT FIFO status. This effectively removes the posting read, so add an explicit posting read using FORCEWAKE_ACK_VLV (which is what use in vlv_forcewake_reset()). Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Skip __gen6_gt_wait_for_thread_c0() on CHV. Reviewed-by:
-
Deepak S authored
v2: Disable media turbo and Add DOWN_IDLE_AVG support (Ville) v3: Mass rename of the dev_priv->rps variables in upstream. v4: Rebase against latest code. (Deepak) v5: Rebase against latest nightly code. (Deepak) v6: Rename the variables to match the spec (Mika) v7: change min/max freq variable naming to match spec (Mika) Signed-off-by:
-
Ville Syrjälä authored
Because of the upcoming vblank interrupt driven watermark update mechanism we will have use for vblank interrupts during plane enabling/disabling. So don't call drm_vblank_off() until planes are off, and call drm_vblank_on() just before we start to enable the planes. v2: Pimp commit message (Paulo) Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Deepak S authored
Support to individually control Media/Render well based on the register access. Add CHV specific write function to habdle difference between registers that are sadowed vs those that need forcewake even for writes. Streamline the CHV forcewake functions just like was done for VLV. This will also fix a bug in accessing the common well registers, where we'd end up trying to wake up the wells too many times since we'd call force_wake_get/put twice per register access, with FORCEFAKE_ALL both times. v2: Drop write FIFO for CHV and add comman well forcewake (Ville) Re-factor CHV/VLV Forcewake offsets (Ben) v3: Fix for decrementing fw count in chv read/write. (Deepak) v4: Squash the patches (Mika) Reviewed-by: -
Deepak S authored
v2: Configure PCBR if BIOS fails allocate pcbr (deepak) v3: Fix PCBR condition check during CHV RC6 Enable flag set v4: Fixup PCBR comment msg. (Chris) Rebase against latest code (Deak) Fixup Spurious hunk (Ben) v5: Fix PCBR and commentis msg (mika) v6: Rebase patch on latest nightly (Deepak) Signed-off-by: -
Rodrigo Vivi authored
"Because our driver assumes only one panel is PSR capable, and we already have other PSR information on dev_priv instead of intel_dp. If we ever support multiple PSR panels, we'll have to move struct i915_psr to intel_dp anyway." (by Paulo) v2: Avoid more than one setup. Removing initialization and trusting allocation. (By Paulo Zanoni). v3: rebase. v4: Adding comment. Reviewed-by:Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Dave Airlie authored
Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next display rework fixes lots of displayport issues. * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (43 commits) drm/nouveau/disp/dp: fix tmds passthrough on dp connector drm/nouveau/dp: probe dpcd to determine connectedness drm/nv50-: trigger update after all connectors disabled drm/nv50-: prepare for attaching a SOR to multiple heads drm/gf119-/disp: fix debug output on update failure drm/nouveau/disp/dp: make use of postcursor when its available drm/g94-/disp/dp: take max pullup value across all lanes drm/nouveau/bios/dp: parse lane postcursor data drm/nouveau/dp: fix support for dpms drm/nouveau: register a drm_dp_aux channel for each dp connector drm/g94-/disp: add method to power-off dp lanes drm/nouveau/disp/dp: maintain link in response to hpd signal drm/g94-/disp: bash and wait for something after changing lane power regs drm/nouveau/disp/dp: split link config/power into two steps drm/nv50/disp: train PIOR-attached DP from second supervisor drm/nouveau/disp/dp: make use of existing output data for link training drm/gf119/disp: start removing direct vbios parsing from supervisor drm/nv50/disp: start removing direct vbios parsing from supervisor drm/nouveau/disp/dp: maintain receiver caps in response to hpd signal drm/nouveau/disp/dp: create subclass for dp outputs ...
-
Ben Skeggs authored
Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We were sending the necessary state changes to unset the mode, but never actually hit the big GO button unless another modeset happens afterwards. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
And at the same time, obey the spec better wrt out-of-range requests. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
SOR_PWR has no effect to power-off DP links, unlike other SOR protocols. Instead, on the source side, we cut power to the lanes after having put the sink into D3. Link training takes care of everything required to bring it back again. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This previously worked for the most part due to userspace doing a modeset in response to HPD interrupts. This will allow us to properly handle cases where sync is lost for other reasons, or if userspace isn't caring. Signed-off-by: -
Ben Skeggs authored
Some kind of update? Needed to make the power-down take effect at least. Signed-off-by: -
Ben Skeggs authored
We want to be able to power down the lanes for DPMS off. Signed-off-by: -
Ben Skeggs authored
Same place as for SOR, between detach and attach phases. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This will, at some point, be used to replace various bits and pieces of code doing direct bios parsing. For now, it'll just be used for some DP improvements. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
There's also provisions to allow a pad to be locked with a specific routing, for an indefinite period of time. This will be used in future patches. The G94+ pad driver will now also power-down pads when not required. Signed-off-by: -
Ben Skeggs authored
This was a half-finished hack before, just enough to handle the shared aux/i2c pad thing on G94 and up. We got lucky with locking etc up until now, as this was (generally) all protected by the DRM mode_config lock. It's about to become a lot more likely to hit the races. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
