- 16 May, 2023 17 commits
-
-
Imre Deak authored
Prevent downgrading the link training maximum lane count/rate if the sink is disconnected - and so the link training failure is expected. In such cases modeset failures due to the reduced max link params would be just confusing for user space (instead of which the correct thing it should act on is the sink disconnect signaled by a hotplug event, requiring a disabling modeset). v2: - Check the actual HPD state to handle the forced connector state case. (Vinod) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-11-imre.deak@intel.com
-
Imre Deak authored
If a sink is disconnected it's expected that link training actions will fail on it, so downgrade the error messages about such actions to be a debug message. Such - expected - link training failures are more frequent after a follow up patch, after which an active TypeC link is reset after the sink is disconnected which also involves a link training. v2: - Check the actual HPD state to handle the forced connector state case. (Vinod) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by:
-
Imre Deak authored
Add functions for printing link training debug and error messages, both to prepare for the next patch, which downgrades an error to a debug message if the sink is disconnected and to remove some code duplication. v2: (Ville) - Always print the connector prefix. - Preserve the drm_dbg_kms() debug category. v3: - Keep printing the name of functions calling the helpers. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Signed-off-by:
-
Imre Deak authored
During HW readout/sanitization CRTCs can be disabled only if they don't have an attached encoder (and so the encoder disable hooks don't need to be called). An upcoming patch will need to disable CRTCs also with an attached encoder, so add support for this. For bigjoiner configs the encoder disabling hooks require the slave CRTC states, so add these too to the atomic state. Since the connector atomic state is already up-to-date when the CRTC is disabled the connector state needs to be updated (reset) after the CRTC is disabled, make this so. Follow the proper order of disabling first all bigjoiner slaves, then any port synced CRTC slaves followed by the CRTC originally requested to be disabled. v2: - Fix calculating the bigjoiner_masters mask in a port sync config, (Ville) - Keep _noatomic suffix in intel_crtc_disable_noatomic(). (Ville) - Rebase on full CRTC state reset in this patchset, not requiring resetting the bigjoiner state separately and (instead) resetting the full atomic CRTC and related global state after all linked pipes got disabled. - Disable portsync slaves before a portsync master. - Disable a portsync master if a linked portsync slave is disabled. v3: (Ville) - Use s/u32/u8 for transcoder and pipe masks. - Use is_power_of_2() instead of hweight()==1. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Factor out a function setting the encoder and CRTC in the connector atomic state, required by a follow up patch. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Split calling the CRTC/encoder disabling hooks and updating the CRTC and DPLL object states from updating the CRTC and atomic state and other global state (BW, CDCLK, DBUF) into separate functions. When disabling a bigjoiner configuration the latter step can be done only after all the linked pipes are disabled, so this change prepares for that. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
During HW state readout/sanitization an up-to-date connector atomic state will be required by a follow-up patch, which can disable CRTCs with an encoder (and calling the correct encoder hooks happens via the connector atomic state encoder pointer). So update the connector state already before the CRTC sanitize/disable step. For now this doesn't make a difference, since intel_modeset_update_connector_atomic_state() will update/enable the atomic state only for connectors that have an enabled encoder/CRTC. Such CRTCs/encoders will not be affected by intel_sanitize_crtc(). v2: Add comment about why the connector state needs to be up-to-date. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Make sure that the CRTC state is reset correctly, as expected after disabling the CRTC. In particular this change will: - Zero all the CSC blob pointers after intel_crtc_free_hw_state() has freed them. - Zero the shared DPLL and port PLL pointers and clear the corresponding CRTC reference flag in the PLL state. - Reset all the transcoder and pipe fields. v2: - Reset fully the CRTC state. (Ville) - Clear pipe active flags in the DPLL state. v3: - Clear only the CRTC reference flag and add a helper for this. (Ville) v4: - Rebased on previous patch, adding intel_unreference_shared_dpll_crtc() separately. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add helpers to reference/unreference a shared DPLL tracking the use of it by a given CRTC. This prepares for the next patch, which unreferences a DPLL during CRTC HW-readout/sanitization. Suggested-by:
-
Imre Deak authored
For a bigjoiner configuration display->crtc_disable() will be called first for the slave CRTCs and then for the master CRTC. However slave CRTCs will be actually disabled only after the master CRTC is disabled (from the encoder disable hooks called with the master CRTC state). Hence the slave PIPEDMCs can be disabled only after the master CRTC is disabled, make this so. intel_encoders_post_pll_disable() must be called only for the master CRTC, as for the other two encoder disable hooks. While at it fix this up as well. This didn't cause a problem, since intel_encoders_post_pll_disable() will call the corresponding hook only for an encoder/connector connected to the given CRTC, however slave CRTCs will have no associated encoder/connector. Fixes: 3af2ff08 ("drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Suraj Kandpal authored
stream_id and k(no of streams) should be set in intel_hdcp_set_content_streams. stream_type should be set in intel_hdcp_required_content_stream. --v5 -add missing stream_id assignment [Ankit] Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515112726.689116-1-suraj.kandpal@intel.com
-
Suraj Kandpal authored
Since topology state is being added to drm_atomic_state now all drm_modeset_lock required are being taken from core. This raises an issue when we try to loop over connector and assign vcpi id to our streams as we did not have atomic state to derive acquire_ctx from. We fill in stream info if dpmst encoder is found before enabling hdcp. intel_hdcp_required_stream will be broken which will only set the content type. --v2 -move prepare streams to beginning of intel_hdcp_enable to avoid checking of mst encoder twice [Ankit] --v3 -break intel_required_content_stream to two part and set the stream_id at the beginning [Ankit] --v4 -change return types for intel_hdcp_prepare_stream and intel_hdcp_required content_stream [Ankit] -rename intel_hdcp_set_content_stream to intel_hdcp_set_stream [Ankit] -place intel_hdcp_set_streams above caller [Ankit] Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Remove enforce_type0 check outside the loop since it does not make sense to keep it there as we use the same digport and continue checking it again and again Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Pass all the parameter in intel_encoder->enable() to intel_hdcp_enable as we need intel_atomic_state later down to get acquire_ctx. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Jani Nikula authored
Split hotplug irq handling out of i915_irq.[ch] into display/intel_hotplug_irq.[ch]. The line between the new intel_hotplug_irq.[ch] and the existing intel_hotplug.[ch] needs further clarification, but the first step is to move the stuff out of i915_irq.[ch]. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Jani Nikula authored
The return value is not used for anything. Reviewed-by:
-
- 15 May, 2023 8 commits
-
-
Jani Nikula authored
Add i915 parameter to I915_STATE_WARN() and use device based logging. Done using cocci + hand edited where there was no i915 local variable ready. v2: avoid null deref in verify_connector_state() Reviewed-by:
-
Jani Nikula authored
Remove the unused macro. Signed-off-by:
-
Jani Nikula authored
Describe the assertion better. Signed-off-by:
-
Jani Nikula authored
In general, we don't do assertions that a function gets called on the right platforms, and if we did, it should not be a state warn. Signed-off-by:
-
Juha-Pekka Heikkila authored
Add Tile4 ccs modifiers w/ auxbuffer handling Implement Wa_14017240301 Bspec: 49251, 49252, 49253 Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Juha-Pekka Heikkila authored
Add Tile4 type ccs modifiers with aux buffer needed for MTL Bspec: 49251, 49252, 49253 Cc: dri-devel@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Jani Nikula authored
Add helper for reading SPI to not duplicate the write&read combo everywhere. Signed-off-by:
-
Suraj Kandpal authored
Check if media_gt exists if we are using gsc cs --v2 -correct typo [Ankit] -assign gsc variable if gt exists [Ankit] --v3 -declare gsc and gt variables in if block [Ankit] --v4 -add fixes tag [Ankit] Fixes: 88363177 ("drm/i915/mtl: Add HDCP GSC interface") Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
- 12 May, 2023 1 commit
-
-
Jani Nikula authored
CHV_FUSE_GT (0x182168) is purely about GT fuses, therefore belongs in intel_gt_regs.h, is in the gcfgmmio unit, but is technically in the VLV display base area. Add VLV_GUNIT_BASE to drop dependency on VLV_DISPLAY_BASE and thus display/intel_display_reg_defs.h in intel_gt_regs.h. v2: Add VLV_GUNIT_BASE (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 11 May, 2023 7 commits
-
-
Jani Nikula authored
Move gmbus and dp aux irq handlers to their respective files. It should be up to them what to do with the irq, not the generic irq code. Signed-off-by:
-
Ville Syrjälä authored
Now that we have encoder->devdata everwhere we don't need the intel_bios_is_port_dp_dual_mode() wrapper any more. And while at it let's include it in the child device log dump as well since the logic in there is a bit more complex than just DP&&HDMI. Signed-off-by:
-
Ville Syrjälä authored
Swap the roles of the index vs. value for the VBT DDC pin mapping tables. This is not strictly necessary for DDC pins but it will make this work exactly like the AUX CH mapping tables where the role reversal is necessary (or at least makes things easier). Consistency is good. Signed-off-by:
-
Ville Syrjälä authored
The big switch+if statement mess in map_aux_ch() is illegible. Split up into cleaner per-platform arrays like we already have for the gmbus pins. We use enum aux_ch as the index and the VBT thing as the value. Slightly non-intuitive perhaps but if we did it the other way around we'd have problems with AUX_CH_A being zero, and thus any non-populated element would look like AUX_CH_A. v2: flip the index vs. value around TODO: Didn't bother with the platform variants beyond the ones that really need remapping, which means if the VBT is bogus we end up with a nonexistent aux ch. Might be nice to check this a bit better. Yet another bitmask in device info? Signed-off-by: -
Ville Syrjälä authored
Modernize the DP AUX CH register definitions with REG_BIT() & co. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com>
-
Ville Syrjälä authored
To avoid annoying spec lookups let's define more PS_CTRL bits in the header. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Jani Nikula authored
The display prefix is unnecessary within the display sub-directory. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
- 09 May, 2023 1 commit
-
-
Jani Nikula authored
For development and testing purposes, the i915.force_probe module parameter and DRM_I915_FORCE_PROBE kconfig option allow probing of devices that aren't supported by the driver. The i915.force_probe module parameter is "unsafe" and setting it taints the kernel. However, using the kconfig option does not. Always taint the kernel when force probing a device that is not supported. v2: Drop "depends on EXPERT" to avoid build breakage (kernel test robot) Fixes: 7ef5ef5c ("drm/i915: add force_probe module parameter to replace alpha_support") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 08 May, 2023 1 commit
-
-
Stanislav Lisovskiy authored
By my own mistake, after adding !IS_DG2 into wrong branch, bxt_set_cdclk started to execute code intended for platforms gen < 11, which is wrong. Move IS_DG2 check to better place. Fixes: ceb0cc3b ("drm/i915: Communicate display power demands to pcode") Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230506144217.26075-1-stanislav.lisovskiy@intel.com
-
- 05 May, 2023 5 commits
-
-
Ville Syrjälä authored
On g4x the hardware has only one audio/video DIP block. Thus only one HDMI port can transmit audio/infoframes at a time. Currently we pretend that multiple ports can do it at the same time, but that doesn't actually work for two reasons: - the state of the single hw block will get clobbered by the multiple ports, leading to state checker failures - the hardware will automagically disable audio/infoframe transmission when enabled on multiple ports To fix this let's allow only one of the ports to transmit audio/infoframes at a time. We'll just go over all the HDMI ports and pick the first one that is otherwise capable of audio/infoframes. Further HDMI ports will be treated as if they had a DVI sink connected. In order to compute this consistently we'll also need to always add all HDMI ports to the atomic state. Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
We'll be wanting to compute has_hdmi_sink a bit differently for some platforms. To that end compute it in the encoder .compute_config_hook() before we call intel_hdmi_compute_config(). intel_hdmi_compute_has_hdmi_sink() will do the basic lifting beyond any platform specific stuff. Signed-off-by:
-
Ankit Nautiyal authored
Check for MODE_H_ILLEGAL before calculating max rates, lanes etc. Move comments about compressed bpp U6.4 format closer to where it is used. Signed-off-by:
-
Ankit Nautiyal authored
Common function to get the sink format for a given mode for DP. Signed-off-by:
-
Ankit Nautiyal authored
Start passing the sink_format, to all functions that take a bool ycbcr420_output as parameter. This will make the functions generic, and will serve as a slight step towards 4:2:2 support later. v2: Rebased. v3: Correct the checks in places concerned with pipe output. (Ville) Other minor styling and refactoring fixes, as suggested by Ville. Suggested-by:
-
