summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | drm/i915/icl: Reserve all required PLLs for TypeC portsImre Deak2019-07-013-42/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When enabling a TypeC port we need to reserve all the required PLLs for it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks. We can select the proper PLL for the current port mode from the reserved PLLs only once we selected and locked down the port mode for the whole duration of the port's active state. Resetting and locking down the port mode can in turn happen only during the modeset commit phase once we disabled the given port and the PLL it used. To support the above reserve-and-select PLL semantic we store the reserved PLLs along with their HW state in the CRTC state and provide a way to select the active PLL from these. The selected PLL along with its HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as in the case of other port types. Besides reserving all required PLLs no functional changes. v2: - Fix releasing the ICL PLLs, not clearing the PLLs from the old crtc_state. - Init port_dpll to ICL_PORT_DPLL_DEFAULT closer to where port_dpll is used for symmetry with the corresponding ICL_PORT_DPLL_MG_PHY init. (Ville) v3: - Add FIXME: for clearing the ICL port PLLs from the new crtc state. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-20-imre.deak@intel.com
| * | | drm/i915/icl: Split getting the DPLLs to port type specific functionsImre Deak2019-07-011-34/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For clarity factor out the combo PHY and TypeC PHY specific code from icl_get_dplls() into their own functions. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-19-imre.deak@intel.com
| * | | drm/i915: Sanitize the shared DPLL find/reference interfaceImre Deak2019-07-011-37/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass the PLL HW state to the PLL find/reference functions making it clearer what is their input. Also pass to these the atomic state and the CRTC object instead of the CRTC state, since they don't require the latter. Move setting the PLL in the crtc_state to the get_dpll() hook, which is the more logical place for this, where the related PLL HW state was also set. This refactoring is also a preparation for a follow-up patch that will have to find/reference multiple PLLs. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-18-imre.deak@intel.com
| * | | drm/i915: Sanitize the shared DPLL reserve/release interfaceImre Deak2019-07-013-100/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/ to better match intel_release_shared_dplls(). Also, pass to the reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and CRTC object, that way these functions can look up the old or new state as needed. Also release the PLLs from the atomic state via a new put_dplls->intel_unreference_shared_dpll() call chain for better symmetry with the reservation via the get_dplls->intel_reference_shared_dpll() call chain. Since nothing uses the PLL returned by intel_reserve_shared_dplls(), make it return only a bool. While at it also clarify the reserve/release function docbook headers making it clear that multiple DPLLs will be reserved/released and whether the new or old atomic CRTC state is affected. This refactoring is also a preparation for a follow-up change that needs to reserve multiple DPLLs. Kudos to Ville for the idea to pass intel_atomic_state around, to make things clearer locally where an object's old/new atomic state is required. No functional changes. v2: - Fix checkpatch issue: typo in code comment. v3: - Rebase on drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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/20190628143635.22066-17-imre.deak@intel.com
| * | | drm/i915: Sanitize the TypeC FIA lane configuration decodingImre Deak2019-07-011-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use hex numbers, since that makes more sense when decoding a bit pattern. No functional change. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-16-imre.deak@intel.com
| * | | drm/i915: Keep the TypeC port mode fixed for detect/AUX transfersImre Deak2019-07-013-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must keep the TypeC port mode fixed for the duration of the connector detection and each AUX transfers. Add a new TypeC lock holding it around these two sequences. For consistency also hold the lock during the port mode sanitization. Whenever resetting the port mode (only during the detection for now) the port's AUX power domain must be disabled already. Flush the async power domain disabling work to ensure this. A follow-up patch will make the port mode changing more robust by postponing the change for active ports. v2: - Fix checkpatch issue: missing annotation for tc_lock. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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/20190628143635.22066-15-imre.deak@intel.com
| * | | drm/i915: Fix the TypeC port mode sanitization during loading/resumeImre Deak2019-07-015-16/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For using the correct AUX power domains we have to sanitize the TypeC port mode early, so move that before encoder sanitization. To do this properly read out the actual port mode instead of just relying on the VBT legacy port flag (which can be incorrect). We also verify that the PHY is connected as expected if the port is active. In case the port is inactive we connect the PHY in case of a legacy port - as we did so far. The PHY will be connected during detection for DP-alt mode - as it was done so far. For TBT-alt mode nothing needs to be done to connect the PHY. v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) v3: - Detect TCCOLD any time PORT_TX_DFLEXDPCSSS is read. (Ville) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-14-imre.deak@intel.com
| * | | drm/i915: Sanitize the TypeC connect/detect sequencesImre Deak2019-07-011-49/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the order during detection more consistent: first reset the TypeC port mode if needed (adding new helpers for this), then detect any connected sink. To check if a port mode reset is needed determine first the target port mode based on the live status if a sink is already connected or the PHY status complete flag otherwise. Add a WARN in legacy mode if unexpectedly we can't set the unsafe mode or if the FIA doesn't provide the 4 lanes required. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-13-imre.deak@intel.com
| * | | drm/i915: Handle the TCCOLD power-down eventImre Deak2019-07-011-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on a recent BSpec update (Index/21750) we must handle the TCCOLD event associated with the DP-alt mode. We can detect this event by reading an invalid all-1s value from FIA registers. After detecting TCCOLD we will: - fall back to TBT-alt mode when attempting to switch to DP-alt mode - conclude that nothing is connected during live status detection - WARN when already in unsafe mode, since then TCCOLD is unexpected v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) v3: - Use 0xffffffff instead of -1 as invalid FIA reg value. (José, Ville) - Check for TCCOLD in icl_tc_phy_status_complete() too. (Ville) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-12-imre.deak@intel.com
| * | | drm/i915: Wait for TypeC PHY complete flag to clear in safe modeImre Deak2019-07-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PHY status complete flag normally clears when disconnecting the PHY in DP-alt mode (achieved by switching to safe mode), so wait for the flag to clear. v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-11-imre.deak@intel.com
| * | | drm/i915: Factor out common parts from TypeC port handling functionsImre Deak2019-07-013-81/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Factor out helpers reading/parsing the TypeC specific registers, making current users of them clearer and letting us use them later. While at it also: - Simplify icl_tc_phy_connect() with an early return in legacy mode. - Simplify the live status check using one bitmask for all HPD bits. - Remove a micro-optimisation of the repeated safe-mode clearing. - Make sure we fix the legacy port flag in all cases. Except for the last two, no functional changes. v2: - Don't do reg reads at variable declarations. (Jani) - Prevent constant truncated compiler warning when assigning the valid_hpd_mask. (Nick) - s/intel_tc_port_get_lane_info/intel_tc_port_get_lane_mask/ (Ville) v3: - Make valid_hpd_mask init clear. (Ville) Cc: José Roberto de Souza <jose.souza@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: Nick Desaulniers <ndesaulniers@google.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/20190628143635.22066-10-imre.deak@intel.com
| * | | drm/i915: Unify the TypeC port notation in debug/error messagesImre Deak2019-07-013-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unify the TypeC port notation in log messages, so that it matches the spec. For instance the first ICL TypeC port will read as 'Port C/TC#1'. v2: - Format print the name only once. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-9-imre.deak@intel.com
| * | | drm/i915: Use the correct AUX power domain in TypeC TBT-alt modeImre Deak2019-07-011-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the TypeC TBT-alt port mode we must use the TBT AUX power domain, fix that. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-8-imre.deak@intel.com
| * | | drm/i915: Fix the TBT AUX power well enablingImre Deak2019-07-011-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL register. Fixes: c7375d9542f1 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com
| * | | drm/i915: Don't enable the DDI-IO power in the TypeC TBT-alt modeImre Deak2019-07-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the spec we should not enable the DDI-IO power domain if the TypeC port is in the TBT-alt mode, so do that only in the other TypeC modes or for non-TypeC ports. See the internal BSpec Index/22243. v2: - Add the internal BSpec reference to the log message. (José) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-6-imre.deak@intel.com
| * | | drm/i915: Sanitize the terminology used for TypeC port modesImre Deak2019-07-015-40/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TypeC port mode can switch dynamically, to reflect that better call the port's mode as 'mode' rather than 'type'. While at it: - s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/. 'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality. - Remove the 'unknown' TypeC port mode. The mode is always known, it's the TBT-alt/safe mode after HW reset and after disconnecting the PHY. Simplify the tc_port/tc_type checks accordingly. - Don't WARN if the port mode changes, that can happen normally. No functional changes. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-5-imre.deak@intel.com
| * | | drm/i915: Move the TypeC port handling code to a separate fileImre Deak2019-07-015-229/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the TypeC port handling functions to a new file for clarity. While at it: - s/icl_tc_port_connected()/intel_tc_port_connected()/ icl_tc_phy_disconnect(), will be unexported later. - s/intel_dp_get_fia_supported_lane_count()/ intel_tc_port_fia_max_lane_count()/ It's used for HDMI legacy mode too. - Simplify function interfaces by passing only dig_port to them. No functional changes. v2: - Fix checkpatch issues: +1/-1 empty lines in intel_tc.c and add missing SPDX to intel_tc.h. (Jani) Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-4-imre.deak@intel.com
| * | | drm/i915: Tune down WARNs about TBT AUX power well enablingImre Deak2019-07-011-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HW completion flag for the TBT AUX power well enabling/disabling gets stuck if the firmware tears down the TBT DP tunnel before the completion. We shouldn't complain about the timeout, since it's expected to happen and doesn't cause further issues. We suppress the disabling timeout already, do the same for enabling. v2: - Make the debug message more precise. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-3-imre.deak@intel.com
| * | | drm/i915/icl: Add support to read out the TBT PLL HW stateImre Deak2019-07-011-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support to read out the TBT PLL HW state. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-2-imre.deak@intel.com
| * | | drm/i915: Pass intel state to plane functions as wellMaarten Lankhorst2019-07-013-55/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass along the correct state as much as possible, instead of relying on the drm state internally. This is required to rely on hw state internally soon. While at it, clean up intel_plane_atomic_check slightly, by using a helper function to get the intel_crtc. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-6-maarten.lankhorst@linux.intel.com
| * | | drm/i915: Use intel_crtc_state in sanitize_watermarks() tooMaarten Lankhorst2019-07-011-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of all instances of drm_crtc_state, and rename cstate to crtc_state for more clarity. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-5-maarten.lankhorst@linux.intel.com
| * | | drm/i915: Convert hw state verifier to take more intel state, v2.Maarten Lankhorst2019-07-011-83/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like the rest of the intel atomic functions we should pass along intel_crtc_state, and dereference drm_crtc_state only through intel_crtc_state->base While at it, rename old/new_state to old/new_crtc_state. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-4-maarten.lankhorst@linux.intel.com
| * | | drm/i915: Convert most of atomic commit to take more intel stateMaarten Lankhorst2019-07-011-230/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of passing along drm_crtc_state and drm_atomic_state, pass along more intel_atomic_state and intel_crtc_state. This will make the code more readable by not casting between drm state and intel state all the time. While at it, rename old_state to state, with the get_new/old helpers there is no point in distinguishing between state before and after swapping state any more. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-3-maarten.lankhorst@linux.intel.com
| * | | drm/i915: Pass intel_crtc_state to needs_modeset()Maarten Lankhorst2019-07-011-34/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In i915 we should use intel_crtc_state as much as possible, pass intel_crtc_state to needs_modeset, before we clean up all other uses of drm_crtc_state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-2-maarten.lankhorst@linux.intel.com
| * | | drm/i915: add header search path to subdir MakefilesJani Nikula2019-06-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the subdirectories we lost the ability to build individual files on the command line, for example: $ make drivers/gpu/drm/i915/display/intel_display.o This was due to the top level directory missing from header search path. Add the header search paths to subdir Makefiles. Note that none of the other options in the top level i915 Makefile are taken into account when building individual files. Usually this is not a concern. Reported-by: Imre Deak <imre.deak@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626143618.21800-2-jani.nikula@intel.com
| * | | drm/i915/ehl: Add voltage level requirement tableJosé Roberto de Souza2019-06-261-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EHL has it own voltage level requirement depending on cd clock. BSpec: 21809 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-3-jose.souza@intel.com
| * | | drm/i915/ehl: Remove unsupported cd clocksJosé Roberto de Souza2019-06-261-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EHL do not support 648 and 652.8 MHz. v2: - Limiting maximum CD clock by max_cdclk_freq instead of remove it from icl_calc_cdclk()(Ville and Jani) BSpec: 20598 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-2-jose.souza@intel.com
| * | | drm/i915/icl: Add new supported CD clocksJosé Roberto de Souza2019-06-261-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now 180, 172.8 and 192 MHz are supported. 180 and 172.8 MHz CD clocks will only be used when audio is not enabled as state by BSpec and implemented in intel_crtc_compute_min_cdclk(), CD clock must be at least twice of Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz but we are not reading it. v3: - making icl clock arrays static (Ville) BSpec: 20598 BSpec: 15729 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-1-jose.souza@intel.com
| * | | drm/i915: Switch to per-crtc vblank vfuncsVille Syrjälä2019-06-261-15/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch from the driver-wide vblank vfuncs to the per-crtc ones so that we don't have so many platform specific vfuncs in the driver struct. We still need to do something about the rest fo the irq vfuncs... v2: s/INTEL_GEN>=3/IS_GEN3/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| * | | drm/i915: Fix various tracepoints for gen2Ville Syrjälä2019-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gen2 doesn't have a frame counter and apparently we no longer provide a fake .get_vblank_counter() hook for it. That means all tracepoints calling that hook will oops. Update the tracepoints to use intel_crtc_get_vblank_counter() which will gracefully fall back to using the software counter. This is actually a better approach since we now get (hopefully accurate) frame numbers in the traces. This also gets rid of the raw driver->get_vblank_counter() calls, which we need to do in order to switch to the per-crtc vblank vfuncs. v2: Deal with new tracepoints v3: Use a distinct variable name for the internal crtc iterator (Chris) Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 967dd4841787 ("drm: remove drm_vblank_no_hw_counter assignment from driver code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-2-ville.syrjala@linux.intel.com
| * | | drm/i915: Check backlight type while doing eDP backlight initializaitonLee Shawn C2019-06-262-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If LFP backlight type setting from VBT was "VESA eDP AUX Interface". Driver should check panel capability and try to initialize aux backlight. No matter i915_modparams.enable_dpcd_backlight was enabled or not. v2: access dev_priv->vbt.backlight.type directly and remove unused function. v3: 1. Modify i915.enable_dpcd_backlight type from bool to int and give default value as 0 (disable). 2. Add a judgement to check LFP backlight type was aux interface or not. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1561045456-12171-1-git-send-email-shawn.c.lee@intel.com
| * | | drm/i915/ehl/dsi: Enable AFE over PPI strapJosé Roberto de Souza2019-06-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The other additional step in the DSI sequence for EHL. v2: - Using REG_BIT()(Matt) - Fixed commit message typo(Vandita) BSpec: 20597 Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619233134.20009-2-jose.souza@intel.com
| * | | drm/i915/ehl/dsi: Set lane latency optimization for DW1Vandita Kulkarni2019-06-201-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EHL has 2 additional steps in the DSI sequence, this is one of then the lane latency optimization for DW1. BSpec: 20597 Cc: Uma Shankar <uma.shankar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619233134.20009-1-jose.souza@intel.com
| * | | drm/i915/ehl: Allow combo PHY A to drive a third external displayMatt Roper2019-06-192-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EHL has a mux on combo PHY A that allows it to be driven either by an internal display (DDI-A or DSI DPHY) or by an external display (DDI-D). This is a motherboard design decision that can not be changed on the fly. Unfortunately there are no strap registers that allow us to detect the board configuration directly, so let's use the VBT to try to figure it out and program the mux accordingly. For now if we run across a broken VBT that tries to claim that PHY A is attached to both internal and external displays at the same time, we'll resolve the conflict in favor of the internal display. To help debug these kind of bad VBT's, let's also add a quick DRM_DEBUG message during child device parsing so that it's easier to understand these cases if they show up in bug reports. v2: - Confirmed that VBT's dvo port refers to the DDI and not the PHY. Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If a bad VBT contradicts itself, let internal display win. (Ville) v3: - Switch condition from !IS_ICELAKE to IS_ELKHARTLAKE. Although the convention is usually to assume that future platforms will inherit all current platform behavior, this feels more like a one-platform quirk. (Ville) - Update commit message to describe what we do if/when we encounter broken VBT's, and note that the new debug print during child device parsing is intentional. Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618175131.9139-1-matthew.d.roper@intel.com
* | | | drm/i915: Limit MST to <= 8bpc once againVille Syrjälä2019-09-091-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My attempt at allowing MST to use the higher color depths has regressed some configurations. Apparently people have setups where all MST streams will fit into the DP link with 8bpc but won't fit with higher color depths. What we really should be doing is reducing the bpc for all the streams on the same link until they start to fit. But that requires a bit more work, so in the meantime let's revert back closer to the old behavior and limit MST to at most 8bpc. Cc: stable@vger.kernel.org Cc: Lyude Paul <lyude@redhat.com> Tested-by: Geoffrey Bennett <gmux22@gmail.com> Fixes: f1477219869c ("drm/i915: Remove the 8bpc shackles from DP MST") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111505 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828102059.2512-1-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com> (cherry picked from commit 75427b2a2bffc083d51dec389c235722a9c69b05) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915/dp: Fix DSC enable code to use cpu_transcoder instead of encoder->typeManasi Navare2019-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the intel_configure_pps_for_dsc_encoder() function to use cpu_transcoder instead of encoder->type to select the correct DSC registers that was wrongly used in the original patch for one DSC register isntance. Fixes: 7182414e2530 ("drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling") Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821215950.24223-1-manasi.d.navare@intel.com (cherry picked from commit d4c61c4a16decd8ace8660f22c81609a539fccba) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Do not create a new max_bpc prop for MST connectorsVille Syrjälä2019-08-271-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're not allowed to create new properties after device registration so for MST connectors we need to either create the max_bpc property earlier, or we reuse one we already have. Let's do the latter apporach since the corresponding SST connector already has the prop and its min/max are correct also for the MST connector. The problem was highlighted by commit 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors") which results in the following spew: [ 1330.878941] WARNING: CPU: 2 PID: 1554 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa0/0xb0 [drm] ... [ 1330.879008] Call Trace: [ 1330.879023] drm_property_create+0xba/0x180 [drm] [ 1330.879036] drm_property_create_range+0x15/0x30 [drm] [ 1330.879048] drm_connector_attach_max_bpc_property+0x62/0x80 [drm] [ 1330.879086] intel_dp_add_mst_connector+0x11f/0x140 [i915] [ 1330.879094] drm_dp_add_port.isra.20+0x20b/0x440 [drm_kms_helper] ... Cc: stable@vger.kernel.org Cc: Lyude Paul <lyude@redhat.com> Cc: sunpeng.li@amd.com Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Fixes: 5ca0ef8a56b8 ("drm/i915: Add max_bpc property for DP MST") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190820161657.9658-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> (cherry picked from commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Fix HW readout for crtc_clock in HDMI modeImre Deak2019-08-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The conversion during HDMI HW readout from port_clock to crtc_clock was missed when HDMI 10bpc support was added, so fix that. v2: - Unscrew the non-HDMI case. Fixes: cd9e11a8bf25 ("drm/i915/icl: Add 10-bit support for hdmi") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109593 Cc: Radhakrishna Sripada <radhakrishna.sripada@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/20190808162547.7009-1-imre.deak@intel.com (cherry picked from commit 2969a78aead38b49e80c821a5c683544ab16160d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: Fix wrong escape clock divisor init for GLKStanislav Lisovskiy2019-08-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Bspec clock divisor registers in GeminiLake should be initialized by shifting 1(<<) to amount of correspondent divisor. While i915 was writing all this time that value as is. Surprisingly that it by accident worked, until we met some issues with Microtech Etab. v2: Added Fixes tag and cc v3: Added stable to cc as well. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826 Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK") Cc: Deepak M <m.deepak@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com (cherry picked from commit ce52ad5dd52cfaf3398058384e0ff94134bbd89c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | drm/i915: fix possible memory leak in intel_hdcp_auth_downstream()Wei Yongjun2019-08-051-1/+2
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: f26ae6a652f2 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com (cherry picked from commit de70fdd7d24cd07e51fbec420f8704d956a47949) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Fix the TBT AUX power well enablingImre Deak2019-07-291-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL register. Fixes: c7375d9542f1 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com (cherry picked from commit 29ae36abf08f943b76a2959f5000c44efa335be7) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915/vbt: Fix VBT parsing for the PSR sectionDhinakaran Pandiyan2019-07-292-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A single 32-bit PSR2 training pattern field follows the sixteen element array of PSR table entries in the VBT spec. But, we incorrectly define this PSR2 field for each of the PSR table entries. As a result, the PSR1 training pattern duration for any panel_type != 0 will be parsed incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb version >= 226 will also be wrong. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org #v5.2 Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183 Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: François Guerraz <kubrick@fgv6.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com (cherry picked from commit b5ea9c9337007d6e700280c8a60b4e10d070fb53) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHVVille Syrjälä2019-07-291-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by: Stefan Gottwald <gottwald@igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit bffb31f73b29a60ef693842d8744950c2819851d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Deal with machines that expose less than three QGV pointsVille Syrjälä2019-07-291-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SAGV is forced to disabled/min/med/max in the BIOS pcode will only hand us a single QGV point instead of the normal three. Fix the code to deal with that instead declaring the bandwidth limit to be 0 MB/s (and thus preventing any planes from being enabled). Also shrink the max_bw sturct a bit while at it, and change the deratedbw type to unsigned since the code returns the bw as an unsigned int. Since we now keep track of how many qgv points we got from pcode we can drop the earlier check added for the "pcode doesn't support the memory subsystem query" case. Cc: felix.j.degrood@intel.com Cc: Mark Janes <mark.a.janes@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Fixes: c457d9cf256e ("drm/i915: Make sure we have enough memory bandwidth on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 56e9371bc3f3e7d6c1a197a45d550b2ce6af25f6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Fix various tracepoints for gen2Ville Syrjälä2019-07-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gen2 doesn't have a frame counter and apparently we no longer provide a fake .get_vblank_counter() hook for it. That means all tracepoints calling that hook will oops. Update the tracepoints to use intel_crtc_get_vblank_counter() which will gracefully fall back to using the software counter. This is actually a better approach since we now get (hopefully accurate) frame numbers in the traces. This also gets rid of the raw driver->get_vblank_counter() calls, which we need to do in order to switch to the per-crtc vblank vfuncs. v2: Deal with new tracepoints v3: Use a distinct variable name for the internal crtc iterator (Chris) Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 967dd4841787 ("drm: remove drm_vblank_no_hw_counter assignment from driver code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-2-ville.syrjala@linux.intel.com (cherry picked from commit 4c888e7bd26f58deb27c2e6ddc90000b89ee9393) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Mark expected switch fall-throughsGustavo A. R. Silva2019-07-252-1/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/gpu/drm/i915/gem/i915_gem_mman.c: In function ‘i915_gem_fault’: drivers/gpu/drm/i915/gem/i915_gem_mman.c:342:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!i915_terminally_wedged(i915)) ^ drivers/gpu/drm/i915/gem/i915_gem_mman.c:345:2: note: here case -EAGAIN: ^~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c: In function ‘i915_gem_object_map’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c:270:3: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(type); ^~~~~~~~~~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c:272:2: note: here case I915_MAP_WB: ^~~~ drivers/gpu/drm/i915/i915_gpu_error.c: In function ‘error_record_engine_registers’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/i915_gpu_error.c:1196:5: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(engine->id); ^~~~~~~~~~~~ drivers/gpu/drm/i915/i915_gpu_error.c:1197:4: note: here case RCS0: ^~~~ drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_get_fia_supported_lane_count’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/display/intel_dp.c:233:3: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(lane_info); ^~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_dp.c:234:2: note: here case 1: ^~~~ drivers/gpu/drm/i915/display/intel_display.c: In function ‘check_digital_port_conflicts’: CC [M] drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgv100.o drivers/gpu/drm/i915/display/intel_display.c:12043:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (WARN_ON(!HAS_DDI(to_i915(dev)))) ^ drivers/gpu/drm/i915/display/intel_display.c:12046:3: note: here case INTEL_OUTPUT_DP: ^~~~ Also, notice that the Makefile is modified to stop ignoring fall-through warnings. The -Wimplicit-fallthrough option will be enabled globally in v5.3. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
* | Merge tag 'drm-intel-next-2019-06-19' of ↵Dave Airlie2019-06-215-14/+20
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next Features: - HDR support (Uma, Ville) - Add I2C symlink under HDMI connector similar to DP (Oleg) - Add ICL multi-segmented gamma support (Shashank, Uma) - Update register whitelist support for new hardware (Robert, John) - GuC firmware update with updated ABI interface (Michal, Oscar) - Add support for new DMC header versions (Lucas) - In-kernel blitter client for selftest use (Matthew) - Add Mule Creec Canyon (MCC) PCH support to go with EHL (Matt) - EHL platform feature updates (Matt) - Use Command Transport Buffers with GuC on all gens (Daniele) - New i915.force_probe module parameter to replace i915.alpha_support (Jani) Refactoring: - Better runtime PM code abstraction/encapsulation (Daniele) - VBT parsing cleanup and improvements (Jani) - Move display code to its own subdirectory (Jani) - Header cleanup (Jani, Daniele) - Prep work for subsclice mask expansion (Stuart) - Use uncore mmio register accessors more, remove unused macro wrappers (Tvrtko) - Remove unused atomic property get/set stubs (Maarten) - GTT cleanups and improvements (Mika) - Pass intel_ types instead of drm_ types in plenty of display code (Ville) - Engine reset, hangcheck, fault code cleanups and improvements (Tvrtko) - Consider AML variants simply as either KBL or CFL ULX (Ville) - State checker cleanups and improvements (Ville) - GEM code reorganization to more files under gem subdirectory (Chris) - Reducing dependency on a coarse struct_mutex (Chris) Fixes: - Fix use of uninitialized/incorrect error pointers (Colin, Dan) - Fix DSI fastboot on some VLV/CHV platforms (Hans) - Fix DSI error path (Hans) - Add ICL port A combo PHY HW state check (Imre) - Fix ICL AUX-B HW not done issue (Imre) - Fix perf whitelist on gen10+ (Lionel) - Fix PSR exit by forcing manual exit on older gens (José) - Match voltage ranges instead of exact values (Lucas) - Fix SDVO HDMI audio, with cleanups (Ville) - Fix plane state dumps (Ville) - Fix driver cleanup code to support driver hot unbind (Janusz) - Add checks for ICL memory bandwidth requirements (Ville) - Fix toggling between no C8 planes vs. at least one C8 plane (Ville) - Improved checks on PLL usage conditions, refactoring (Ville) - Avoid clobbering M/N values in fastset fuzzy checks (Ville) - Take a runtime pm wakeref for atomic commits (Chris) - Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too quickly (Chris) - Avoid refcount_inc on known zero count to avoid debug flagging (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87v9x1lpdh.fsf@intel.com
* drm/i915/psr: Force manual PSR exit in older gensJosé Roberto de Souza2019-06-181-10/+26
| | | | | | | | | | | | | | | To do frontbuffer tracking we are depending on Display WA #0884 to exit PSR when there is a frontbuffer modification but according to user reports a write to CURSURFLIVE do not cause PSR to exit in older gens so lets force a PSR exit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110799 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Thomas Rohwer <trohwer85@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617195154.30292-1-jose.souza@intel.com
* drm/i915: Drop the _INCOMPLETE for has_infoframeVille Syrjälä2019-06-181-1/+1
| | | | | | | | | | We have full infoframe readout now so we can replace the PIPE_CONF_CHECK_BOOL_INCOMPLETE(has_infoframe) with the normal PIPE_CONF_CHECK_BOOL(has_infoframe). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190612130801.2085-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Make pipe_config_err() vs. fastset less confusingVille Syrjälä2019-06-181-79/+79
| | | | | | | | | | | | | | Rename pipe_config_err() to pipe_config_mismatch(), and also print whether we're doing the fastset check or the sw vs. hw state readout check. Should make the logs a bit less confusing when they're not filled with what looks like a real error. Also rename the 'adjust' variable to 'fastset' to make it clear what it means. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190612130801.2085-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
OpenPOWER on IntegriCloud