summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_ddi.c
AgeCommit message (Collapse)Author
2018-09-01drm/i915/dp_mst: Fix enabling pipe clock for all streamsImre Deak
commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders") inadvertently stopped enabling the pipe clock for any DP-MST stream after the first one. It also rearranged the pipe clock enabling wrt. initial MST payload allocation step (which may or may not be a problem, but it's contrary to the spec.). Fix things by making the above commit truly a non-functional change. Fixes: afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365 Reported-by: Lyude Paul <lyude@redhat.com> Reported-by: dmummenschanz@web.de Tested-by: dmummenschanz@web.de Tested-by: Lyude Paul <lyude@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dmummenschanz@web.de Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180831174739.30387-1-imre.deak@intel.com
2018-08-20drm/i915/icl: Get DDI clock for ICL for MG PLL and TBT PLLManasi Navare
PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG PLL the link lock can be obtained from the the PLL divisors based on the specification. v2 (from Paulo): * Make the algorithm look more like what's in the spec, also document where we differ form the spec and why. * Make the code a little more consistent with our coding style. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-2-paulo.r.zanoni@intel.com
2018-08-14drm/i915: set DP Main Stream Attribute for color range on DDI platformsJani Nikula
Since Haswell we have no color range indication either in the pipe or port registers for DP. Instead, there's a separate register for setting the DP Main Stream Attributes (MSA) directly. The MSA register definition makes no references to colorimetry, just a vague reference to the DP spec. The connection to the color range was lost. Apparently we've failed to set the proper MSA bit for limited, or CEA, range ever since the first DDI platforms. We've started setting other MSA parameters since commit dae847991a43 ("drm/i915: add intel_ddi_set_pipe_settings"). Without the crucial bit of information, the DP sink has no way of knowing the source is actually transmitting limited range RGB, leading to "washed out" colors. With the colorimetry information, compliant sinks should be able to handle the limited range properly. Native (i.e. non-LSPCON) HDMI was not affected because we do pass the color range via AVI infoframes. Though not the root cause, the problem was made worse for DDI platforms with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the "Broadcast RGB" property"), which selects limited range RGB automatically based on the mode, as per the DP, HDMI and CEA specs. After all these years, the fix boils down to flipping one bit. [Per testing reports, this fixes DP sinks, but not the LSPCON. My educated guess is that the LSPCON fails to turn the CEA range MSA into AVI infoframes for HDMI.] Reported-by: Michał Kopeć <mkopec12@gmail.com> Reported-by: N. W. <nw9165-3201@yahoo.com> Reported-by: Nicholas Stommel <nicholas.stommel@gmail.com> Reported-by: Tom Yan <tom.ty89@gmail.com> Tested-by: Nicholas Stommel <nicholas.stommel@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=100023 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.9+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
2018-07-25drm/i915/icl: toggle PHY clock gating around link trainingPaulo Zanoni
The Gen11 TypeC PHY DDI Buffer chapter, PHY Clock Gating Programming section says that PHY clock gating should be disabled before starting voltage swing programming, then enabled after any link training is complete. v2: Simple rebase. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-6-paulo.r.zanoni@intel.com
2018-07-25drm/i915/icl: program MG_DP_MODEPaulo Zanoni
Programming this register is part of the Enable Sequence for DisplayPort on ICL. Do as the spec says. v2: Simple rebase. Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-5-paulo.r.zanoni@intel.com
2018-07-24drm/i915/icl: Implement voltage swing programming sequence for MG PHY DDIManasi Navare
This sequence is used to setup voltage swing before enabling MG PHY DDI as well as for changing the voltage during DisplayPort Link training. For ICL, there are two types of DDIs. This sequence needs to be used for MG PHY DDI which is ports C-F. v6 (From Manasi): * Add programming for MG_CLKHUB and MG_TX_DCC as per the spec updates v5 (from Paulo): * Checkpatch. v4 (from Paulo): * Fix bogus error message * Fix copy+paste bugs (missing s/TX1/TX2/ after copy+paste) * Use the new mask names * Stay under 80 columns * Add some blank lines v3: * Clear the regs before writing (Paulo) v2: * Rename to MG PHY in the function def (Jani Nikula) * Rebase on top of new revision of other patches in series Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530225344-20373-2-git-send-email-manasi.d.navare@intel.com
2018-07-13drm/i915: Nuke dev_priv->irq_port[]Ville Syrjälä
Instead of looping over ports and hpd_pins, let's loop over the encoders when doing hotplug processing. And instead of depending on dev_priv->irq_port[] to tell us whether the encoder has the ->hpd_pulse() hook or not, we can just check for that directly. So we can just nuke irq_port[] entirely. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-5-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-13drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.Clint Taylor
On GLK NUC platforms the HDMI retiming buffer needs additional disabled time to correctly sync to a faster incoming signal. When measured on a scope the highspeed lines of the HDMI clock turn off for ~400uS during a normal resolution change. The HDMI retimer on the GLK NUC appears to require at least a full frame of quiet time before a new faster clock can be correctly sync'd. Wait 100ms due to msleep inaccuracies while waiting for a completed frame. Add a quirk to the driver for GLK boards that use ITE66317 HDMI retimers. V2: Add more devices to the quirk list V3: Delay increased to 100ms, check to confirm crtc type is HDMI. V4: crtc type check extended to include _DDI and whitespace fixes v5: Fix white spaces, remove the macro for delay. Revert the crtc type check introduced in v4. Cc: Imre Deak <imre.deak@intel.com> Cc: <stable@vger.kernel.org> # v4.14+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887 Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Tested-by: Daniel Scheller <d.scheller.oss@gmail.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com
2018-07-06drm/i915/ddi: Simplify get_encoder_power_domains()Imre Deak
We can simplify the encoder's get_power_domains() hook by calling it only if the encoder is active. That way the hook can return its power domains unconditionally without checking the active state by calling encoder::get_hw_state(). This get_hw_state() query is in fact redundant since it's already done by intel_modeset_readout_hw_state() setting the encoder's crtc or leaving it NULL accordingly. Let's use this fact to decide if the encoder is active. While at it clarify the comment in intel_ddi_get_power_domains() about primary vs. fake MST encoders and make sure we never do an incorrect encoder->dig_port cast for fake MST encoders. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705122654.17072-1-imre.deak@intel.com
2018-07-05drm/i915: Mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Addresses-Coverity-ID: 1357360 Addresses-Coverity-ID: 1357403 Addresses-Coverity-ID: 1357433 Addresses-Coverity-ID: 1392622 Addresses-Coverity-ID: 1415273 Addresses-Coverity-ID: 1435752 Addresses-Coverity-ID: 1441500 Addresses-Coverity-ID: 1454596 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628223541.GA17665@embeddedor.com
2018-06-26drm/i915/ddi: Get AUX power domain for DP main link tooImre Deak
So far we got an AUX power domain reference only for the duration of DP AUX transfers. However, the following suggests that we also need these for main link functionality: - The specification doesn't state whether it's needed or not for main link functionality, but suggests that these power wells need to be enabled already during display core initialization (Sequences to Initialize Display). - For PSR we need to keep the AUX power well enabled. - On ICL combo PHY ports (non-TC) the AUX power well is needed for link training too: while the port is enabled with a DP link training test pattern trying to toggle the AUX power well will time out. - On ICL MG PHY ports (TC) the AUX power well is needed also for main link functionality (both in DP and HDMI modes). - Windows enables these power wells both for main and AUX lane functionality. Based on the above take an AUX power reference for main link functionality too. This makes a difference only on GEN10+ (GLK+) platforms, where we have separate port specific AUX power wells. For PSR we still need to distinguish between port A and the other ports, since on port A DC states must stay enabled for main link functionality, but DC states must be disabled for driver initiated AUX transfers. So re-use the corresponding helper from intel_psr.c. Since we take now a reference for main link functionality on all DP ports we can forgo taking the separate power ref for PSR functionality. v2: - Make sure DC states stay enabled when taking the ref on port A. (Ville) v3: (Ville) - Fix comment about logic for encoders without a crtc state and add FIXME note for a simplification to avoid calling get_power_domains in such cases. - Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> [Clarified code comments in intel_ddi_main_link_aux_domain() and intel_ddi_get_power_domains() (Imre)] Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180621184449.26634-1-imre.deak@intel.com
2018-06-15drm/i915/icl: implement DVFS for ICLPaulo Zanoni
ICL DVFS is almost the same as CNL, except for the CDCLK/DDICLK table. Implement it just like CNL does. References: commit 48469eced282 ("drm/i915: Use cdclk_state->voltage on CNL") References: commit 53e9bf5e8159 ("drm/i915: Adjust system agent voltage on CNL if required by DDI ports") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614221018.19044-1-paulo.r.zanoni@intel.com
2018-06-14drm/i915/icl: start adding the TBT pllPaulo Zanoni
This commit just adds the register addresses and the basic skeleton of the code. The next commits will expand on more specific functions. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-15-paulo.r.zanoni@intel.com
2018-06-14drm/i915/ddi: Set HDMI infoframes with pipe clocks enabledImre Deak
On ICL for setting the HDMI infoframe the pipe clock needs to be enabled, otherwise accessing the VIDEO_DIP_CTL register will hang the machine. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613170710.15080-5-imre.deak@intel.com
2018-06-14drm/i915/ddi: Push pipe clock enabling to encodersImre Deak
On ICL the pipe clock needs to be enabled before setting the HDMI infoframe, but these steps are in the reverse order atm. Move the pipe clock enabling to the encoders, so reordering of the two steps can be done in a clean way. No functional change. v2: - Rebased on drm-tip. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613172746.18525-1-imre.deak@intel.com
2018-06-12drm/i915/icl: Add DDI HDMI level selection for ICLManasi Navare
This patch adds a proper HDMI DDI entry level for vswing programming sequences on ICL. Spec doesn't specify any default for HDMI tables, so let's pick the last entry as the default for now to stay consistent with older platform like CNL. Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-8-paulo.r.zanoni@intel.com
2018-06-01drm/i915/icl: Calculate link clock using the new registersArkadiusz Hiler
Start using the new registers for ICL and on. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-13-paulo.r.zanoni@intel.com
2018-06-01drm/i915/icl: Get DDI clock for ICL based on PLLs.Manasi Navare
PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. This gets a little tricky for ICL since there is no register bit that maps directly to the link clock. So this patch creates a separate function in intel_dpll_mgr.c to obtain the write array PLL Params and compares the set pll_params with the table to get the corresponding link clock. v2: - Fix the encoder type check (DK). - Improve our error checking, return a sane value (Mika, Paulo). - Fix table entries (Paulo). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Paulo: implement v2] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180523224444.19017-1-paulo.r.zanoni@intel.com
2018-06-01drm/i915/icl: fix icl_unmap/map_plls_to_portsMahesh Kumar
All connectors may not have best_encoder attached, so don't dereference encoder pointer for each connector. Fixes: c27e917e2bda ("drm/i915/icl: add basic support for the ICL clocks") Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180525155238.7054-1-lucas.demarchi@intel.com
2018-05-23drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi codeVille Syrjälä
The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it elsewhere where we have some users left. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-1-ville.syrjala@linux.intel.com
2018-05-18drm/i915: Use the same vswing->max_preemph mapping on HSW/BDW as on SKL+Ville Syrjälä
All DDI platforms support the full set of preemph settings for each supported vswing, so let's use the same code for them. We'll also move the code into intel_ddi.c so that it sits closer to the actual buf trans tables. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-07drm/i915/icl: add basic support for the ICL clocksPaulo Zanoni
This commit introduces the definitions for the ICL clocks and adds the basic functions to the shared DPLL framework. It adds code for the Enable and Disable sequences for some PLLs, but it does not have the code to compute the actual PLL values, which are marked as TODO comments and should be introduced as separate commits. Special thanks to James Ausmus for investigating and fixing a bug with the placement of icl_unmap_plls_to_ports() function. v2: - Rebase around dpll_lock changes. v3: - The spec now says what the timeouts should be. - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze the machine. - Checkpatch found a white space problem. - Small adjustments before upstreaming. v4: - Move the ICL checks out of the *map_plls_to_ports() functions (James) - Add extra encoder check (James) - Call icl_unmap_plls_to_ports() later (James) v5: - Rebase after the pll struct changes. v6: - Properly make the unmap function based on encoders_post_disable() with regarding to checks and iterators. - Address checkpatch comment on "min = max = x()". Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
2018-04-30drm/i915/icl: Fix the DP Max Voltage for ICLManasi Navare
On clock recovery this function is called to find out the max voltage swing level that we could go. However gen 9 functions use the old buffer translation tables to figure that out. ICL uses different set of tables for eDP and DP for both Combo and MG PHY ports. This patch adds the hook for ICL for getting this information from appropriate buf trans tables. v5 (from Paulo): * New rebase after changes to earlier patches. v4: * Rebase. v3: * Follow the coding conventions here (https://cgit.freedesktop.org/drm-intel/tree/Documentation/process/codin g-style.rst#n191) (Paulo) v2: * Rebase after patch that adds voltage check inside buf trans function (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-9-paulo.r.zanoni@intel.com
2018-04-30drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDIManasi Navare
This is an important part of the DDI initalization as well as for changing the voltage during DisplayPort link training. The Voltage swing seqeuence is similar to Cannonlake. However it has different register definitions and hence it makes sense to create a separate vswing sequence and program functions for ICL to leave room for more changes in case the Bspec changes later and deviates from CNL sequence. v2: Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula) v3: * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo) v4: * Call it combo_vswing, use switch statement (Paulo) v5 (from Paulo): * Fix a typo. * s/rate < 600000/rate <= 600000/. * Don't remove blank lines that should be there. v6: * Rebased by Rodrigo on top of Cannonlake changes where non vswing sequences are not aligned with iboost anymore. v7: Another rebase after an upstream rework. v8 (from Paulo): * Adjust the code to the upstream output type changes. * Squash the patch that moved some functions up. * Merge both get_combo_buf_trans functions in order to simplify the code. * Change the changelog format. v9 (from Paulo): * Use RTERM_SELECT instead of SCALING_MODE_SEL. * Adjust the output type handling according to how the other platforms do it now. v10 (from Paulo): * Fix comment left out from v9 changes (Rodrigo). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: James Ausmus <james.ausmus@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-8-paulo.r.zanoni@intel.com
2018-04-07drm/i915/dp: Send DPCD ON for MST before phy_upLyude Paul
When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that: It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in intel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again. Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications. Changes since v1: - Remove comment above if (!intel_dp->is_mst) - vsryjala - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to keep enable/disable paths symmetrical - Improve commit message - dhnkrn Changes since v2: - Only send DPMS off when we're disabling the last sink, and only send DPMS on when we're enabling the first sink - dhnkrn Changes since v3: - Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
2018-03-27drm/i915: use id from intel_shared_dpll.infoLucas De Marchi
Replace all users of pll->id to use pll->info->id. In functions using this more than once it was preferred to add an id variable to make the code easier to read. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320220637.21480-6-lucas.demarchi@intel.com
2018-03-23drm/i915/icl: Add Voltage swing table for MG PHY DDI BufferManasi Navare
This table is used for voltage swing programming sequence during DDI Buffer initialization for MG PHY DDI Buffers on Icelake. v2 (from Paulo): * Fix white space issues. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180323172419.24911-5-paulo.r.zanoni@intel.com
2018-03-23drm/i915/icl: Add Combo PHY DDI Buffer translation tables for Icelake.Manasi Navare
These tables are used on voltage vswing sequence initialization on Icelake. The swing_sel on the spec's table is defined in a 4 bits binary like 1010. However the register bits are split in upper 1 bit swing_sel and lower 3 bits swing sel. In this table here we store this value as a single value in hex like it is mentioned in the Bspec and split it to the upper and lower bit values only while programming the registers. For instance: b1010 is written as 0xA and then while writing to the register, the upper 1 bit is obtained by (0xA & 0x8) and shifting by appropriate bits while lower 3 bits are obtained by (0xA & 0x7) and shifting by appropriate bits. Some of the columns need to be updated after the spec is updated. v5 (from Paulo): * Checkpatch fixes. v4 (from Paulo): * Fix minor typo * Coding style conformance v3: * Get rid of HDMI/DVI tables, same as DP (Paulo) * Use combo_phy in ddi buf trans table defs (Paulo) v2: * Added DW4_scaling_hex column to the translation tables (Rodrigo) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180323172419.24911-3-paulo.r.zanoni@intel.com
2018-03-23drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio failsVille Syrjälä
When we're disabling the HDMI link we try to reset the scrambling and TMDS bit clock ratio back to the default values. This will fail if the sink has already been disconnected. Thus we should not print an error message when resetting the scrambling/TMDS bit clock ratio fail during disable. During enable we do want the error, and during disable we may still want to know what happended for debug purposes so let's use DRM_DEBUG_KMS() there. v2: Remember them consts v3: Go back to just one function and print the errors/debugs from callers (Shashank) Cc: Shashank Sharma <shashank.sharma@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105644 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322154707.22103-1-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2018-03-19drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.Dhinakaran Pandiyan
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by: Laura Abbott <labbott@redhat.com> 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/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
2018-03-09drm/i915/icl: do not save DDI A/E sharing bit for ICLJani Nikula
We don't want to preserve the DDI A 4 lane bit on ICL. Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing limitation.") Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180306104155.3526-1-jani.nikula@intel.com
2018-03-06drm/i915: Track whether the DP link is trained or notVille Syrjälä
LSPCON likes to throw short HPDs during the enable seqeunce prior to the link being trained. These obviously result in the channel CR/EQ check failing and thus we schedule a pointless hotplug work to retrain the link. Avoid that by ignoring the bad CR/EQ status until we've actually initially trained the link. I've not actually investigated to see what LSPCON is trying to signal with the short pulse. But as long as it signals anything I think we're supposed to check the link status anyway, so I don't really see other good ways to solve this. I've not seen these short pulses being generated by normal DP sinks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180117192149.17760-5-ville.syrjala@linux.intel.com
2018-03-06drm/i915: Move SST DP link retraining into the ->post_hotplug() hookVille Syrjälä
Doing link retraining from the short pulse handler is problematic since that might introduce deadlocks with MST sideband processing. Currently we don't retrain MST links from this code, but we want to change that. So better to move the entire thing to the hotplug work. We can utilize the new encoder->hotplug() hook for this. The only thing we leave in the short pulse handler is the link status check. That one still depends on the link parameters stored under intel_dp, so no locking around that but races should be mostly harmless as the actual retraining code will recheck the link state if we end up there by mistake. v2: Rebase due to ->post_hotplug() now being just ->hotplug() Check the connector type to figure out if we should do the HDMI thing or the DP think for DDI [pushed with whitespace changes for sparse] Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180117192149.17760-3-ville.syrjala@linux.intel.com
2018-03-06drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPDVille Syrjälä
The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but when I turn it back on it will pulse the HPD line. By that time it has forgotten everything we told it about scrambling and the clock ratio. Hence if we want to get a picture out if it again we have to tell it whether we're currently sending scrambled data or not. Implement that via the encoder->hotplug() hook. v2: Force a full modeset to not follow the HDMI 2.0 spec more closely (Shashank) [pushed with whitespace fixes to make sparse happy] Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180117192149.17760-1-ville.syrjala@linux.intel.com
2018-03-05drm/i915/icl: remove port A/E lane sharing limitation.Mahesh Kumar
Platforms before Gen11 were sharing lanes between port-A & port-E. This limitation is no more there. Changes since V1: - optimize the code (Shashank/Jani) - create helper function to get max lanes (ville) Changes since V2: - Include BIOS fail fix-up in same helper function (ville) Changes since V3: - remove confusing if/else (jani) - group intel_encoder initialization Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180206060855.30026-1-mahesh1.kumar@intel.com
2018-03-01Merge tag 'drm-intel-next-2018-02-21' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Lift alpha_support protection from Cannonlake (Rodrigo) * Meaning the driver should mostly work for the hardware we had at our disposal when testing * Used to be preliminary_hw_support - Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo) - Cannonlake port register fix (Mahesh) - Fix Dell Venue 8 Pro black screen after modeset (Hans) - Fix for always returning zero out-fence from execbuf (Daniele) - Fix HDMI audio when no no relevant video output is active (Jani) - Fix memleak of VBT data on driver_unload (Hans) - Fix for KASAN found locking issue (Maarten) - RCU barrier consolidation to improve igt/gem_sync/idle (Chris) - Optimizations to IRQ handlers (Chris) - vblank tracking improvements (64-bit resolution, PM) (Dhinakaran) - Pipe select bit corrections (Ville) - Reduce runtime computed device_info fields (Chris) - Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris) - A bunch of kerneldoc warning fixes (Chris) * tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20180221 drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning drm/i915: Move the policy for placement of the GGTT vma into the caller drm/i915: Also check view->type for a normal GGTT view drm/i915: Drop WaDoubleCursorLP3Latency:ivb drm/i915: Set the primary plane pipe select bits on gen4 drm/i915: Don't set cursor pipe select bits on g4x+ drm/i915: Assert that we don't overflow frontbuffer tracking bits drm/i915: Track number of pending freed objects drm/i915/: Initialise trans_min for skl_compute_transition_wm() drm/i915: Clear the in-use marker on execbuf failure drm/i915: Prune gen8_gt_irq_handler drm/i915: Track GT interrupt handling using the master iir drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use drm: intel_dpio_phy: fix kernel-doc comments at nested struct drm/i915: Release connector iterator on a digital port conflict. drm/i915/execlists: Remove too early assert drm/i915: Assert that we always complete a submission to guc/execlists drm: move read_domains and write_domain into i915 ...
2018-02-16Merge tag 'topic/hdcp-2018-02-13' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next Add HDCP support to i915 drm driver. * tag 'topic/hdcp-2018-02-13' of git://anongit.freedesktop.org/drm/drm-misc: (26 commits) drm/i915: fix misalignment in HDCP register def drm/i915: Reauthenticate HDCP on failure drm/i915: Detect panel's hdcp capability drm/i915: Optimize HDCP key load drm/i915: Retry HDCP bksv read drm/i915: Connector info in HDCP debug msgs drm/i915: Stop encryption for repeater with no sink drm/i915: Handle failure from 2nd stage HDCP auth drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS drm/i915: Restore HDCP DRM_INFO when with no downstream drm/i915: Check for downstream topology errors drm/i915: Start repeater auth on READY/CP_IRQ drm/i915: II stage HDCP auth for repeater only drm/i915: Extending HDCP for HSW, BDW and BXT+ drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link drm/i915: Only disable HDCP when it's active drm/i915: Don't allow HDCP on PORT E/F drm/i915: Implement HDCP for DisplayPort drm/i915: Implement HDCP for HDMI drm/i915: Add function to output Aksv over GMBUS ...
2018-02-09drm/i915: Use INTEL_GEN everywhereTvrtko Ursulin
Coccinelle patch: @@ identifier p; @@ -INTEL_INFO(p)->gen +INTEL_GEN(p) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-12-tvrtko.ursulin@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180209215847.6660-1-chris@chris-wilson.co.uk
2018-01-30drm/i915/cnl: Enable DDI-F on Cannonlake.Rodrigo Vivi
Now let's finish the Port-F support by adding the proper port F detection, irq and power well support. v2: Rebase v3: Use BIT_ULL v4: Cover missed case on ddi init. v5: Update commit message. v6: Rebase on top of display headers rework. v7: Squash power-well handling related to DDI F to this patch to avoid warns as pointed out by DK. v8: Introduce DDI_F_LANES to PG2. (DK) v9: Squash in the PORT_F case for enabling DP MST encoder. (DK) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> 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: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com
2018-01-24drm/i915: Implement display w/a #1143Ville Syrjälä
Apparently SKL/KBL/CFL need some manual help to get the programmed HDMI vswing to stick. Implement the relevant workaround (display w/a #1143). Note that the relevant chicken bits live in a transcoder register even though the bits affect a specific DDI port rather than a specific transcoder. Hence we must pick the correct transcoder register instance based on the port rather than based on the cpu_transcoder. Also note that for completeness I included support for DDI A/E in the code even though we never have HDMI on those ports. v2: CFL needs the w/a as well (Rodrigo and Art) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-01-08drm/i915: Implement HDCP for HDMISean Paul
This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Changes in v2: - Rebased on drm-intel-next Changes in v3: - Initialize new worker Changes in v4: - Remove SKL_ prefix from most register names (Daniel) - Wrap sanity checks in WARN_ON (Daniel) - Consolidate the enable/disable functions into one toggle fn - Use intel_hdcp_init (Daniel) Changes in v5: - checkpatch whitespace nits Changes in v6: - None Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-9-seanpaul@chromium.org
2018-01-08drm/i915: Add HDCP framework + base implementationSean Paul
This patch adds the framework required to add HDCP support to intel connectors. It implements Aksv loading from fuse, and parts 1/2/3 of the HDCP authentication scheme. Note that without shim implementations, this does not actually implement HDCP. That will come in subsequent patches. Changes in v2: - Don't open code wait_fors (Chris) - drm_hdcp.c under MIT license (Daniel) - Move intel_hdcp_disable() call above ddi_disable (Ram) - Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel) - Justify intel_hdcp_shim with comments (Daniel) - Fixed async locking issues by adding hdcp_mutex (Daniel) - Don't alter connector_state in enable/disable (Daniel) Changes in v3: - Added hdcp_mutex/hdcp_value to make async reasonable - Added hdcp_prop_work to separate link checking & property setting - Added new helper for atomic_check state tracking (Daniel) - Moved enable/disable into atomic_commit with matching helpers - Moved intel_hdcp_check_link out of all locks when called from dp - Bumped up ksv_fifo timeout (noticed failure on one of my dongles) Changes in v4: - Remove SKL_ prefix from most register names (Daniel) - Move enable/disable back to modeset path (Daniel) - s/get_random_long/get_random_u32/ (Daniel) - Remove mode_config.mutex lock in prop_work (Daniel) - Add intel_hdcp_init to handle init of conn components (Daniel) - Actually check return value of attach_property - Check Bksv is valid before trying to authenticate (Ram) Changes in v5: - checkpatch whitespace changes - s/DRM_MODE_CONTENT_PROTECTION_OFF/DRM_MODE_CONTENT_PROTECTION_UNDESIRED/ - Fix ksv list wait timeout (actually wait 5s) - Increase the R0 timeout to 300ms (Ram) Changes in v6: - SPDX license Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ramalingam C <ramalingm.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-6-seanpaul@chromium.org
2017-12-19drm/i915: Fix indentation for intel_ddi_clk_selectChris Wilson
drivers/gpu/drm/i915/intel_ddi.c:2098 intel_ddi_clk_select() warn: inconsistent indenting References: 8edcda1266f9 ("drm/i915: Protect DDI port to DPLL map from theoretical race.") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171219112649.9388-1-chris@chris-wilson.co.uk
2017-12-18drm/i915: Protect DDI port to DPLL map from theoretical race.Rodrigo Vivi
In case we have multiple modesets for different connectors happening in parallel we could have a race on the RMW on these shared registers. This possibility was initially raised by Paulo when reviewing commit '555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")' but the original possibility comes from commit '5416d871136d ("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe later when atomic commits entered into picture. Apparently the discussion around this topic showed that the right solution would be on serializing the atomic commits in a way that we don't have the possibility of races here since if that parallel modeset happenings apparently many other things will be on fire. Code is there since SKL and there was no report of issue, but since we never looked back to that serialization possibility, and also we don't have an igt case for that it is better to at least protect this corner. Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Fixes: 555e38d27317 ("drm/i915/cnl: DDI - PLL mapping") Fixes: 5416d871136d ("drm/i915/skl: Set the eDP link rate on DPLL0") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20171215224310.19103-1-rodrigo.vivi@intel.com
2017-12-01drm/i915/cnl: Mask previous DDI - PLL mappingJames Ausmus
Without masking out the old value, we can end up pointing the DDI to a disabled PLL, which makes the system fall over. Mask out the previous value before setting the PLL to DDI mapping. This can be observed by running igt/testdisplay with both an eDP and HDMI/DP output active. v2: Add the Bugzilla link Fixes: 555e38d273172 ("drm/i915/cnl: DDI - PLL mapping") Testcase: igt/testdisplay Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103997 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201021700.13504-1-james.ausmus@intel.com
2017-12-01drm/i915: Fix has_audio readout for DDI AVille Syrjälä
Transcoder EDP does not support audio. Let's not try to read the state of the audio enable bit HSW_AUD_PIN_ELD_CP_VLD based on the pipe when using transcoder EDP. While at it make the function static and flatten it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129164303.18793-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2017-11-14drm/i915: Generalize transcoder loopingMika Kahola
To make looping through transcoders in intel_ddi.c more generic, let's switch to use 'for_each_pipe()' macro to do this. v2: Add a notion that we are dealing with transcoders instead of pipes (Jani) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510216670-16848-1-git-send-email-mika.kahola@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-11-09drm/i915: Nuke intel_digital_port->portVille Syrjälä
Remove intel_digital_port->port and replace its users with intel_encoder->port. intel_encoder->port is a superset of intel_digital_port->port, and it works correctly even for MST encoders. v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK) Performed with cocci: @@ @@ struct intel_digital_port { ... - enum port port; ... } @@ struct intel_digital_port *D; expression E; @@ - D->port = E; @@ struct intel_digital_port *D; @@ - D->port + D->base.port @ expression E; @@ ( - dp_to_dig_port(E)->port + dp_to_dig_port(E)->base.port | - enc_to_dig_port(E)->port + to_intel_encoder(E)->port ) @@ expression E; @@ - to_intel_encoder(&E->base) + E @@ struct intel_digital_port *D; identifier I, M; @@ I = &D->base <... ( - D->base.M + I->M | - &D->base + I ) ...> @@ identifier D; expression E; identifier M; @@ D = enc_to_dig_port(&E->base) <... ( - D->base.M + E->M | - &D->base + E ) ...> @@ identifier D, DP; expression E; identifier M; @@ DP = enc_to_intel_dp(&E->base) <... ( - dp_to_dig_port(DP)->base.M + E->M | - &dp_to_dig_port(DP)->base + E ) ...> @@ expression E; identifier M; @@ ( - enc_to_dig_port(&E->base)->base.M + E->M | - enc_to_dig_port(&E->base)->base + E | - enc_to_mst(&E->base)->primary->base.port + E->port ) @@ expression E; identifier D; @@ - struct intel_digital_port *D = E; ... when != D Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
2017-10-31drm/i915: Pass around crtc and connector states for audioVille Syrjälä
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>
2017-10-30drm/i915: Use intel_ddi_get_config() for MSTVille Syrjälä
Eliminate the partially duplicated DDI readout code from MST, and instead just call intel_ddi_get_config(). As a nice bonus we get more cross checking as intel_ddi_get_config() will populate output_types based on the actual mode of the DDI port. Additonally intel_ddi_get_config() must be changed to get the crtc from the passed in crtc state rather than from the encoder->crtc link. encoder->crtc really shouldn't be used anyway. v2: Rebased on BXT MST latency_optim fix Make intel_ddi_clock_get() static 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-7-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-02 07:19:32 +0000