summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_hdmi.c
AgeCommit message (Collapse)Author
2021-02-11drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappingsLyude Paul
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this platform in order to make all of the display connectors work. So, let's do that. Changes since v4: * Split this into it's own patch - vsyrjala Changes since v5: * Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin() Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-3-lyude@redhat.com
2021-02-05drm/i915: Use intel_hdmi_port_clock() moreVille Syrjälä
Replace the hand rolled intel_hdmi_port_clock() stuff with the real thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204020846.2094-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-02-05drm/i915: Reject 446-480MHz HDMI clock on GLKVille Syrjälä
The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-02-02Merge tag 'topic/adl-s-enabling-2021-02-01-1' of ↵Jani Nikula
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next Driver Changes: - Add basic support for Alder Lake S, to be shared between drm-intel-next and drm-intel-gt-next Signed-off-by: Jani Nikula <jani.nikula@intel.com> # Conflicts: # drivers/gpu/drm/i915/i915_drv.h From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210202025620.2212559-1-lucas.demarchi@intel.com
2021-01-26drm/i915/adl_s: Add adl-s ddc pin mappingAditya Swarup
ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E. Combo PHY A still uses the old ddc pin mapping. From VBT, ddc pin info suggests the following mapping: VBT DRIVER DDI B->ddc_pin=2 should translate to PORT_D->0x9 DDI C->ddc_pin=3 should translate to PORT_E->0xa DDI D->ddc_pin=4 should translate to PORT_F->0xb DDI E->ddc_pin=5 should translate to PORT_G->0xc Adding pin map to facilitate this translation as we cannot use existing icl ddc pin map due to conflict with DDI B and DDI C info. Bspec:20124 v2: Replace IS_ALDERLAKE_S() with HAS_PCH_ADP() as the pin map pairing depends on the PCH being used rather than the platform.(mdroper) v3: - Modify adls_port_to_ddc_pin() to make PHY_A the special case for check, else return pin mapping based on correct arithmetic with phy offset. Remove redundant platform checks and use HAS_PCH_ADP() instead of IS_ALDERLAKE_S() in intel_hdmi_ddc_pin().(mdroper) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-9-aditya.swarup@intel.com
2021-01-13drm/i915/hdcp: Pass connector to check_2_2_linkAnshuman Gupta
This requires for HDCP 2.2 MST check link. As for DP/HDMI shims check_2_2_link retrieves the connector from dig_port, this is not sufficient or DP MST connector, there can be multiple DP MST topology connector associated with same dig_port. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: Pass dig_port to intel_hdcp_initAnshuman Gupta
Pass dig_port as an argument to intel_hdcp_init() and intel_hdcp2_init(). This will be required for HDCP 2.2 stream encryption. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com
2021-01-13drm/i915/hdcp: HDCP stream encryption supportAnshuman Gupta
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP encryption over DP MST Transport Link. HDCP 1.4 stream encryption requires to validate the stream encryption status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link in order to enable/disable the stream encryption. Both of above requirement are same for all Gen with respect to B.Spec Documentation. v2: - Cosmetic changes function name, error msg print and stream typo fixes. [Uma] v3: - uniformity for connector detail in DMESG. [Ram] Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-8-anshuman.gupta@intel.com
2021-01-07Merge tag 'drm-intel-next-2021-01-04' of ↵Daniel Vetter
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Display hotplug fix for gen2/gen3 (Chris) - Remove trailing semicolon (Tom) - Suppress display warnings for old ifwi presend on our CI (Chris) - OA/Perf related workaround (Lionel) - Replace I915_READ/WRITE per new uncore and display read/write functions (Jani) - PSR improvements (Jose) - HDR and other color changes on LSPCON (Uma, Ville) - FBC fixes for TGL (Uma) - Record plane update times for debugging (Chris) - Refactor panel backlight control functions (Dave) - Display power improvements (Imre) - Add VRR register definition (Manasi) - Atomic modeset improvements for bigjoiner pipes (Ville) - Switch off the scanout during driver unregister (Chris) - Clean-up DP's FEW enable (Manasi) - Fix VDSCP slice count (Manasi) - Fix and clean up around rc_model_size for DSC (Jani) - Remove Type-C noisy debug warn message (Sean) - Display HPD code clean-up (Ville) - Refactor Intel Display (Dave) - Start adding support for Intel's eDP backlight controls (Lyude) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210104211018.GA1094707@intel.com
2020-12-22drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1Ankit Nautiyal
The DP-HDMI2.1 PCON spec provides way for a source to set PPS parameters: slice height, slice width and bits_per_pixel, based on the HDMI2.1 sink capabilities. The DSC encoder of the PCON will respect these parameters, while preparing the 128 byte PPS. This patch adds helper functions to calculate these PPS paremeters as per the HDMI2.1 specification. v2: Addressed review comments given by Uma Shankar: -added documentation for functions -fixed typos and errors Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> [Jani: Fixed checkpatch SUSPECT_CODE_INDENT, TYPO_SPELLING] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201218103723.30844-14-ankit.k.nautiyal@intel.com
2020-12-02drm/i915/display: Implement DRM infoframe read for LSPCONUma Shankar
Implement Read back of HDR metadata infoframes i.e Dynamic Range and Mastering Infoframe for LSPCON devices. v2: Added proper bitmask of enabled infoframes as per Ville's recommendation. v3: Dropped a redundant wrapper as per Ville's comment. v4: Dropped a redundant print, added Ville's RB. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-14-uma.shankar@intel.com
2020-12-02drm/i915/display: Nuke bogus lspcon checkUma Shankar
Dropped a irrelevant lspcon check from intel_hdmi_add_properties function. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-10-uma.shankar@intel.com
2020-12-02drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variantsVille Syrjälä
With LSPCON we use the AVI infoframe to convey the colorimetry information (as opposed to DP MSA/SDP), so the property we expose should match the values we can stuff into the infoframe. Ie. we must use the HDMI variant of the property, even though we drive LSPCON in PCON mode. To that end just split intel_attach_colorspace_property() into HDMI and DP variants and let the caller worry about which one it wants to use. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-8-uma.shankar@intel.com
2020-12-02drm/i915/display: Enable HDR on gen9 devices with MCA LspconUma Shankar
Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR support for MCA LSPCON based GEN9 devices. SOC will drive LSPCON as DP and send HDR metadata as standard DP SDP packets. LSPCON will be set to operate in PCON mode, will receive the metadata and create Dynamic Range and Mastering Infoframe (DRM packets) and send it to HDR capable HDMI sink devices. v2: Re-used hsw infoframe write implementation for HDR metadata for LSPCON as per Ville's suggestion. v3: Addressed Jani Nikula's review comments. v4: Addressed Ville's review comments, removed redundant wrapper and checks, passed arguments instead of hardcodings. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-3-uma.shankar@intel.com
2020-11-18drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-10-07drm/i915/dg1: gmbus pin mappingLucas De Marchi
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC. From spec we have registers GPIO_CTL[1-4], so we should not do the 4->9 mapping as in ICL/TGL. The values for VBT seem wrong in BSpec. For the current boards we actually have a 1:1 mapping. BSpec: 49311, 49945, 20124 Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-5-lucas.demarchi@intel.com
2020-10-01drm/i915: Init lspcon after HPD in intel_dp_detect()Kai-Heng Feng
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port becomes useless and never responds to cable hotplugging: [ 3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D Seems like the lspcon chip on the system only gets powered after the cable is plugged. Consilidate lspcon_init() into lspcon_resume() to dynamically init lspcon chip, and make HDMI port work. v6: - Rebase on latest for-linux-next. v5: - Consolidate lspcon_resume() with lspcon_init(). - Move more logic into lspcon code. v4: - Trust VBT in intel_infoframe_init(). - Init lspcon in intel_dp_detect(). v3: - Make sure it's handled under long HPD case. v2: - Move lspcon_init() inside of intel_dp_hpd_pulse(). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/203 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200610075542.12882-1-kai.heng.feng@canonical.com
2020-10-01drm/i915: Plumb crtc_state to link trainingVille Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state usage by plumbing the crtc state all the way down to the link training code. Unfortunately we do have to keep some cached state in intel_dp so that we can do the "does the link need retraining?" checks from the short hpd handler. v2: Add intel_crtc_state forward declaration v3: Don't kill the PHY test code totally since it's now in the hotplug work where we can get at the states v4: Don't resurrect the debug scrambling disable bit (Imre) Use intel_dp_mst_is_master_trans() (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001111053.24451-1-ville.syrjala@linux.intel.com
2020-09-17drm/i915: Do YCbCr 444->420 conversion via DP protocol convertersVille Syrjälä
For platforms that can't do native 4:2:0 outout we may still be able to do it by getting the DP->HDMI protocol converter to perform the 4:4:4->4:2:0 downsamling for us. In this case we have to configure our hardware to output YCbCr 4:4:4, which we've already hooked up so all we need to do is flip the switch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-19-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-09-17drm/i915: DP->HDMI TMDS clock limits vs. deep colorVille Syrjälä
Account for the TMDS clock limits declared by the DFP when determining what color depth we're going to use. v2: Drop the reference to DP++ dongle since it's not handled here Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-17-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-09-17drm/i915: Extract intel_hdmi_has_audio()Ville Syrjälä
Pull the "do we want to enable audio?" computation into a small helper to make intel_hdmi_compute_config() less messy. Will make it easier to add more checks for this later (eg. we should actually be checking at the hblank is long enough for audio transmission). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-16-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-09-15drm/i915: Move hpd_pin setup to encoder initVille Syrjälä
Currently DP/HDMI/DDI encoders init their hpd_pin from the connector init. Let's move it to the encoder init so that we don't need to add platform specific junk to the connector init (which is shared by all g4x+ platforms). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnectedVille Syrjälä
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED return false we have to be capable of shutting it down cleanly so as to not anger the hw. To that end let's reduce the effect of !INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected. Should prevent anyone from automagically enabling any of them, while still allowing us to cleanly shut them down. v2: Put the check into the right place for CRT Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-01drm/i915: Add connector to hdcp_shim->check_link()Sean Paul
Currently we derive the connector from digital port in check_link(). For MST, this isn't sufficient since the digital port passed into the function can have multiple connectors downstream. This patch adds connector to the check_link() arguments so we have it when we need it. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-sean@poorly.run #v7 Changes in v4: -Added to the set Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-15-sean@poorly.run
2020-09-01drm/i915: Plumb port through hdcp initSean Paul
This patch plumbs port through hdcp init instead of relying on intel_attached_encoder() to return a non-NULL encoder which won't work for MST connectors. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-sean@poorly.run #v7 Changes in v5: -Added to the set Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-14-sean@poorly.run
2020-09-01drm/i915: Don't fully disable HDCP on a port if multiple pipes are using itSean Paul
This patch is required for HDCP over MST. If a port is being used for multiple HDCP streams, we don't want to fully disable HDCP on a port if one of them is disabled. Instead, we just disable the HDCP signalling on that particular pipe and exit early. The last pipe to disable HDCP will also bring down HDCP on the port. In order to achieve this, we need to keep a refcount in intel_digital_port and protect it using a new hdcp_mutex. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-sean@poorly.run #v7 Changes in v2: -Move the toggle_signalling call into _intel_hdcp_disable so it's called from check_work Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Split minor intel_hdcp_disable refactor into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-10-sean@poorly.run
2020-09-01drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signallingSean Paul
Instead of using intel_dig_port's encoder pipe to determine which transcoder to toggle signalling on, use the cpu_transcoder field already stored in intel_hdmi. This is particularly important for MST. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -s/hdcp/hdmi/ in commit msg (Ram) Changes in v4: -Rebased on intel_de_(read|write) change Changes in v5: -Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0 Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-6-sean@poorly.run
2020-07-14drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.Maarten Lankhorst
This fixes the following KASAN splash on module reload: [ 145.136327] ================================================================== [ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134 [ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783 [ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016 [ 145.136546] Workqueue: events drm_connector_free_work_fn [ 145.136551] Call Trace: [ 145.136560] dump_stack+0xa1/0xe0 [ 145.136571] print_address_description.constprop.0+0x1e/0x210 [ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136710] __kasan_report.cold+0x1b/0x37 [ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136870] kasan_report+0x27/0x30 [ 145.136881] __asan_report_load8_noabort+0x1c/0x20 [ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915] [ 145.136954] drm_connector_free_work_fn+0xd1/0x100 [ 145.136967] process_one_work+0x86e/0x1610 [ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0 [ 145.137004] ? move_linked_works+0x128/0x2c0 [ 145.137021] worker_thread+0x63e/0xc90 [ 145.137048] kthread+0x2f6/0x3f0 [ 145.137054] ? calculate_sigpending+0x81/0xa0 [ 145.137059] ? process_one_work+0x1610/0x1610 [ 145.137064] ? kthread_bind+0x40/0x40 [ 145.137075] ret_from_fork+0x24/0x30 [ 145.137111] Allocated by task 0: [ 145.137119] (stack is not available) [ 145.137137] Freed by task 5053: [ 145.137147] save_stack+0x28/0x90 [ 145.137152] __kasan_slab_free+0x136/0x180 [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137157] kasan_slab_free+0x26/0x30 [ 145.137161] kfree+0xe6/0x350 [ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915] [ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0 [ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915] [ 145.137403] i915_driver_remove+0xc4/0x130 [i915] [ 145.137482] i915_pci_remove+0x3e/0x90 [i915] [ 145.137489] pci_device_remove+0x108/0x2d0 [ 145.137494] device_release_driver_internal+0x1e6/0x4a0 [ 145.137499] driver_detach+0xcb/0x198 [ 145.137503] bus_remove_driver+0xde/0x204 [ 145.137508] driver_unregister+0x6d/0xa0 [ 145.137513] pci_unregister_driver+0x2e/0x230 [ 145.137576] i915_exit+0x1f/0x26 [i915] [ 145.137581] __x64_sys_delete_module+0x35b/0x470 [ 145.137586] do_syscall_64+0x99/0x4e0 [ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 145.137606] The buggy address belongs to the object at ffff888216640000 which belongs to the cache kmalloc-8k of size 8192 [ 145.137618] The buggy address is located 6192 bytes inside of 8192-byte region [ffff888216640000, ffff888216642000) [ 145.137630] The buggy address belongs to the page: [ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0 [ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80 [ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000 [ 145.137656] page dumped because: kasan: bad access detected [ 145.137668] Memory state around the buggy address: [ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137706] ^ [ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 145.137733] ================================================================== [ 145.137742] Disabling lock debugging due to kernel taint Changes since v1: - Add fixes tags. - Use early unregister. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi") Cc: <stable@vger.kernel.org> # v4.19+ Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com
2020-07-09drm/i915: Reject DRM_MODE_FLAG_DBLCLK with DVI sinksVille Syrjälä
The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the pixel repeat feature. That only works with HDMI since it requires AVI infoframe to signal the information to the sink. Hence even if the mode dotclock would be valid we cannot currently assume that we can just ignore the DBLCLK flag. Reject it for DVI sinks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-09drm/i915/sdvo: Implement limited color range for SDVO HDMI properlyVille Syrjälä
The SDVO/HDMI port register limited color range bit can only be used with TMDS encoding and not SDVO encoding, ie. to be used only when using the port as a HDMI port as opposed to a SDVO port. The SDVO spec does have a note that some GMCHs might allow that, but gen4 bspec vehemently disagrees. I suppose on ILK+ it might work since the color range handling is on the CPU side rather than on the PCH side, so there is no clear linkage between the TMDS vs. SDVO encoding and color range. Alas, I have no hardware to test that theory. To implement limited color range support for SDVO->HDMI we need to ask the SDVO device to do the range compression. Do so, but first check if the device even supports the colorimetry selection. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-07-02drm/i915/display: prefer dig_port to reference intel_digital_portLucas De Marchi
We have a mix of dport, intel_dport, intel_dig_port and dig_port to reference a intel_digital_port struct. Numbers are around 5 intel_dport 36 dport 479 intel_dig_port 352 dig_port Since we already removed the intel_ prefix from most of our other structs, do the same here and prefer dig_port. v2: rename everything in i915, not just a few display sources and reword commit message (from Matt Roper) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701045054.23357-1-lucas.demarchi@intel.com
2020-06-30drm/i915: HDCP: retry link integrity check on failureOliver Barta
A single Ri mismatch doesn't automatically mean that the link integrity is broken. Update and check of Ri and Ri' are done asynchronously. In case an update happens just between the read of Ri' and the check against Ri there will be a mismatch even if the link integrity is fine otherwise. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Reviewed-by: Sean Paul <sean@poorly.run> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504123524.7731-1-oliver.barta@aptiv.com
2020-06-04drm/i915/rkl: Add DDC pin mappingMatt Roper
The pin mapping for the final two outputs varies according to which PCH is present on the platform: with TGP the pins are remapped into the TC range, whereas with CMP they stay in the traditional combo output range. Bspec: 49181 Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-9-matthew.d.roper@intel.com
2020-04-24drm/i915: Have pfit calculations return an error codeVille Syrjälä
Change intel_{gmch,pch}_panel_fitting() to return a normal error vs. success int. We'll need this later to validate that the margin properties aren't misconfigured. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2020-04-24drm/i915: Pass connector state to pfit calculationsVille Syrjälä
Pass the entire connector state to intel_{gmch,pch}_panel_fitting(). For now we just need to get at .scaling_mode but in the future we'll want access to the margin properties as well. v2: Deal with intel_dp_ycbcr420_config() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-5-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2020-04-24drm/i915: s/pipe_config/crtc_state/ in pfit functionsVille Syrjälä
Follow the new naming convention and call the crtc state "crtc_state", and while at it drop the redundant crtc argument. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-4-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2020-04-24drm/i915: Fix skl+ non-scaled pfit modesVille Syrjälä
Fix skl_update_scaler_crtc() to deal with different scaling modes correctly. The current implementation assumes DRM_MODE_SCALE_FULLSCREEN. Fortunately we don't expose any border properties currently so the code does actually end up doing the right thing (assigning a scaler for pfit). The code does need to be fixed before any borders are exposed. Also we have redundant calls to skl_update_scaler_crtc() in dp/hdmi .compute_config() which can be nuked. They were anyway called before we had even computed the pfit state so were basically nonsense. The real call we need to keep is in intel_crtc_atomic_check(). v2: Deal witrh skl_update_scaler_crtc() in intel_dp_ycbcr420_config() Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-1-ville.syrjala@linux.intel.com
2020-04-21drm/i915: drop a bunch of superfluous inlinesJani Nikula
Remove a number of inlines from .c files, and let the compiler decide what's best. There's more to do, but need to start somewhere, and need to start setting the example. Acked-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/20200420140438.14672-2-jani.nikula@intel.com
2020-04-21drm/i915/hdmi: remove unused intel_hdmi_hdcp2_protocol()Jani Nikula
Unused, hiding from the compiler warnings behind the inline keyword. 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/20200420140438.14672-1-jani.nikula@intel.com
2020-04-17drm/i915: Add connector dbgfs for all connectorsAnshuman Gupta
Add connector debugfs attributes for each intel connector which is getting register. v2: - adding connector debugfs for each connector in intel_connector_register() to fix CI failure for legacy connectors. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415170555.15531-4-anshuman.gupta@intel.com
2020-04-16drm/i915: HDCP: fix Ri prime check done during link checkOliver Barta
The check was always succeeding even in case of a mismatch due to the HDCP_STATUS_ENC bit being set. Make sure both bits are actually set. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI") Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200328104100.12162-1-oliver.barta@aptiv.com
2020-04-06drm/i915: Add a retry counter for hotplug detect retriesImre Deak
On TypeC connectors we need to retry the detection after hotplug events for a longer time, so add a retry counter to support this. The next patch will add detection retries on TypeC ports needing this. 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/20200330095425.29113-1-imre.deak@intel.com
2020-04-03drm/i915: Pass atomic state to encoder hooksVille Syrjälä
We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-03-26drm/i915/display: Remove useless but deadly localChris Wilson
Beware dereferencing the NULL pointer prior to checking for its existence. <1>[ 3.324694] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 3.324696] #PF: supervisor read access in kernel mode <4>[ 3.324704] hardirqs last enabled at (751): [<ffffffff812a4f77>] d_lookup+0x57/0xa0 <1>[ 3.324709] #PF: error_code(0x0000) - not-present page <4>[ 3.324716] hardirqs last disabled at (752): [<ffffffff8125a1b9>] __slab_alloc.isra.89.constprop.94+0x19/0x70 <4>[ 3.324720] softirqs last enabled at (402): [<ffffffff81e00385>] __do_softirq+0x385/0x47f <6>[ 3.324725] PGD 0 P4D 0 <4>[ 3.324733] softirqs last disabled at (395): [<ffffffff810bab6a>] irq_exit+0xba/0xc0 <4>[ 3.324762] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 3.324768] CPU: 0 PID: 380 Comm: systemd-udevd Not tainted 5.6.0-rc7-CI-CI_DRM_8189+ #1 <4>[ 3.324776] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016 <4>[ 3.324840] RIP: 0010:intel_read_infoframe+0x3a/0x170 [i915] <4>[ 3.324848] Code: 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 31 c0 83 f9 0a 77 12 ba 01 00 00 00 48 d3 e2 f7 c2 c0 05 00 00 48 0f 45 c7 83 fb 03 <4c> 8b 20 0f 84 f2 00 00 00 83 fb 0a 0f 84 f3 00 00 00 83 fb 07 0f <4>[ 3.324865] RSP: 0018:ffffc900005438b0 EFLAGS: 00010212 <4>[ 3.324871] RAX: 0000000000000000 RBX: 0000000000000082 RCX: 0000000000000001 <4>[ 3.324879] RDX: 0000000000000002 RSI: ffff8883f8309000 RDI: ffff8883f80cbe00 <4>[ 3.324887] RBP: ffff8883f8309b34 R08: 000000000000000e R09: 0000000000000001 <4>[ 3.324894] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8883f7ac0000 <4>[ 3.324901] R13: ffff8883f7ac0000 R14: ffff8883f7ac0d90 R15: ffff8883f844d000 <4>[ 3.324908] FS: 00007ffa4a839680(0000) GS:ffff888410000000(0000) knlGS:0000000000000000 <4>[ 3.324917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 3.324923] CR2: 0000000000000000 CR3: 0000000401aa4002 CR4: 00000000001606f0 <4>[ 3.324930] Call Trace: <4>[ 3.324980] ? gen6_read32+0x272/0x300 [i915] <4>[ 3.325044] intel_ddi_get_config+0x238/0x610 [i915] <4>[ 3.325108] hsw_crt_get_config+0x12/0x40 [i915] <4>[ 3.325173] intel_modeset_setup_hw_state+0x3b3/0x1660 [i915] <4>[ 3.325182] ? ww_mutex_lock+0x39/0x70 <4>[ 3.325190] ? drm_modeset_lock+0xad/0x120 <4>[ 3.325254] intel_modeset_init+0x582/0x1c50 [i915] Fixes: 419190429cd1 ("drm/i915/hdmi: use struct drm_device based logging") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200326082838.16357-1-chris@chris-wilson.co.uk
2020-03-25drm/i915/hdmi: use struct drm_device based loggingJani Nikula
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fbc5396e6a512195b38c24b113aeebe23755c716.1584714939.git.jani.nikula@intel.com
2020-02-28drm/i915: Limit display Wa_1405510057 to gen11Ville Syrjälä
TGL+ supposedly do not need Wa_1405510057 so limit it to gen11 only. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-02-28drm/i915: Nuke pre-production GLK HDMI w/a 1139Ville Syrjälä
w/a #1139 is only needed for pre-production GLK. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-02-27drm/i915: significantly reduce the use of <drm/i915_drm.h>Jani Nikula
The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines 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/20200225133131.3301-1-jani.nikula@intel.com
2020-02-20drm/i915: Mark all HPD capabled connectors as suchVille Syrjälä
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-14drm/i915: split out display debugfs to a separate fileJani Nikula
The i915_debugfs.c has grown more than a little unwieldy. Split out the display related debugfs code to a file of its own under display/, initialized with a separate call. No functional changes. v2: - Also moved i915_frontbuffer_tracking, i915_gem_framebuffer, i915_power_domain_info, i915_dmc_info, i915_ipc_status (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/20200211161451.6867-2-jani.nikula@intel.com
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-23 01:14:59 +0000