- 27 1月, 2015 9 次提交
-
-
由 Matt Roper 提交于
We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Calls have been added to invalidate/flush DRRS whenever invalidate/flush is called as part of frontbuffer tracking. Apart from calls as a result of GEM tracking to fb invalidate/flush, a call has been added to invalidate fb obj from crtc_page_flip as well. This is to track busyness through flip calls. The call to fb_obj_invalidate (in flip) is placed before queuing flip for this obj. drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if it was setup in drrs_enable(). This covers for the condition when DRRS is not supported. v2: Removing the call to invalidate_drrs from page_flip. This has not been tested on Android yet, but, in case DRRS transtions do not work as expected, check by adding back this call in page_flip. Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Calling enable/disable DRRS when enable/disable DDI are called. These functions are responsible for setup of drrs data (in enable) and reset of drrs (in disable). has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in the VBT. A check has been added for has_drrs in these functions, to make sure the functions go through only if DRRS will work on the platform with the attached panel. V2: [By Ram]: WARN_ON is used when intel_edp_drrs_enable() is called more than once [Rodrigo] Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Add DRRS work function to trigger a switch to low refresh rate, when no activity is detected on screen till 1 sec duration. v2: [By Ram]: drrs.dp also protected with drrs.mutex and worker function is renamed to intel_edp_drrs_downclock_work [Chris] Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Self-explanatory code is better code. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
The objective is to make this structure usable with the atomic helpers, so let's start with the rename. Patch generated with coccinelle: @@ @@ -struct intel_crtc_config { +struct intel_crtc_state { ... } @@ @@ -struct intel_crtc_config +struct intel_crtc_state v2: Completely generate the patch with cocci. (Ander) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Earlier, DRRS structures were specific to eDP (used only in intel_dp). Since DRRS can be extended to other internal display types (if the panel supports multiple RR), modifying structures to be part of drm_i915_private and have a provision to add display related structs like intel_dp. Also, aligning with frontbuffer tracking mechanism, the new structure contains data for busy frontbuffer bits. Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 1月, 2015 1 次提交
-
-
由 Andy Shevchenko 提交于
Instead of pushing each byte via stack the specifier allows to supply the pointer and length to dump buffers up to 64 bytes long. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 12月, 2014 2 次提交
-
-
由 Rob Clark 提交于
Many distro's have mechanism in place to collect and automatically file bugs for failed WARN()s. And since i915 has a lot of hw state sanity checks which result in WARN(), it generates quite a lot of noise which is somewhat disconcerting to the end user. Separate out the internal hw-is-in-the-state-I-expected checks into I915_STATE_WARN()s and allow configuration via i915.verbose_checks module param about whether this will generate a full blown stacktrace or just DRM_ERROR(). The new moduleparam defaults to true, so by default there is no change in behavior. And even when disabled, you will still get an error message logged. v2: paint the macro names blue, clarify that the default behavior remains the same as before Signed-off-by: NRob Clark <robdclark@gmail.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
After commit a18c0af1 uthor: Thierry Reding <treding@nvidia.com> Date: Wed Dec 10 11:38:49 2014 +0100 drm: Zero out DRM object memory upon cleanup we will use the eDP encoder during destroying it. Fix this by calling drm_encoder_cleanup() at a point when the encoder is not used any more. This caused a NULL pointer dereference in pps_lock(), I can't see that it caused any other problem. All the other encoders seem to call drm_encoder_cleanup() at a safe place. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 15 12月, 2014 1 次提交
-
-
由 Damien Lespiau 提交于
I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good chance to be working as well as prevous platforms. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 12月, 2014 3 次提交
-
-
由 Rodrigo Vivi 提交于
This patch is the last in series of VLV/CHV PSR, that finally enable PSR by adding it to HAS_PSR and calling the proper enable and disable functions on the right places. Although it is still disabled by default. v2: Rebase over intel_psr and merge Durgadoss's fixes. v3: Fix typo. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
This function was in use to check if PSR feature got enabled. However on HSW and BDW we currently force psr exit by disabling EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually returning the active/inactive state that is different from the enable/disable meaning and had the risk of false negative. But anyway this check with DRRS was dangerous, since DRRS could try to get enabled before PSR gets there. So let's just remove it for now. A proper synchronization mechanism must be implemented later probably using pipe config. Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Egbert Eich 提交于
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: NEgbert Eich <eich@suse.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 11月, 2014 1 次提交
-
-
由 Ville Syrjälä 提交于
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 773538e8 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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 19 11月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
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=84890Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 18 11月, 2014 3 次提交
-
-
由 Damien Lespiau 提交于
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: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Rodrigo Vivi 提交于
No functional change. Just making it public for use outside intel_dp.c Allowing split psr functions. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 11月, 2014 1 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 11月, 2014 3 次提交
-
-
由 Jani Nikula 提交于
As per spec, and similar to DDI. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Add support for disabling the audio codec on vlv/chv/gen5-7, similar to hsw/bdw. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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 bc76e320 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=85670Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Acked-by: NJani Nikula <jani.nikula@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 11月, 2014 15 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The pps timestamp initialization was accidentally lost on vlv/chv in commit a4a5d2f8 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: NImre Deak <imre.deak@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
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: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) [danvet: Appease checkpatch.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> [danvet: Summarize my discussion with Ville about dpms on/off issues.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Print the port name in the VDD/PPS debugs messages. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> [danvet: Add note about resume issues Imre spotted.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NTodd Previte <tprevite@gmail.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Acked-by: NTodd Previte <tprevite@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-