Eliminate a ton of pointless 'dev' variables in the DP code, and pass
around 'dev_priv' instead of 'dev'.
v2: Rebase
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152758.32257-1-ville.syrjala@linux.intel.com
No need to pass 'dev' or 'dev_priv' when the function already takes
'intel_dp'. Also let's prefer passing 'dev_priv' instead of 'dev'
when we have to pass one or the other.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-10-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Rather than digging through encoder->crtc and crtc->config in the
DPIO PHY functions, pass down the correct crtc state from the caller.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-6-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
drm_add_edid_modes() now fills in the ELD automatically, so the calls to
drm_edid_to_eld() are redundant. Remove them.
All the other places are obvious, but nv50 has detached
drm_edid_to_eld() from the drm_add_edid_modes() call.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0959ca02b983afc9e74dd9acd190ba6e25f21678.1509545641.git.jani.nikula@intel.com
Explicitly pass the crtc and connector states into the audio
code enable/disable hooks, and plumb them all the way down.
This gets rid of almost all crtc->config and encoder->crtc
uses. The one place where we still use them is
i915_audio_component_sync_audio_rate() since that gets called from
the audio driver and we don't have explicit states around then.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171030184654.17429-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we can't
really trust that that current value of encoder->type actually matches
the type of signal we're trying to drive through it.
Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and
there's a bunch of code that relies on that value to identify eDP
encoders.
We'll introduce a new encoder .compute_output_type() hook. This allows
us to compute the full output_types before any encoder .compute_config()
hooks get called, thus those hooks can rely on output_types being
correct, which is useful for cloning on oldr platforms. For now we'll
just look at the connector type and pick the correct mode based on that.
In the future the new hook could be used to implement dynamic switching
between LS and PCON modes for LSPCON.
v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg
v4: Rebase
v5: Populate output_types in .get_config() rather than in the caller
v5: Split out populating output_types in .get_config() (Maarten)
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-3-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Rather than having the caller of .get_config() set output_types based on
encoder->type, let's just have .get_config() itself populate
output_types. This way we are isolated from encoder->type, which won't
be useable for this purpose anyway soon (at least for DDI encoders).
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
check the bit before reading the registers, and DP_EDP_DPCD_REV is the
only way to detect eDP revision.
Turns out there are (likely buggy) displays that require eDP 1.4+
features, such as supported link rates and link rate select, but do not
have the bit set. Read the display control registers
unconditionally. They are supposed to read zero anyway if they are not
supported, so there should be no harm in this.
This fixes the referenced bug by enabling the eDP version check, and
thus reading of the supported link rates. The panel in question has 0 in
DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
supported link rates method we default to RBR which is insufficient for
the panel native mode. As a curiosity, the panel also has a bogus value
of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
(which is 0x03).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
Reported-and-tested-by: Nicolas P. <issun.artiste@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com
(cherry picked from commit 0501a3b0eb)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
DP dongles may signal downstream HPD via short HPD pulses. Setting the
sink to DPMS off apparently kills the downstream HPD (at least on my
DP->VGA dongle), so skip the DPMS off for such dongles when we turn
off the port.
v2: Deal with DDI as well by moving the check into
intel_dp_sink_dpms() (Dhinakaran)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Pablo <pablodebiase@nanalysis.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103472
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99114
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027094523.9317-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
DP_EDP_CONFIGURATION_CAP should be set if the eDP display control
registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we
check the bit before reading the registers, and DP_EDP_DPCD_REV is the
only way to detect eDP revision.
Turns out there are (likely buggy) displays that require eDP 1.4+
features, such as supported link rates and link rate select, but do not
have the bit set. Read the display control registers
unconditionally. They are supposed to read zero anyway if they are not
supported, so there should be no harm in this.
This fixes the referenced bug by enabling the eDP version check, and
thus reading of the supported link rates. The panel in question has 0 in
DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the
supported link rates method we default to RBR which is insufficient for
the panel native mode. As a curiosity, the panel also has a bogus value
of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14
(which is 0x03).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400
Reported-and-tested-by: Nicolas P. <issun.artiste@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171026142932.17737-1-jani.nikula@intel.com
Make BXT less special by following the CNL approach and handling
it in intel_ddi_dp_voltage_max() alognside every other DDI platform.
v2: Clean up the argument types to bxt_ddi_vswing_sequence() while at it
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-6-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Per BSpec, 400us is "BDW+ Do not use this setting." - not just PORT_A.
Set BDW to 600us unconditionally.
v2:
-Split in to two patches (Rodrigo)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012213037.4245-2-james.ausmus@intel.com
Rename DP_AUX_CH_CTL_TIME_OUT_1600us to DP_AUX_CH_CTL_TIME_OUT_MAX, as
the meaning of the (3 << 26) value varies per platform, but it's always the
maximum timeout for that platform. Pre-CNL it means 1600us, and for CNL
it means 3200us.
v2:
-Split in to two patches (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012213037.4245-1-james.ausmus@intel.com
Add the minimal amount of PSR tracking into the crtc state. This allows
precomputing the possibility of using PSR correctly, and it means we can
safely call the psr enable/disable functions for any DP endcoder.
As a nice bonus we get rid of some more crtc->config usage, which we
want to kill off eventually.
v2: Fix 'goto unlock' fail in intel_psr_enable() (Jani)
Check intel_dp_is_edp() in is_edp_psr() (Jani)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012130201.21318-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Turn intel_dp_source_supports_hbr2() into a simple helper to query the
pre-filled source rates array, and move the conditions about which
platforms support which rates to the single point of truth in
intel_dp_set_source_rates().
This also reduces the code paths you have to think about in the source
rates initialization in intel_dp_set_source_rates(), making it easier to
grasp.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171009092959.29021-2-jani.nikula@intel.com
For this specific PCI device, the eDP panel requires a higher panel
power cycle delay of 1300ms where the minimum spec requirement of panel
power cycle delay is 500ms. This fix in combination with correct
timestamp at which we get the panel power off time fixes the dP AUX CH
timeouts seen on various IGT tests.
Fixes: c99a259b4b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507073845-13420-2-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit c02b8fb407)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Kernel stores the time in jiffies at which the eDP panel is turned
off. This should be obtained after the panel is off (after the
wait_panel_off). When we next attempt to turn the panel on, we use the
difference between the timestamp at which we want to turn the panel on
and timestamp at which panel was turned off to ensure that this is equal
to panel power cycle delay and if not we wait for the remaining
time. Not waiting for the panel power cycle delay can cause the panel to
not turn on giving rise to AUX timeouts for the attempted AUX
transactions.
v2:
* Separate lines for bugzilla (Jani Nikula)
* Suggested by tag (Daniel Vetter)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507135706-17147-1-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit cbacf02e77)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
For this specific PCI device, the eDP panel requires a higher panel
power cycle delay of 1300ms where the minimum spec requirement of panel
power cycle delay is 500ms. This fix in combination with correct
timestamp at which we get the panel power off time fixes the dP AUX CH
timeouts seen on various IGT tests.
Fixes: c99a259b4b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507073845-13420-2-git-send-email-manasi.d.navare@intel.com
Kernel stores the time in jiffies at which the eDP panel is turned
off. This should be obtained after the panel is off (after the
wait_panel_off). When we next attempt to turn the panel on, we use the
difference between the timestamp at which we want to turn the panel on
and timestamp at which panel was turned off to ensure that this is equal
to panel power cycle delay and if not we wait for the remaining
time. Not waiting for the panel power cycle delay can cause the panel to
not turn on giving rise to AUX timeouts for the attempted AUX
transactions.
v2:
* Separate lines for bugzilla (Jani Nikula)
* Suggested by tag (Daniel Vetter)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507135706-17147-1-git-send-email-manasi.d.navare@intel.com
We already print training pattern used during link training and also
print if the source or sink does not support TPS3 for HBR2 link rates,
see intel_dp_training_pattern().
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170918222141.4674-5-dhinakaran.pandiyan@intel.com
Our global struct with params is named exactly the same way
as new preferred name for the drm_i915_private function parameter.
To avoid such name reuse lets use different name for the global.
v5: pure rename
v6: fix
Credits-to: Coccinelle
@@
identifier n;
@@
(
- i915.n
+ i915_modparams.n
)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
Most of our DP encoder hooks are split into per-platform variants.
.disable() an exception, and thus it's a bit messy. Let's split it
up as well. We'll leave the common parts in a helper called by
each platform specific hook. Now each platform has mostly its own
hooks. Some hooks are still shared between vlv and chv, and between
g4x and ilk. None of the remaining shared hooks have any platform
checks in them however so duplicating them doesn't seem particularly
useful.
There is a subtle change on VLV/CHV where we now disable PSR before
audio, whereas before we disabled PSR after audio. That should be
totally fine, and PSR is disabled by default anyway. Jani also pointed
out to me that PSR + audio doesn't seem like a particularly realistic
combination.
v2: Drop the PSR HAS_DDI check here (Rodrigo)
Pimp up the commit message a bit based on a chat with Jani
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170920151251.5961-1-ville.syrjala@linux.intel.com
It is safe to call intel_psr_disable() on a platform without PSR. We
don't have such a check when calling intel_psr_enable() either.
v2: Don't drop the HAS_DDI check quite yet (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170920151236.5864-1-ville.syrjala@linux.intel.com
Some platforms do not support PSR and DRRS simultaneously.
Visual artifacts and flickering were reported on BDW HP Spectre
x360 Convertible. Deferring to PSR when both PSR and DRRS are
supported by the panel.
V2: Minor code-style changes suggested by Rodrigo
V3: Add a WARN_ON during PSR init suggested by Dhinakaran
Correct debug message,title suggested by Jani
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101111
Cc: Nicholas Stommel <nicholas.stommel@gmail.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170914181641.24393-1-radhakrishna.sripada@intel.com
This patch fixes the DP AUX CH timeouts observed during CI runs causing
CI Failures on a specific PCI device. This issue was fixed previously
by adding a quirk but looks like we need to increase this delay even more
in order to get rid all the DP AUX CH timeouts.
Fixes: c99a259b4b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502823591-25310-1-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit e8f345e08d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This patch fixes the DP AUX CH timeouts observed during CI runs causing
CI Failures on a specific PCI device. This issue was fixed previously
by adding a quirk but looks like we need to increase this delay even more
in order to get rid all the DP AUX CH timeouts.
Fixes: c99a259b4b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502823591-25310-1-git-send-email-manasi.d.navare@intel.com
Let's decouple bxt, glk and cnl dp signal levels
from other DDIs to avoid confusion.
No functional change. Only a reorg to avoid messing
with currently working DP signal levels when
moving voltage swing sequences around to match spec.
v2: ddi_signal_levels is also called from other ddi
platforms, so don't remove IS_GEN9_BC check from
skl_ddi_set_iboos. (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-2-rodrigo.vivi@intel.com
The enable/disable/etc. encoder hooks aren't supposed to alter the
state(s), so pass them as const. Unfortunately C lacks any kind of deep
const thingy, so this can't catch all abuses. But at least it acts as a
hint to the reader telling them not to mess about with the state(s).
v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well
v3: Deal with intel_sdvo_connector_state
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-9-ville.syrjala@linux.intel.com
The PSR enable/disable need to know things about the crtc state, so
plumb it through. This will become even more important when we start
to reuse the generic infoframe code for the VSC DIP programming as the
infoframe code wants the crtc state as well.
v2: Fix kernel docs
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-7-ville.syrjala@linux.intel.com
DP ports may want to use the video DIP for SDP transmission, so let's
initialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-6-ville.syrjala@linux.intel.com
Emphasize that this is based on the port, not intel_dp. This is also in
line with the underlying intel_bios_is_port_edp() function. No
functional changes.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818093020.19160-1-jani.nikula@intel.com
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow the use of the alternate mode if it's
available and it was specifically requested.
v2 and v3: Rebase
v4: * Fix up some leaky mode stuff (Chris)
* Rebase
v5: * Fix a NULL pointer derefrence (David Weinehall)
v6: * Whitespace / spelling / checkpatch clean-up; no functional
change. (David)
* Rebase
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.bride@linux.intel.com
Validate the compliance test link parameters when the compliance
test dpcd registers are read. Also validate them in compute_config
before using them since the max values might have been reduced
due to link training fallback.
If either the link rate or lane count is invalid, we still bail
from using the test parameters since the combination would not work
and instead use the fallback values.
v2:
* Added commit message to explain why we still bail when either of
of the params is invalid (Ville Syrjala)
* Add reason for validating in the comment (Jani Nikula)
* Also check if index >= 0 after validating (Jani Nikula)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-2-git-send-email-manasi.d.navare@intel.com
This function now takes the link rate and lane ocunt to be validated
as an argument so that this can be used for validating even the
compliance test link parameters.
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-1-git-send-email-manasi.d.navare@intel.com
The idea is to have an unique place to decide the pin-port
per platform.
So let's create this function now without any functional
change. Just adding together code from hdmi and dp together.
v2: Add missing pin for port A.
v3: Fix typo on subject.
Avoid behaviour change so add WARN_ON and return
if port A on HDMI. (by DK).
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811182650.14327-2-rodrigo.vivi@intel.com
We will soon need to make that pin port association per
platform, so let's try to simplify it beforehand.
Also we are moving the backwards port to pin
here as well so let's use a standardized way.
One extra possibility here would be to add a
MISSING_CASE along with PORT_NONE, but I don't want
to change this behaviour for now.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811182650.14327-1-rodrigo.vivi@intel.com
"Frequencies over 5.4 GHz only supported on certain
DDI ports and SKUs, and requires Vccio >= 0.95V."
More specifically, for current CNL SKUs available
(CNL-U and CNL-Y) we have:
DDI A - 5.4G eDP
DDI B - 8.1G DP
DDI C - 8.1G DP
DDI D - 5.4G DP
v2: Rebase on top of source_rates changes.
v3: Address the max 5.4 x 8.1 per DDI and also consider vccio.
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170810224008.15571-1-rodrigo.vivi@intel.com
It's dead code, the core handles all this directly now.
The only special case is nouveau and tda988x which used one function
for both legacy modeset code and -nv50 atomic world instead of 2
vtables. But amounts to exactly the same.
v2: Rebase over the panel/brideg refactorings in stm/ltdc.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Peter Senna Tschudin <peter.senna@collabora.com>
Cc: Martin Donnelly <martin.donnelly@ge.com>
Cc: Martyn Welch <martyn.welch@collabora.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Carlo Caione <carlo@caione.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Yakir Yang <kuankuan.y@gmail.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Romain Perier <romain.perier@collabora.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Hai Li <hali@codeaurora.org>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-tegra@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: zain wang <wzz@rock-chips.com>
Cc: Baoyou Xie <baoyou.xie@linaro.org>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-8-daniel.vetter@ffwll.ch
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Archit Taneja <architt@codeaurora.org>
Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm)
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Vincent Abriou <vincent.abriou@st.com>
It's dead code, the core handles all this directly now. This also
allows us to unexport drm_atomic_helper_connector_set_property.
The only special case is nouveau which used one function for both
pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2
vtables. But amounts to exactly the same.
What is rather strange here is how few drivers set this up, I suspect
the earlier patch to handle properties in the core did end up fixing a
pile of possible issues.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-7-daniel.vetter@ffwll.ch
Acked-by: Vincent Abriou <vincent.abriou@st.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZYseIAAoJEAx081l5xIa+85kP/0zKzKKVzZXSXG2TAGb5jNfk
Ex+TELG8tWk9KBxA7lEE5c0WEsnP79cNoXZLQu8wlUzO8+kwQK5Bz0zgNUkpSuo1
RthwdsxBQX1++UxB+HoSG+dOa7hkKVqlgQR3z9qyhsBXzetkJV0DoYcpMV0A1EWd
6Jzt+AvCShVkcW+21LqHPlc5EIVewrDMoA3oU6aYCLhyAOUTVvvQB2ML8YApH7TM
JrSrzCFHTrQEBbGUrZQhzR0sZzZzk9byntb/I/mdVbHeCyIHiL8sC4PfWSOyyazm
GkPnA8G3aFAY9haBRz9jG/VBr1yVb0mCBjkWQ1lGfIAOCDDSc+d7PDXdG+i4AewK
jZheXlrDIdGgmJLy4W3rdEqJvdf7UQHZOs8594OL19l4+FxCTrol1JSHSMeavCvr
8bUNil9Jb/ONU/wmp+q55U0k4TCTyerUA7gKnuaJAwBvd4n78/PKmQnbrWinDyJc
GQXp6zESk9bKt5DXSnVZuVf4POTzpuAsQkkfX1V2y145EHTQYfS3jLENWqEjyZUy
QtKCHZvRkJfGaFU4Pr+vBo9Iu1GlA5OiOv08QadldTT4OxUI0T6yaLDobHCQfKPE
sc3wCuCM+/dAnqoKDcGC4hAmF8zDdO0kw65P2m7uC6T9Jm1G35CioKbzo+fzUhuL
fg5TBpbp2Wwe2oPA5iBm
=2S5N
-----END PGP SIGNATURE-----
Merge tag 'drm-for-v4.13' into drm-intel-next-queued
Resync with the main drm-next pull request for 4.13. What we really
need is to fully resync with pending drm-misc, but that's not yet
possible due to the still ongoing merge window.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now the VBT.seq->t11_t12 value adds 100ms to both Gen9_LP
as well as non Gen9_LP cases so no need to special case
and do -1 during HW readout and +1 during pp_div write
for Gen9_LP/CNP case.
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498504905-21067-2-git-send-email-manasi.d.navare@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
When we read the VBT t11_t12 value for panel power cycle delay,
it is a zero based value so we need to 100ms to that. And then it
needs to be multiplied by 10 to store it in 100usecs unit same as
SW VBT.
v3:
* Add it as part of series
v2:
* Change the VBT value instead of HW readout and pp div (Ville Syrjala)
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1498504905-21067-1-git-send-email-manasi.d.navare@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Final pile of features for 4.13
New uabi:
- batch bo in first slot, for faster execbuf assembly in userspace
(Chris Wilson)
- (sub)slice getparam, needed for mesa perf support (Robert Bragg)
First pile of patches for cnl/cfl support, maintained by Rodrigo but
with lots of contributions from others. Still incomplete since public
review still ongoing.
Features/refactoring:
- Make execbuf faster (Chris Wilson), a pile of series to make execbuf
buffer handling have fewer passes, use less list walking, postpone
more work to async workers and shuffle buffers less, all to make the
common case much faster (in some cases at least).
- cold boot support for glk dsi (Madhav Chauhan)
- Clean up pipe A quirk and related old platform hacks (Ville)
- perf sampling support for kbl/glk (Lionel)
- perf cleanups (Robert Bragg)
- wire atomic state to backlight code, to avoid pipe lookup hacks
(Maarten)
- reduce request waiting latency/overhead to remove the spinning and
associated cpu cycle wasting (Chris)
- fix 90/270 rotation wm computation (Ville)
- new ddb allocation algo for skl (Kumar Mahesh)
- fix regression due to system suspend optimiazatino (Imre)
- the usual pile of small cleanups and refactors all over
GVT updates contained in this tag:
- optimization for per-VM mmio save/restore (Changbin)
- optimization for mmio hash table (Changbin)
- scheduler optimization with event (Ping)
- vGPU reset refinement (Fred)
- other misc refactor and cleanups, etc.
* tag 'drm-intel-next-2017-06-19' of git://anongit.freedesktop.org/git/drm-intel: (170 commits)
drm/i915: Update DRIVER_DATE to 20170619
drm/i915/cfl: Introduce Coffee Lake workarounds.
drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH
drm/i915: Stash a pointer to the obj's resv in the vma
drm/i915: Async GPU relocation processing
drm/i915: Allow execbuffer to use the first object as the batch
drm/i915: Wait upon userptr get-user-pages within execbuffer
drm/i915: First try the previous execbuffer location
drm/i915: Store a persistent reference for an object in the execbuffer cache
drm/i915: Eliminate lots of iterations over the execobjects array
drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations
drm/i915: Pass vma to relocate entry
drm/i915: Store a direct lookup from object handle to vma
drm/i915: Fix retrieval of hangcheck stats
drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty
drm/i915: Mark CPU cache as dirty on every transition for CPU writes
drm/i915: Make i915_vma_destroy() static
drm/i915: Actually attach the tv_format property to the SDVO connector
Revert "drm/i915/skl: New ddb allocation algorithm"
drm/i915/glk: Add cold boot sequence for GLK DSI
...
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJZPdbLAAoJEHm+PkMAQRiGx4wH/1nCjfnl6fE8oJ24/1gEAOUh
biFdqJkYZmlLYHVtYfLm4Ueg4adJdg0wx6qM/4RaAzmQVvLfDV34bc1qBf1+P95G
kVF+osWyXrZo5cTwkwapHW/KNu4VJwAx2D1wrlxKDVG5AOrULH1pYOYGOpApEkZU
4N+q5+M0ce0GJpqtUZX+UnI33ygjdDbBxXoFKsr24B7eA0ouGbAJ7dC88WcaETL+
2/7tT01SvDMo0jBSV0WIqlgXwZ5gp3yPGnklC3F4159Yze6VFrzHMKS/UpPF8o8E
W9EbuzwxsKyXUifX2GY348L1f+47glen/1sedbuKnFhP6E9aqUQQJXvEO7ueQl4=
=m2Gx
-----END PGP SIGNATURE-----
BackMerge tag 'v4.12-rc5' into drm-next
Linux 4.12-rc5 for nouveau fixes
This is an important part of the DDI initalization as well as
for changing the voltage during DisplayPort link training.
This new sequence for Cannonlake is more like Broxton style
but still with different registers, different table and
different steps.
v2: Do not write to DW4_GRP to avoid overwrite individual loadgen.
Fix PORT_CL_DW5 SUS Clock Config set.
v3: As previous platforms use only eDP table if low voltage was
requested.
v4: fix Werror:maybe uninitialized (Paulo)
v5: Rebase on top of dw2_swing_sel changes
on previous patches.
v6: Using flexible SCALING_MODE_SEL(x).
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-11-git-send-email-rodrigo.vivi@intel.com
Panel Power sequences for CNP is similar to Broxton,
but with only one sequencer.
Main difference from SPT is that PP_DIVISOR was removed
and power cycle delay has been moved to PP_CONTROL.
v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4]
as on Broxton. (Found by DK)
v3: Improve commit message. (By DK)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1496434004-29812-6-git-send-email-rodrigo.vivi@intel.com
intel_dp supports 3 properties, scaling mode, broadcast rgb and
force_audio. intel_digital_connector handles the plumbing,
so we only have to hook this up in compute_config and init.
Changes since v1:
- Remove limited_color_range too, unused. (danvet)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-10-maarten.lankhorst@linux.intel.com
None of the intel connectors can use all types of scaling modes,
so only try the ones that are possible. This is another preparation
for connectors towards conversion to atomic.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-5-maarten.lankhorst@linux.intel.com
[mlankhorst: Use renamed drm_connector_attach_scaling_mode_property function]
The first step in converting connector properties to atomic is
wiring up the atomic state. We're still not completely supoprting
the scaling mode in the atomic case, but this is the first step
towards it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170501133804.8116-4-maarten.lankhorst@linux.intel.com
The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. We tried to reduce the M/N values for
all devices in commit 9a86cda07a ("drm/i915/dp: reduce link M/N
parameters"), but that regressed some other sinks. Detect this IC by its
OUI value of 0x0022B9 via the DPCD quirk list, and only reduce the M/N
values for that.
v2 by Jani: Rebased on the DP quirk database
v3 by Jani: Rebased on the reworked DP quirk database
v4 by Jani: Improve commit message (Daniel)
Fixes: 9a86cda07a ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2d2e30f8f47d3f28c9b74ca2612336a54585c3ec.1495105635.git.jani.nikula@intel.com
Switch to using the common DP helpers instead of using our own.
v2: also remove leftover struct intel_dp_desc (Daniel)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The assumptions of these users of drm_dp_dpcd_readb() is that the passed
in output buffer won't change in case of error, but this isn't
guaranteed. Fix this by treating any error as the lack of the given
capability.
In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
buffer uninitialized even with the above assumption.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1494408113-379-2-git-send-email-imre.deak@intel.com
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.
To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37b
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.
v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
s/apparely/apparently/ in the comment (Chris)
Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
(cherry picked from commit 1a36147bb9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.
This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.
This patch is a resend of the original commit id (233ce881dd
"drm/i915: Implement Link Rate fallback on Link training failure")
which got reverted in this commit id (afc1ebf456 Revert
"drm/i915: Implement Link Rate fallback on Link training failure")
due to CI failures.
After investigating the CI failures it was found that these
were essentially the failures which were always there but hidden because
they used to be DRM_DEBUG_KMS messages for link failures so never got
caught by CI. But now this patch actually throws DRM_ERROR if the link
training fails at RBR and 1 lane. So it caught these link train failures.
There were two failures:
1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
without eDP on Port A. But our VBT initialization code in the driver writes
VBT defaults in a way that it always sets DP flag on Port A and this does
not get cleared after parsing the VBT outputs. This has been fixed in
commit id (bb1d132935 "drm/i915/vbt: split out defaults that are set
when there is no VBT) and (665788572c "drm/i915/vbt: don't propagate
errors from intel_bios_init())
2. On ILK-650 desktop - This was happening because of a bad monitor desktop
combination. I switched the monitor in the CI lab and that helped get rid
of the link failures on ILK system.
v10:
* Rebase on drm-tip and resend after revert
v9:
* Use the trimmed max values of link rate/lane count based on
link train fallback (Daniel Vetter)
v8:
* Set link_status to BAD first and then call mode_valid (Jani Nikula)
v7:
Remove the redundant variable in previous patch itself
v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <Harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.
To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37b
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.
v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
s/apparely/apparently/ in the comment (Chris)
Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
during previous modeset. Or these values can get stale since we have
now re read the DPCD registers or it can be 0 in case of connected boot
case.
This patch validates these values against the max link rate and max lane
count values.
This is absolutely required incase the common_rates or max lane count
are now different due to link fallback.
v2:
* Include the FIXME commnet inside the function (Ville Syrjala)
* Remove the redundant parenthesis (Ville Syrjala)
v3 by Jani:
* rebase on the DP refactoring series
* rename intel_dp_link_params_is_valid to intel_dp_link_params_valid
* minor stylistic changes
v4:
* Compare the link rate against max link rate not the
common_rates since common_rates does not account for the
lowered fallback link rate value. (Ville Syrjala)
v5:
* Fixed a warning for unused variable (Manasi)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491512412-30016-1-git-send-email-manasi.d.navare@intel.com
Those properties are not hooked up on MST and were ignored. Best not expose them at all.
Without this the next patch fails to start on X.org, because the DP-MST properties could
not be read.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/751b85a0-81cd-09e2-9e60-6d4ddbf1c6ac@linux.intel.com
Testcase: kms_properties
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Maarten needs both the new connector->atomic_check hook and the
connection_mutex locking changes in the probe helpers to be able to
start merging the connector property conversion to atomic.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The source might not support as many lanes as the sink, or the link
training might have failed at higher lane counts. Take these into
account.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cf59530acafaf9258fb643d321ad251b44f34e29.1491485983.git.jani.nikula@intel.com
These are the theoretical maximums common for source and sink. These are
the maximums we should start with. They may be degraded in case of link
training failures, and the dynamic link values are stored separately.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/5088aca253c47dfa18251e1adb976aca1718f083.1491485983.git.jani.nikula@intel.com
If we modify these on the fly depending on the link conditions, don't
pretend they are sink properties.
Some link vs. sink confusion still remains, but we'll take care of them
in follow-up patches.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/3739b4fac502ebd1c6e075a62c1a195e4094eb16.1491485983.git.jani.nikula@intel.com
In link training fallback, we're trying to find a rate that we know is
in a sorted array of common link rates. We don't need to limit the array
using the max rate. For test request, the DP CTS doesn't say we should
limit the rate based on earlier fallback. This lets us get rid of
intel_dp_link_rate_index() and use intel_dp_rate_index() instead.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/33cab481a3228f31e938b5891a6285d892dcf272.1491485983.git.jani.nikula@intel.com
Now that source rates are static and sink rates are updated whenever
DPCD is updated, we can do and cache the intersection of them whenever
sink rates are updated. This reduces code complexity, as we don't have
to keep calling the functions to intersect. We also get rid of several
common rates arrays on stack.
Limiting the common rates by a max link rate can be done by picking the
first N elements of the cached common rates.
v2: get rid of the local common_rates variable (Manasi)
v3: don't clobber cached eDP rates on short pulse (Ville)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/e3b287e8cb6559b1f8fd4e80b78a8d22f1802eb7.1491485983.git.jani.nikula@intel.com
Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
which is allowed to use link rate select method and have 0 in max link
rate. With this change, it makes sense to store the max rate as the
actual rate rather than as a bw code.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/3e8baadb406d59f414cab36fed9f0b35d207fde5.1491485983.git.jani.nikula@intel.com
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.
Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.
This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.
Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com
There is some conflation related to sink rates, making this change more
complicated than it would otherwise have to be. There are three changes
here that are rather difficult to split up:
1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We
initialize it from DPCD on eDP 1.4 like before, but generate it based
on DP_MAX_LINK_RATE on others. This reduces code complexity when we
need to use the sink rates; they are all always in the sink_rates
array.
2) Update the sink rate array whenever we read DPCD, and use the
information from there. This increases code readability when we need
the sink rates.
3) Disentangle fallback rate limiting from sink rates. In the code, the
max rate is a dynamic property of the *link*, not of the *sink*. Do
the limiting after intersecting the source and sink rates, which are
static properties of the devices.
This paves the way for follow-up refactoring that I've refrained from
doing here to keep this change as simple as it possibly can.
v2: introduce use_rate_select and handle non-confirming eDP (Ville)
v3: don't clobber cached eDP rates on short pulse (Ville)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
We need the source rates array so often that it makes sense to set it
once at init. This reduces function calls when we need the rates, making
the code easier to follow.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/aa998882d2b824f671272c60e9d26621ab9d2d17.1490712890.git.jani.nikula@intel.com
Rename the function, move it at the top, and reuse in
intel_dp_link_rate_index(). If there was a reason in the past to use
reverse search order here, there isn't now.
The names may be slightly confusing now, but intel_dp_link_rate_index()
will go away in follow-up patches.
v2: Use name intel_dp_rate_index (Dhinakaran)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/c7b6197aaa12e368a0d024dc142fa574fd0443a7.1490712890.git.jani.nikula@intel.com
We shouldn't silently use the first element if we can't find the rate
we're looking for. Make rate_to_index() more generally useful, and
fallback to the first element in the caller, with a big warning.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8a6e83b7bf35da0cbbc703ae157944107ff145be.1490712890.git.jani.nikula@intel.com
I can't think of a real world bug this could cause now, but this will be
required in follow-up work. While at it, change the parameter order to
be slightly more sensible.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/ff5b08f45a72c2247f5326b080027e2f5d8cc4ee.1490712890.git.jani.nikula@intel.com
At least a ParadTech PS175 LSPCON chip/firmware uses long instead of
short pulses to signal output unplug/plug events. This is contrary to
how branch devices normally work which use short HPD signaling. This
chip will also switch to LS mode after an unplug event, which could be
the consequence of the long HPD signaling semantics and an effort to
save power automatically. Because of this we'll fail to do AUX and
detect the output after a replug event.
To fix this make sure we are in PCON mode during connector detection.
v2:
- Switch the mode in the proper spot.
Cc: raptorteak@gmail.com
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912
Reported-and-tested-by: raptorteak@gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487776252-6288-1-git-send-email-imre.deak@intel.com
Rather than sprinkling ideas of how big the DDI buf translation tables
are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
where the actual tables are defined. To that end we introduce
intel_ddi_dp_voltage_max() which will actually look at the proper
translation table to determine what is the maximum voltage swing level
supported.
v2: Mask out the preemphasis bits from the return value of
intel_ddi_dp_voltage_max()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223174901.26749-1-ville.syrjala@linux.intel.com
This reverts commit 7ee686034b "drm/i915/dp: Ratelimit DP aux timeout
messages" as although it successfully squelches the debug messages, when
it does so it generates a warning instead. CI lights up orange with all
the warnings!
In its current incarnation DRM_DEBUG_RATELIMITED is not usable for us,
and we need to first teach lib/ratelimit.c not to warn when used for
debug messages.
Fixes: 7ee686034b ("drm/i915/dp: Ratelimit DP aux timeout messages")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lyude <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/20170223115102.7059-1-chris@chris-wilson.co.uk
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Right now this is just leaving a lot of spam in dmesg that makes real
issues more difficult to debug. As well (as noted by the comment right
above the DRM_DEBUG_KMS() call) this is normal behavior when there's
nothing connected to the DisplayPort connector.
Signed-off-by: Lyude <lyude@redhat.com>
The max link parameters should be set/reset only on HPD or
connected boot case or on system resume.
Add a flag reset_link_params to intel_dp to decide when
to reset the max link parameters. This prevents the parameters
from getting reset/overwritten through all other
connector->funcs->detect() calls. This is important when link
training fails and the max link params are modified to the
lower fallback values.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486515251-23469-1-git-send-email-manasi.d.navare@intel.com
Until recently vlv_steal_power_sequencer() wasn't being called for
normal DP ports, and hence it could assert that it should only be
called for pipe A and B (since pipe C doesn't support eDP). However
that changed when we started to consider normal DP ports as well when
choosing a PPS. So we will now get spurious warnings when
vlv_steal_power_sequencer() does get called for pipe C. Avoid this by
moving the WARN down into vlv_detach_power_sequencer() where this
assertion should still hold.
Cc: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Fixes: 9f2bdb006a ("drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV")
References: https://bugs.freedesktop.org/show_bug.cgi?id=95287
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170208175254.10958-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
This shaves a few lines from intel_dp_init_connector() and will serve as
a good place to add other port specific information in a follow up
patch.
While at it, convert BUG() to MISSING_CASE() in the default case.
v2: s/BUG/MISSING_CASE. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170203140316.20792-2-ander.conselvan.de.oliveira@intel.com
The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess.
So here I'm introducing the "actual" and "logical" naming for our
cdclk state. "actual" is what we'll bash into the hardware and "logical"
is what everyone should use for state computaion/checking and whatnot.
We'll track both using the intel_cdclk_state as both will need other
differing parameters than just the actual cdclk frequency.
While doing that we can at the same time unify the appearance of the
.modeset_calc_cdclk() implementations a little bit.
v2: Commit dev_priv->cdclk.actual since that already has the
new state by the time .modeset_commit_cdclk() is called.
v3: s/locical/logical/ and improve the docs a bit
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-9-ville.syrjala@linux.intel.com
Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returning the current cdclk frequency.
One immediate benefit is that calling .get_cdclk() will no longer
clobber state stored under dev_priv unless ex[plicitly told to do
so. Previously it clobbered the vco and reference clocks stored
there on some platforms.
We'll expand the use of this structure to actually precomputing the
state and whatnot later.
v2: Constify intel_cdclk_state_compare()
v3: Document intel_cdclk_state_compare()
v4: Deal with i945gm_get_cdclk()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207183345.19763-1-ville.syrjala@linux.intel.com
During system resume time initialization the HPD level on LSPCON ports
can stay low for an extended amount of time, leading to failed AUX
transfers and LSPCON initialization. Fix this by waiting for HPD to get
asserted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99178
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-3-git-send-email-imre.deak@intel.com
Chris Wilson wants the new fence tracepoint added in
commit 8c96c67801
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jan 24 11:57:58 2017 +0000
dma/fence: Export enable-signaling tracepoint for emission by drivers
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Another round of -misc stuff:
- Noralf debugfs cleanup cleanup (not yet everything, some more driver
patches awaiting acks).
- More doc work.
- edid/infoframe fixes from Ville.
- misc 1-patch fixes all over, as usual
Noralf needs this for his tinydrm pull request.
* tag 'drm-misc-next-2017-01-30' of git://anongit.freedesktop.org/git/drm-misc: (48 commits)
drm/vc4: Remove vc4_debugfs_cleanup()
dma/fence: Export enable-signaling tracepoint for emission by drivers
drm/tilcdc: Remove tilcdc_debugfs_cleanup()
drm/tegra: Remove tegra_debugfs_cleanup()
drm/sti: Remove drm_debugfs_remove_files() calls
drm/radeon: Remove drm_debugfs_remove_files() call
drm/omap: Remove omap_debugfs_cleanup()
drm/hdlcd: Remove hdlcd_debugfs_cleanup()
drm/etnaviv: Remove etnaviv_debugfs_cleanup()
drm/etnaviv: allow build with COMPILE_TEST
drm/amd/amdgpu: Remove drm_debugfs_remove_files() call
drm/prime: Clarify DMA-BUF/GEM Object lifetime
drm/ttm: Make sure BOs being swapped out are cacheable
drm/atomic: Remove drm_atomic_debugfs_cleanup()
drm: drm_minor_register(): Clean up debugfs on failure
drm: debugfs: Remove all files automatically on cleanup
drm/fourcc: add vivante tiled layout format modifiers
drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F
drm/edid: Set AVI infoframe Q even when QS=0
drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()
...
Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.
v2: s/adjusted_mode/mode in vc4 to make it actually compile
v3: Add a comment proposed by Eric
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.
When the test is requested with specific BPC value, we read the BPC
value from the DPCD register. If this BPC value in intel_dp structure
has a non-zero value and we're on a display port connector, then we use
the value to calculate the bpp for the pipe. Also in this case if its
a 18bpp video pattern request, then we force the dithering on pipe to be
disabled since it causes CRC mismatches.
The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.
v5:
* Remove test_result variable
* Populate the compliance test data at the end of the function (Jani Nikula)
v4:
*Return TEST_NAK on read failures and invalid values (Jani Nikula)
* Address CRC mismatch errors
v3:
* Use the updated properly shifted bit definitions (Jani Nikula)
* Force dithering to be disabled on 18bpp compliance
test request (Manasi Navare)
v2:
* Updated the DPCD Register reads based on proper defines in header (Jani Nikula)
* Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte<todd.previte@gmail.com>
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
v2:
* Added read debugfs data from test_data.edid if its EDID test (Jani NIkula)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484968170-12467-3-git-send-email-manasi.d.navare@intel.com
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is retrained and enabled for link parameters requested
by the test.
v5:
* Only modify the compliance structure after all validation
is done (Jani Nikula)
* Remove the variable test_result (Jani Nikula)
v4:
* Return TEST_NAK for read failures and invalid
values (Jani Nikula)
* Conver the test link BW to link rate before storing (Jani Nikula)
v3:
* Validate the test link rate and lane count as soon as
the request comes (Jani Nikula)
v2:
* Validate the test lane count before using it in
intel_dp_compute_config (Jani Nikula)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485274594-17361-1-git-send-email-manasi.d.navare@intel.com
Along with GLK it was introduced the .is_lp and IS_GEN9_LP.
So, following the same simplification standard we can
put Skylake and Kabylake under the same bucket for most
of the things.
So let's add the IS_GEN9_BC for "Big Core" (non Atom based
platforms).
The i915_drv.c was let out of this patch on purpose
because that is really a decision per platform, just like
other cases where IS_KABYLAKE is different from IS_SKYLAKE.
v2: fix conflict with IS_LP and 3 new cases for this
big core bucket:
- intel_ddi.c: intel_ddi_get_link_dpll
- intel_fbc.c: find_compression_threshold
- i915_gem_gtt.c: gtt_write_workarounds
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485196357-30599-2-git-send-email-rodrigo.vivi@intel.com
There is no point in setting intel_dp->compliance.test_type, and
proceeding with the autotests, if we're about to NAK the request. Some
drive-by cleanups while at it.
v2: look at the ACK bit, as the result may also contain
TEST_EDID_CHECKSUM_WRITE
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Tested-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484931846-25390-1-git-send-email-jani.nikula@intel.com
As per edp1.4 spec , alpm is required for psr2 operation as it's
used for all psr2 main link power down management and alpm enable
bit must be set for psr2 operation.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: vathsala nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: Patil Deepti <deepti.patil@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483356663-32668-6-git-send-email-vathsala.nagaraju@intel.com
Commit cc3f90f063 ("drm/i915/glk: Reuse broxton code for geminilake")
missed a few of occurences of IS_BROXTON() that should have been
coverted to IS_GEN9_LP().
v2: Cite the right commit. (Ander)
Fixes: cc3f90f063 ("drm/i915/glk: Reuse broxton code for geminilake")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> (v1)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483973495-15138-1-git-send-email-ander.conselvan.de.oliveira@intel.com
Apparently some VLV BIOSen like to leave the VDD force bit enabled
even for power seqeuncers that aren't properly hooked up to any
port. That will result in a imbalance in the AUX power domain
refcount when we stat to use said power sequencer as edp_panel_vdd_on()
will not grab the power domain reference if it sees that the VDD is
already on.
To fix this let's make sure we turn off the VDD force bit when we
initialize the power sequencer registers. That is, unless it's
being done from the init path since there we are actually
initializing the registers for the current power sequencer and
we don't want to turn VDD off needlessly as that would require
waiting for the power cycle delay before we turn it back on.
This fixes the following kind of warnings:
WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]()
WARN_ON(!power_domains->domain_use_count[domain])
...
v2: Fix typos in comment (David)
Cc: stable@vger.kernel.org
Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Tested-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161220165117.24801-1-ville.syrjala@linux.intel.com
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
There is at least one APL based system using port A in DP mode
(connecting to an on-board DP->VGA adaptor). Atm we'll configure port A
unconditionally as eDP which is incorrect in this case. Fix this by
relying on the VBT DDI port 'internal port' flag instead on all ports on
DDI platforms. For now chicken out from using VBT for port A before
GEN9.
v2:
- Move the DDI port info lookup to intel_bios_is_port_edp() (David, Jani)
- Use the DDI port info on all DDI platforms starting from port B.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482315444-24750-1-git-send-email-imre.deak@intel.com
VLV apparently gets upset if the PPS for a pipe currently driving an
external DP port gets used for VDD stuff on another eDP port. The DP
port falls over and fails to retrain when this happens, leaving the
user staring at a black screen.
Let's fix it by also tracking which pipe is driving which DP/eDP port.
We'll track this under intel_dp so that we'll share the protection
of the pps_mutex alongside the pps_pipe tracking, since the two
things are intimately related.
I had plans to reduce the protection of pps_mutex to cover only eDP
ports, but with this we can't do that. Well, for for VLV/CHV at least.
For other platforms it should still be possible, which would allow
AUX communication to occur in parallel for multiple DP ports.
v2: Drop stray crap from a comment (Imre)
Grab pps_mutex when clearing active_pipe
Fix a typo in the commit message
v3: Make vlv_active_pipe() static
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481738423-29738-1-git-send-email-ville.syrjala@linux.intel.com
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variables through a memset instead of
individual resetting.
v2:
* Removed functional changes for EDID (Jani Nikula)
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwl.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481329371-16306-1-git-send-email-manasi.d.navare@intel.com
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure and limits the max
link_rate and lane_count values to these fallback values.
v7:
* Remove unnecessary intializations and remove redundant
call to intel_dp_common_rates (Jani Nikula)
v6:
* Cap the max link rate and lane count to the max
values obtained during fallback link training (Daniel Vetter)
v5:
* Start the fallback at the lane count value passed not
the max lane count (Jani Nikula)
v4:
* Remove the redundant variable link_train_failed
v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481252712-12925-1-git-send-email-manasi.d.navare@intel.com
Sink's capabilities are advertised through DPCD registers and get
updated only on hotplug. So they should be computed only once in the
long pulse handler and saved off in intel_dp structure for the use
later. For this reason two new fields max_sink_lane_count and
max_sink_link_bw are added to intel_dp structure.
This also simplifies the fallback link rate/lane count logic
to handle link training failure. In that case, the max_sink_link_bw
and max_sink_lane_count can be reccomputed to match the fallback
values lowering the sink capabilities due to link train failure.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1480984058-552-3-git-send-email-manasi.d.navare@intel.com
Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.
So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a configuration.
v3: Renamed local variables again for consistency (Manasi)
v2: Renamed mode data rate local variable to be more explanatory.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479243546-17189-1-git-send-email-dhinakaran.pandiyan@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.
But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps
v2: Changed to DIV_ROUND_UP() and comment changes (Ville)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479160220-17794-1-git-send-email-dhinakaran.pandiyan@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Geminilake is mostly backwards compatible with broxton, so change most
of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
platforms will be implemented in follow-up patches.
v2: Don't reuse broxton's path in intel_update_max_cdclk().
Don't set plane count as in broxton.
v3: Rebase
v4: Include the check intel_bios_is_port_hpd_inverted().
Commit message.
v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
v6: Rebase.
v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll
code. (Rodrigo)
v8: Squash a couple of DDI patches with more conversions. (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-2-git-send-email-ander.conselvan.de.oliveira@intel.com
Pass dev_priv to intel_setup_outputs() and functions called by it, since
those are all intel i915 specific functions. Also, in the majority of
the functions dev_priv is used more often than dev. In the rare cases
where there are a few calls back into drm core, a local dev variable was
added.
v2: Don't convert dev to &dev_priv->drm in intel_dsi_init. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479910904-11005-1-git-send-email-ander.conselvan.de.oliveira@intel.com
Some LSPCON adaptors may return an incorrect LSPCON mode right after
waking from DP Sleep state. This is the case at least for the ParadTech
PS175 adaptor, both when waking because of exiting the DP Sleep to
active state, or due to any other AUX CH transfer. We can determine the
current expected mode based on whether the DPCD area is accessible,
since according to the LSPCON spec this area is only accesible
in PCON mode.
This wait will avoid us trying to change the mode, while the current
expected mode hasn't settled yet and start link training before the
adaptor thinks it's in PCON mode after waking from DP Sleep state.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-4-git-send-email-imre.deak@intel.com
And as usual a little bit of cascaded function prototype changes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
v2: Keep original order. (Ville Syrjala)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.
This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.
This also removes having to look at crtc->config.
Changes since v1:
- Use intel_crtc->pipe instead of drm_crtc_index. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-8-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.
v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477524358-16563-4-git-send-email-manasi.d.navare@intel.com
On my APL the LSPCON firmware resumes in PCON mode as opposed to the
expected LS mode. It also appears to be in a state where AUX DPCD reads
will succeed but return garbage recovering only after a few hundreds of
milliseconds. After the recovery time DPCD reads will result in the
correct values and things will continue to work. If I2C over AUX is
attempted during this recovery time (implying an AUX write transaction)
the firmware won't recover and will stay in this broken state.
As a workaround check if the firmware is in PCON state after resume and
if so wait until the correct DPCD values are returned. For this we
compare the branch descriptor with the one we cached during init time.
If the firmware was in the LS state, we skip the w/a and continue as
before.
v2:
- Use the DP descriptor value cached in intel_dp. (Jani)
- Get to intel_dp using container_of(), instead of a cached ptr.
(Shashank)
- Use usleep_range() instead of msleep().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98353
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-9-git-send-email-imre.deak@intel.com
As for external DP sink and branch devices read and print the DP
descriptor for eDP and LSPCON devices as well to aid debugging.
v2:
- Split out this change to a separate patch. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-7-git-send-email-imre.deak@intel.com
All types of DP devices (eDP, DP sink, DP branch) will fail their probe
if the start of DPCD can't be read. The LSPCON PCON functionality also
depends on accessing this area, so fail the probe if the read fails.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-6-git-send-email-imre.deak@intel.com
Extend the branch/sink descriptor info with the missing device ID
field. While at it also read out all the descriptor registers in one
transfer and make the debug print more compact.
v2: (Jani)
- Cache the descriptor in intel_dp.
- Split out this change into a separate patch.
v3: (Jani)
- Fix return value check of __intel_dp_read_desc().
- Use %pE instead of %s to print the device ID.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477401159-15098-1-git-send-email-imre.deak@intel.com
There are two separate sets of DPCD registers for the DP OUI - as well as
for the device ID and HW/SW revision - based on whether the given DP
device is a branch or a sink. Currently we print both branch and sink
OUIs, for consistency print only the one that corresponds to the
probed device.
v2:
- Split out this change into a separate patch. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-4-git-send-email-imre.deak@intel.com
Performing DPCD AUX reads based on debug settings may introduce obscure
bugs in other places that depend on the read being done (or being not
done). To reduce the uncertainty perform the reads unconditionally.
Cc: Mika Kahola <mika.kahola@intel.com>
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-3-git-send-email-imre.deak@intel.com
This check is open-coded in a few places, so it makes sense to simplify
things by having a helper for it similar to the rest of DPCD feature
helpers.
v2: (Jani)
- Move the helper to drm_dp_helper.h.
- Split out this change to a separate patch.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477326811-30431-2-git-send-email-imre.deak@intel.com
Once we've determined that the sink is MST capable we never end up
running through the full detect cycle again, despite getting HPDs.
Fix tht by ripping out the incorrect piece of code responsible.
This got broken when I moved the long HPD handling to the ->detect()
hook, but failed to remove the leftover code.
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Rui Tiago Matos <tiagomatos@gmail.com>
Tested-by: Rui Tiago Matos <tiagomatos@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98323
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
References: https://bugs.freedesktop.org/show_bug.cgi?id=98306
Fixes: 27d4efc559 ("drm/i915: Move long hpd handling into the hotplug work")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477057478-29328-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link training' message. This can be observed during
intel_dp_long_pulse where we can do the link training step, but before
we have had a chance to set the link params. To avoid this we add an
extra check for the lane_count in intel_dp_check_link_status, which
should prevent us from doing the link training step prematurely.
v2: add WARN_ON_ONCE and FIXME comment (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476912593-10019-1-git-send-email-matthew.auld@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The VBT provides the platform a way to mix and match the DDI ports vs.
AUX channels. Currently we only trust the VBT for DDI E, which has no
corresponding AUX channel of its own. However it is possible that some
board might use some non-standard DDI vs. AUX port routing even for
the other ports. Perhaps for signal routing reasons or something,
So let's generalize this and trust the VBT for all ports.
For now we'll limit this to DDI platforms, as we trust the VBT a bit
more there anyway when it comes to the DDI ports. I've structured
the code in a way that would allow us to easily expand this to
other platforms as well, by simply filling in the ddi_port_info.
v2: Drop whitespace changes, keep MISSING_CASE() for unknown
aux ch assignment, include a commit message, include debug
message during init
Cc: stable@vger.kernel.org
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)
This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.
V2: Address review comments from Imre
- move lspcon_resume call to encoder->reset()
- use early returns
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476455212-27893-6-git-send-email-shashank.sharma@intel.com
Saves 944 bytes of .rodata strings and 128 bytes of .text.
v2: Add parantheses around dev_priv. (Ville Syrjala)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Saves 864 bytes of .rodata strings and ~100 of .text.
v2: Add parantheses around dev_priv. (Ville Syrjala)
v3: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Saves 1392 bytes of .rodata strings.
Also change a few function/macro prototypes in i915_gem_gtt.c
from dev to dev_priv where it made more sense to do so.
v2: Add parantheses around dev_priv. (Ville Syrjala)
v3: Mention function prototype changes. (David Weinehall)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Ville Syrjälä