aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_dp.c
Commit message (Collapse)AuthorAge
* drm/i915/eDP: When enabling panel VDD cancel pending disable workerEgbert Eich2014-12-03
| | | | | | | | | | | | | | | | | | Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker will be triggered with a delay from the last time edp_panel_vdd_schedule_off() is called, not the first time. This avoids unnecessary overhead. https://bugs.freedesktop.org/show_bug.cgi?id=86201 v2: use cancel_delayed_work() instead of cancel_delayed_work_sync() as the pps_mutexes will provide the required serialization with edp_panel_vdd_work() while the sync variant may deadlock. Suggested by Ville Syrjälä <ville.syrjala@linux.intel.com>. Made commit message a bit clearer. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2014-11-21-fixed' of ↵Dave Airlie2014-12-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2014-11-21: - infoframe tracking (for fastboot) from Jesse - start of the dri1/ums support removal - vlv forcewake timeout fixes (Imre) - bunch of patches to polish the rps code (Imre) and improve it on bdw (Tom O'Rourke) - on-demand pinning for execlist contexts - vlv/chv backlight improvements (Ville) - gen8+ render ctx w/a work from various people - skl edp programming (Satheeshakrishna et al.) - psr docbook (Rodrigo) - piles of little fixes and improvements all over, as usual * tag 'drm-intel-next-2014-11-21-fixed' of git://anongit.freedesktop.org/drm-intel: (117 commits) drm/i915: Don't pin LRC in GGTT when dumping in debugfs drm/i915: Update DRIVER_DATE to 20141121 drm/i915/g4x: fix g4x infoframe readout drm/i915: Only call mod_timer() if not already pending drm/i915: Don't rely upon encoder->type for infoframe hw state readout drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersave drm/i915: Use ggtt error obj capture helper for gen8 semaphores drm/i915: vlv: increase timeout when setting idle GPU freq drm/i915: vlv: fix cdclk setting during modeset while suspended drm/i915: Dump hdmi pipe_config state drm/i915: Gen9 shadowed registers drm/i915/skl: Gen9 multi-engine forcewake drm/i915: Read power well status before other registers for drpc info drm/i915: Pin tiled objects for L-shaped configs drm/i915: Update ring freq for full gpu freq range drm/i915: change initial rps frequency for gen8 drm/i915: Keep min freq above floor on HSW/BDW drm/i915: Use efficient frequency for HSW/BDW drm/i915: Can i915_gem_init_ioctl drm/i915: Sanitize ->lastclose ...
| * Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queuedDaniel Vetter2014-11-19
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So with all the code movement and extraction in intel_pm.c in -next git is hopelessly confused with commit 2208d655a91f9879bd9a39ff9df05dd668b3512c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 14 09:25:29 2014 +0100 drm/i915: drop WaSetupGtModeTdRowDispatch:snb from -fixes. Worse even small changes in -next move around the conflict context so rerere is equally useless. Let's just backmerge and be done with it. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Except for git getting lost no tricky conflicts really. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * | drm/i915: Tune down sink crc timeout dmesg outputDaniel Vetter2014-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For whatever reasons this can happen. For real testcases the test will notice the -EIO and fall over, but we also have some testcases that just read all debugfs files. And that shouldn't cause dmesg spam. So tune it down a bit so that we still have the information for debugging. And change the errno so that real testcases can easily differentiate. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84890 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * | drm/i915/skl: Set the eDP link rate on DPLL0Damien Lespiau2014-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On SKL DPLL0 is used to derive CDCLK but can also be used to drive an eDP port (as long as we don't want SSC). DPLL0 is special enough to not be handled by the shared DPLL framework (drives CDCLK, not supposed to enable the HDMI mode), So we need to compute the configuration separately from the other DPLLs. Note that we don't need to reprogram DPLL0 (which would mean bringing down CDCLK) to support the various eDP 1.3 link rates as they all share the same VCO (8100). 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>
| * | drm/i915: Introduce intel_psr.cRodrigo Vivi2014-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No functional changes. Just cleaning and reorganizing it. v2: Rebase it puting it to begin of psr rework. This helps to blame easily at least latest changes. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make dp aux pack/unpack public outside intel_dp.cRodrigo Vivi2014-11-17
| | | | | | | | | | | | | | | | | | | | | | | | No functional change. Just making it public for use outside intel_dp.c Allowing split psr functions. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Pass the current pipe from eDP init to backlight setupVille Syrjälä2014-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/CHV both pipes A and B have their own backlight control registers. In order to correctly read out the current hardware state at init we need to know which pipe is driving the eDP port. Pass that information down from the eDP init code into the backlight code. To determine the correct pipe we first look at which pipe is currently configured in the port control register, if that look invalid we look at which pipe's PPS is currently controlling the port, and if that too looks invalid we just assume pipe A. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | Merge tag 'v3.18-rc7' into drm-nextDave Airlie2014-12-01
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a bunch of conflicts prior to merging i915 tree. Linux 3.18-rc7 Conflicts: drivers/gpu/drm/exynos/exynos_drm_drv.c drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/tegra/dc.c
| * | | drm/i915: Cancel vdd off work before suspendVille Syrjälä2014-11-26
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we just make sure vdd is off before suspending, but we don't cancel the vdd off work. The work wil not touch vdd if want_panel_vdd==false so in theory this is fine. In the past that was perfectly fine since the vdd off work didn't do anything when want_panel_vdd==false, so even if the work would have been run during system resume before i915 has resumed, nothing would happen. However since pps_lock() will now grab the power domain references before it can check want_panel_vdd, we may end up toggling the power wells on/off already before the driver has resumed. That is not really acceptable, so cancel the vdd off work when suspending the encoder. The problem appeared when pps_lock() was introduced in: commit 773538e86081d146e0020435d614f4b96996c1f9 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:56 2014 +0300 drm/i915: Reset power sequencer pipe tracking when disp2d is off Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | Merge tag 'drm-intel-next-2014-11-07-fixups' of ↵Dave Airlie2014-11-14
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - skl watermarks code (Damien, Vandana, Pradeep) - reworked audio codec /eld handling code (Jani) - rework the mmio_flip code to use the vblank evade logic and wait for rendering using the standard wait_seqno interface (Ander) - skl forcewake support (Zhe Wang) - refactor the chv interrupt code to use functions shared with vlv (Ville) - prep work for different global gtt views (Tvrtko Ursulin) - precompute the display PLL config before touching hw state (Ander) - completely reworked panel power sequencer code for chv/vlv (Ville) - pre work to split the plane update code into a prepare and commit phase (Gustavo Padovan) - golden context for skl (Armin Reese) - as usual tons of fixes and improvements all over * tag 'drm-intel-next-2014-11-07-fixups' of git://anongit.freedesktop.org/drm-intel: (135 commits) drm/i915: Use correct pipe config to update pll dividers. V2 drm/i915: Plug memory leak in intel_shared_dpll_start_config() drm/i915: Update DRIVER_DATE to 20141107 drm/i915: Add gen to the gpu hang ecode drm/i915: Cache HPLL frequency on VLV/CHV Revert "drm/i915/vlv: Remove check for Old Ack during forcewake" drm/i915: Make mmio flip wait for seqno in the work function drm/i915: Make __wait_seqno non-static and rename to __i915_wait_seqno drm/i915: Move the .global_resources() hook call into modeset_update_crtc_power_domains() drm/i915/audio: add DOC comment describing HDA over HDMI/DP drm/i915: make pipe/port based audio valid accessors easier to use drm/i915/audio: add audio codec enable debug log for g4x drm/i915/audio: add audio codec disable on g4x drm/i915: enable audio codec after port drm/i915/audio: add vlv/chv/gen5-7 audio codec disable sequence drm/i915/audio: rewrite vlv/chv and gen 5-7 audio codec enable sequence drm/i915/skl: Enable Gen9 RC6 drm/i915/skl: Gen9 Forcewake drm/i915/skl: Log the order in which we flush the pipes in the WM code drm/i915/skl: Flush the WM configuration ...
| * | drm/i915: enable audio codec after portJani Nikula2014-11-07
| | | | | | | | | | | | | | | | | | | | | | | | As per spec, and similar to DDI. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/audio: add vlv/chv/gen5-7 audio codec disable sequenceJani Nikula2014-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for disabling the audio codec on vlv/chv/gen5-7, similar to hsw/bdw. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/dp: Don't stop the link when retrainingDaniel Vetter2014-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-ddi platforms we don't shut down the link when changing link training parameters. Except when clock recovery fails too hard and we restart with channel eq training. Which doesn't make a lot of sense really, since just stopping/restarting the DP port at this point violates the modeset sequence documented in the Bspec. So let's tempt fate and try this. This patch is motivated by a WARN_ON triggered by commit bc76e320f21f8bd790a72bd5dc06909617432352 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue May 20 22:46:50 2014 +0200 drm/i915: Drop now misleading DDI comment from dp_link_down References: https://bugs.freedesktop.org/show_bug.cgi?id=85670 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Read out the power sequencer port assignment on resume on vlv/chvVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we suspend we turn everything off so the pps should be idle, and we also (or at least should) disable all power wells which will reset the power sequencer port assignment. So when we resume all power sequencers should be in their reset state. However it's at least theoretically possible that the BIOS would touch the power seuqencer(s), so to be safe we ought to read out the current port assignment like we do at driver init time. To do that we can simply call vlv_initial_power_sequencer_setup() from the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize(). There's no danger or clobbering the pps delays since we now have those stored within intel_dp and we don't change them once initialized. This will make sure that the vdd state gets correctly tracked post-resume in case the BIOS enabled it. We need to shuffle things around a bit to get the locking right, and while at it, make intel_edp_panel_vdd_sanitize() static and move it around a bit to avoid a forward declaration. Cc: Imre Deak <imre.deak@intel.com> 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: Initialize PPS timestamps on vlv/chvVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pps timestamp initialization was accidentally lost on vlv/chv in commit a4a5d2f8a96e09844a91469e889f15bd5e927399 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:20 2014 +0300 drm/i915: Track which port is using which pipe's power sequencer Restore it so that we avoid introducing random delays into the pps operations during/after driver init time. Cc: Imre Deak <imre.deak@intel.com> Reported-by: Imre Deak <imre.deak@intel.com> 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: introduce intel_audio_codec_{enable, disable}Jani Nikula2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce functions to enable/disable the audio codec, incorporating the ELD setup within enable. The disable is initially limited to HSW, covering exactly what was done previously. The only functional difference is that ELD valid is no longer set if there is no connector with ELD, which should be the right thing to do anyway. Otherwise the sequence remains the same, with warts and all, in preparation for applying more sanity. v2: add kernel doc. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make sure DPLL is enabled when kicking the power sequencer on VLV/CHVVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The power seqeuencer kick procedure requires the DPLL to be running in order to complete successfully. In case the DPLL isn't currently running when we need to kick the power seqeuncer enable it temporarily. This can happen eg. during ->detect() when the pipe is not already active. To avoid needlessly duplicating the DPLL programming re-use the already existing functions by passing a temporary pipe config to them instead of having them consult the current pipe config at crtc->config. v2: Introduce vlv_force_pll_{on,off}() (Daniel) v3: Rebase due to drm_crtc vs. intel_crtc changes Fix a typo in commit msg (checkpatch) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Warn if stealing power sequencer from an active eDP portVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eDP ports need the power seqeuncer whenever the port is active. Warn if we accidentally steal the power sequener from an active eDP port. This should not happen unless there's a bug somewhere else, but it's best to scream loudly if it happens to help with debugging. Note that this only checks for active pipes and not for enabled pipes which are turned off with dpms. Which means we might run the risk that the pps might get stolen and we can't reacquire one when enabling the pipe again with dpms on. But on current platforms that's impossible since we only support two edp ports with just two panel power sequencers. So a more elaborate scheme which reserves the pps even when the pipe is inactive isn't required. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Summarize my discussion with Ville about dpms on/off issues.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Warn if panel power is already on when enabling itVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should never enable the panel power twice. That would indicate a bug somewhere else as we would need to enable the port twice without disabling it in between. Also print the port name. 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: Improve VDD/PPS debugsVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | Print the port name in the VDD/PPS debugs messages. 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: Steal power sequencer in vlv_power_sequencer_pipe()Ville Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case we fumble something and end up picking an already used power seqeuencer in vlv_power_sequencer_pipe() at least try to steal it gracefully. In theory this should never happen though. 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: Warn if stealing non pipe A/B power sequencerVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | There's no power sequencer on pipe C on VLV/CHV so scream a bit if we try to steal one from pipes other than A and B. 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: Clear PPS port select when giving up the power sequencerVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VLV gets confused if two power sequencers have the same port selected. It would seem the port doesn't start up properly in the is case and vlv_wait_port_ready() will fail as will the link training. Clearing the port select in the PP_ON_DELAYS register fixes this problem. CHV doesn't seem to need this, but it doesn't seem to hurt either so let's just do it for both to keep the code between the platforms as uniform as possible. 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 kick the power seqeuncer just to check if we have vdd/panel ↵Ville Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | power If there's no power sequencer assigned to the port currently we can't very well have vdd or panel power enabled either. If we would try to check that from the pps registers we'd need to pick a power seqeuncer and kick it. So let's skip the register read and the kick. Note that there's still a bit an issue about correctly recovering pps state from resume if the bios is nasty: With this check we'll always assume that the pps is off. But that's better done in a follow-up patch and it shouldn't be too harmful - at most we waste time enabling the pps if it's on already. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Add note about resume issues Imre spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Kick the power sequencer before AUX transactionsVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we pick a new power sequencer for the port but we're not doing a full modeset, the power sequencer may have locked on to another port (or no port). So kick it a bit to make sure it controls the port we want. Again just like when we attempt to actually enable the DP port, we must first write the port register with the approriate value except the enable bit, and then we must enable the port to make the power sequencer happy. In this case since we don't want the port actually enabled we just toggle it on and immediately back off. Going forward the power sequencer will keep working on that specific port until again moved to another port. v2: Refine the kick procedure 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 eDP link training when switching pipes on VLV/CHVVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching from one pipe to another, the power sequencer of the new pipe seems to need a bit of kicking to lock into the port. Even the vdd force bit doesn't work before the power sequencer has been sufficiently kicked, so this must be done before any AUX transactions are attempted. After extensive experimentation I've determined that it's sufficient to first write the port register with the correct values except the port must remain disabled, then we can do a second write to enable the port, after which the power sequencer is operational and allows the port to start up properly. Contrary to my earlier theories we don't need to enable the port with the idle pattern, so let's just use training pattern 1 as that's what other platforms use here. v2: Refine the kick procedure 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: Wait for PHY port ready before link training on VLV/CHVVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no point in checking if the data lanes came out of reset after link training. If the data lanes aren't ready link training will fail anyway. Suggested-by: Todd Previte <tprevite@gmail.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Hold the pps mutex across the whole panel power enable sequenceVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just grab the pps_mutex once and do all the pps panel startup operations while holding the mutex instead of grabbing the mutex separately for each individual step. 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: Split power sequencer panel on/off functions to locked and ↵Ville Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unlocked variants We'll be needing to the call the power seqeuencer functions while already holding pps_mutex, so split the locking out to small wrapper functions. 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 initialize power seqeuencer delays more than onceVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we read the current power seqeuncer delays from the registers (as well as looking at the vbt and spec values) we may end up corrupting delays we already initialized when we switch to another pipe and the power seqeuncer there has different values currently in the registers. So make sure we only initialize the delays once even if intel_dp_init_panel_power_sequencer() gets called multiple times. There was some discussion in the review about when exactly we need to unlock the pps. Quoting Bspec: "If this bit is not a zero, it activates the register write protect and writes to those registers will be ignored unless the write protect key value is set in the panel sequencing control register." Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Add Bspec quote per review discussion between Imre and Ville.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Store power sequencer delays in intel_dpVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The power seqeuncer delays are fixed for a given panel, so we can keep them around once computed. Not that on VLV/CHV we still re-compute them every time we initialize the power seqeuncer registers, but that will change soon enough. 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: Remove high level intel_edp_vdd_{on, off}() from hpd/detectVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | want_panel_vdd is a bool so it can't cope with interleaving on/off calls from multiple threads. If we want to make that possible we'd need to convert want_panel_vdd into a proper ref count. But an easier fix is to remove the high level vdd on/off calls from detect/hpd code paths and just rely on the delayed vdd off to avoid needless vdd on<->off ping pong. After this change only the encoder enable/disable paths use the high level functions, which is fine since both the on and off low level edp vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in between and so want_panel_vdd can't change in between. 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: Warn if trying to register eDP on port != B/C on vlv/chvVille Syrjälä2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only ports B and C have the power sequencer and backlight controls, so complain if we ever try to register an eDP connector on some other port. 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: pass intel_encoder to intel_write_eldJani Nikula2014-11-04
| | | | | | | | | | | | | | | | | | | | | | | | Everything else can be derived from that. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | Merge tag 'v3.18-rc4' into drm-nextDave Airlie2014-11-12
|\ \ \ | |/ / |/| / | |/ | | backmerge to get vmwgfx locking changes into next as the conflict with per-plane locking.
| * drm/i915/dp: only use training pattern 3 on platforms that support itJani Nikula2014-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by: Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org (3.15+) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Ignore long hpds on eDP portsVille Syrjälä2014-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turning vdd on/off can generate a long hpd pulse on eDP ports. In order to handle hpd we would need to turn on vdd to perform aux transfers. This would lead to an endless cycle of "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." So ignore long hpd pulses on eDP ports. eDP panels should be physically tied to the machine anyway so they should not actually disappear and thus don't need long hpd handling. Short hpds are still needed for link re-train and whatnot so we can't just turn off the hpd interrupt entirely for eDP ports. Perhaps we could turn it off whenever the panel is disabled, but just ignoring the long hpd seems sufficient. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Do a dummy DPCD read before the actual readVille Syrjälä2014-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes we seem to get utter garbage from DPCD reads. The resulting buffer is filled with the same byte, and the operation completed without errors. My HP ZR24w monitor seems particularly susceptible to this problem once it's gone into a sleep mode. The issue seems to happen only for the first AUX message that wakes the sink up. But as the first AUX read we often do is the DPCD receiver cap it does wreak a bit of havoc with subsequent link training etc. when the receiver cap bw/lane/etc. information is garbage. A sufficient workaround seems to be to perform a single byte dummy read before reading the actual data. I suppose that just wakes up the sink sufficiently and we can just throw away the returned data in case it's crap. DP_DPCD_REV seems like a sufficiently safe location to read here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | Merge tag 'drm-intel-next-2014-10-03-no-ppgtt' of ↵Dave Airlie2014-10-27
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Ok, new attempt, this time around with full ppgtt disabled again. drm-intel-next-2014-10-03: - first batch of skl stage 1 enabling - fixes from Rodrigo to the PSR, fbc and sink crc code - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic interrupt enable/disable functions - smaller stuff all over drm-intel-next-2014-09-19: - bunch more i830M fixes from Ville - full ppgtt now again enabled by default - more ppgtt fixes from Michel Thierry and Chris Wilson - plane config work from Gustavo Padovan - spinlock clarifications - piles of smaller improvements all over, as usual * tag 'drm-intel-next-2014-10-03-no-ppgtt' of git://anongit.freedesktop.org/drm-intel: (114 commits) Revert "drm/i915: Enable full PPGTT on gen7" drm/i915: Update DRIVER_DATE to 20141003 drm/i915: Remove the duplicated logic between the two shrink phases drm/i915: kerneldoc for interrupt enable/disable functions drm/i915: Use dev_priv instead of dev in irq setup functions drm/i915: s/pm._irqs_disabled/pm.irqs_enabled/ drm/i915: Clear TX FIFO reset master override bits on chv drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv drm/i915: make sink_crc return -EIO on aux read/write failure drm/i915: Constify send buffer for intel_dp_aux_ch drm/i915: De-magic the PSR AUX message drm/i915: Reinstate error level message for non-simulated gpu hangs drm/i915: Kerneldoc for intel_runtime_pm.c drm/i915: Call runtime_pm_disable directly drm/i915: Move intel_display_set_init_power to intel_runtime_pm.c drm/i915: Bikeshed rpm functions name a bit. drm/i915: Extract intel_runtime_pm.c drm/i915: Remove intel_modeset_suspend_hw drm/i915: spelling fixes for frontbuffer tracking kerneldoc drm/i915: Tighting frontbuffer tracking around flips ...
| * drm/i915: Clear TX FIFO reset master override bits on chvVille Syrjälä2014-10-03
| | | | | | | | | | | | | | | | | | | | | | Clear the override bits to make sure the hardware manages the TX FIFO reset master on its own. v2: Squash with the earlier attempt at forcing the override bits Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chvVille Syrjälä2014-10-03
| | | | | | | | | | | | | | | | | | | | | | The register can house two different swing marging/deemph settings at once. However only one gets used based on some other bits. Make sure we set those bits correctly to make the hardware use the settings we provided. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make sink_crc return -EIO on aux read/write failureRodrigo Vivi2014-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though it's unliky, we should check each aux transaction not just the first one. Also commit ce31d9f4fc05964f6c0dd3a8661dc1a1d843a1e2 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Mon Sep 29 18:29:52 2014 -0400 drm/i915: preserve other DP_TEST_SINK bits. added a new aux transaction before the one which was checked. Fix this. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Constify send buffer for intel_dp_aux_chDaniel Vetter2014-10-02
| | | | | | | | | | | | | | Inspired by Ville constifying the send buffer for pach_aux. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: De-magic the PSR AUX messageVille Syrjälä2014-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use pack_aux() to construct the PSR exit DPMS D0 AUX message, and use the defines from dp_dp_helper.h to populate the message contents. v2: Use sizeof() for message size (Jani) Use a generic loop to write EDP_PSR_AUX_DATA registers Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Bikeshed rpm functions name a bit.Daniel Vetter2014-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | - fini goes with init, so call it intel_power_domains_fini. While at it shovel some of the fini code that leaked out of it back in. - give power_enabled functions the verb _is_ to make the meaning clearer. Also use a __ prefix instead of _unlocked to really discourage users. - rename runtime_pm_init/fini to enable/disable since that's what they do. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'topic/skl-stage1' into drm-intel-next-queuedDaniel Vetter2014-09-30
| |\ | | | | | | | | | | | | | | | | | | | | | SKL stage 1 patches still need polish so will likely miss the 3.18 merge window. We've decided to postpone to 3.19 so let's pull this in to make patch merging and conflict handling easier. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| | * drm/i915/skl: Provide a get_aux_send_ctl() vfunc for skylakeDamien Lespiau2014-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Skylake doesn't use the pre-charge field now, but, instead, we need to specify the total number of SYNC pulses for the SYNC phase (pre-charge + SYNC pattern pules). Let's use the default value (32) for that. v3: increase DP AUX TX timeout as 400us is not to be used on SKL apparently (Jesse). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/skl: Implement the get_aux_clock_divider() DP vfuncDamien Lespiau2014-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to provide a vfunc that will make the code in intel_dp_aux_ch() loop once to start the AUX transaction. The return value (clock divider) is unused on SKL, so just return 1. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/skl: Skylake moves AUX_CTL from PCH to CPUDamien Lespiau2014-09-24
| | | | | | | | | | | | | | | | | | | | | | | | So we can apply the old aux_ctl = dp_ctl + 0x10 rule again. Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-14 03:33:29 -0400