summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_dp.c
AgeCommit message (Collapse)Author
2017-02-27drm/i915: Store encoder power domain in struct intel_encoderAnder Conselvan de Oliveira
The encoder power domain is obviously tied to the encoder, so store it in struct intel_encoder. This avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-3-ander.conselvan.de.oliveira@intel.com
2017-02-27drm/i915: Store aux power domain in intel_dpAnder Conselvan de Oliveira
The aux power domain only makes sense in the DP code. Storing it in struct intel_dp avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-2-ander.conselvan.de.oliveira@intel.com
2017-02-24drm/i915/lspcon: Switch back to PCON mode after output replugImre Deak
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
2017-02-24drm/i915: Introduce intel_ddi_dp_voltage_max()Ville Syrjälä
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
2017-02-23Revert "drm/i915/dp: Ratelimit DP aux timeout messages"Chris Wilson
This reverts commit 7ee686034b8b "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: 7ee686034b8b ("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>
2017-02-22drm/i915/dp: Ratelimit DP aux timeout messagesLyude
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>
2017-02-15drm/i915/dp: Reset the link params on HPD/connected boot/resumeManasi Navare
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
2017-02-10drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS codeVille Syrjälä
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: 9f2bdb006a7e ("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>
2017-02-09drm/i915/dp: Move initialization of hpd_pin to a new functionAnder Conselvan de Oliveira
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
2017-02-09drm/i915: Remove WA for swapped HPD pins in broxton A steppingAnder Conselvan de Oliveira
Remove workaround for swapped HPD pins in broxton A stepping, which is pre-production hardware. 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-1-ander.conselvan.de.oliveira@intel.com
2017-02-08drm/i915: Track full cdclk state for the logical and actual cdclk frequenciesVille Syrjälä
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
2017-02-08drm/i915: Start moving the cdclk stuff into a distinct state structureVille Syrjälä
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
2017-02-06drm/i915/lspcon: Fix resume time initialization due to unasserted HPDImre Deak
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
2017-02-01Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter
Chris Wilson wants the new fence tracepoint added in commit 8c96c678011eeb1676da18f203e90dea7e0d69d2 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>
2017-02-01Merge tag 'drm-misc-next-2017-01-30' of ↵Dave Airlie
git://anongit.freedesktop.org/git/drm-misc into drm-next 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() ...
2017-01-26drm/edid: Introduce drm_default_rgb_quant_range()Ville Syrjälä
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>
2017-01-26drm/i915: Add support for DP Video pattern compliance testsManasi Navare
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
2017-01-26drm/i915: Fixes to support DP Compliance EDID testsManasi Navare
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
2017-01-26drm/i915: Add support for DP link training complianceManasi Navare
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
2017-01-24drm/i915: Introduce IS_GEN9_BC for Skylake and Kabylake.Rodrigo Vivi
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
2017-01-24drm/i915/dp: do not proceed with autotests if we don't ACK themJani Nikula
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
2017-01-16drm/i915/dp: Silence compiler for missing prototypeChris Wilson
drivers/gpu/drm/i915/intel_dp.c:3063:6: warning: no previous prototype for ‘intel_dp_get_alpm_status’ [-Wmissing-prototypes] bool intel_dp_get_alpm_status(struct intel_dp *intel_dp) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170114105113.1231-2-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-01-12drm/i915/psr: enable ALPM for psr2Nagaraju, Vathsala
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
2017-01-10drm/i915/psr: program vsc header for psr2Nagaraju, Vathsala
Function hsw_psr_setup handles vsc header setup for psr1 and skl_psr_setup_vsc handles vsc header setup for psr2. Setup VSC header in function skl_psr_setup_vsc for psr2 support, as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2 operation. v2: (Jani) - Initialize variables to 0 - intel_dp_get_y_cord_status and intel_dp_get_y_cord_status made static - Correct indentation for continuation lines - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX_* - Change VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED to DP_VSC_* 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-3-git-send-email-vathsala.nagaraju@intel.com
2017-01-10drm/i915/glk: Convert a few more IS_BROXTON() to IS_GEN9_LP()Michel Thierry
Commit cc3f90f0633c ("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: cc3f90f0633c ("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
2016-12-22drm/i915: Force VDD off on the new power seqeuencer before starting to use itVille Syrjälä
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>
2016-12-22drm/i915/ddi: Rely on VBT DDI port info for eDP detectionImre Deak
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
2016-12-19drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHVVille Syrjälä
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
2016-12-13drm/i915: tune down the fast link training vs boot failDaniel Vetter
It's been unfixed since a while and no one is immediately working on this. And we have the FIXME already. And now also a task in the DP team's backlog. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.html Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Adjust comment per Ville's feedback.] Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161213195414.28923-1-daniel.vetter@ffwll.ch
2016-12-13drm/i915: Intel panel downclock cleanupMika Kahola
Let's switch to use dev_priv instead of dev when calling intel_find_panel_downclock() function. Signed-off-by: Mika Kahola <mika.kahola@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/1481616169-16210-3-git-send-email-mika.kahola@intel.com
2016-12-13drm/i915: Intel panel detection cleanupMika Kahola
Let's switch to use private dev_priv instead of dev when detecting intel panels. Signed-off-by: Mika Kahola <mika.kahola@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/1481616169-16210-2-git-send-email-mika.kahola@intel.com
2016-12-13drm/i915: Move all the DP compliance data to a separate structManasi Navare
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
2016-12-13drm/i915: Find fallback link rate/lane countManasi Navare
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
2016-12-13drm/i915: Compute sink's max lane count/link BW at HotplugManasi Navare
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
2016-12-05drm/i915: Validate mode against max. link data rate for DP MSTDhinakaran Pandiyan
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>
2016-12-05drm/i915: Fix DP link rate mathDhinakaran Pandiyan
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>
2016-12-02drm/i915/glk: Reuse broxton code for geminilakeAnder Conselvan de Oliveira
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
2016-11-25drm/i915: Pass dev_priv to intel_setup_outputs()Ander Conselvan de Oliveira
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
2016-11-23drm/i915/lspcon: Wait for expected LSPCON mode to settleImre Deak
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
2016-11-23drm/i915/lspcon: Add dp_to_lspcon helper()Imre Deak
We need to get to LSPCON in the next patch, so factor out the helper for it. While at it also remove the redundant GEN9 check. Cc: Shashank Sharma <shashank.sharma@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-3-git-send-email-imre.deak@intel.com
2016-11-17drm/i915: dev_priv cleanup in intel_dp.cTvrtko Ursulin
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>
2016-11-14drm/i915: Simplify DP port limited color range bit platform checksVille Syrjälä
Instead of checking for everything not supporting the limited color range bit in the DP port register, let's check for the one thing that does have it (g4x). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479145447-12907-3-git-send-email-ville.syrjala@linux.intel.com
2016-11-11drm/i915: More assorted dev_priv cleanupsTvrtko Ursulin
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>
2016-11-11drm/i915: Assorted dev_priv cleanupsTvrtko Ursulin
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>
2016-11-09drm/i915: Pass atomic state to intel_audio_codec_enable, v2.Maarten Lankhorst
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>
2016-11-01drm/i915: Pass dev_priv to vlv force pll functionsVille Syrjälä
Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-11-01drm/i915: Pass dev_priv to intel_wait_for_vblank()Ville Syrjälä
Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-10-28drm/i915: Change the placement of some static functions in intel_dp.cNavare, Manasi D
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
2016-10-26drm/i915/lspcon: Add workaround for resuming in PCON modeImre Deak
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
2016-10-26drm/i915/dp: Read DP descriptor for eDP and LSPCON tooImre Deak
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 17:10:02 +0000