- 01 Sep, 2023 8 commits
-
-
Jani Nikula authored
In the drm subsystem, the source physical address is, in most cases, available without having to parse the EDID again. Add notes about preferring to use the pre-parsed address instead. Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: linux-media@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
-
Jani Nikula authored
Avoid parsing the EDID again for source physical address. Also gets rids of a few remaining raw EDID usages. Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: linux-media@vger.kernel.org Signed-off-by:
-
Jani Nikula authored
Connectors have source physical address available in display info. There's no need to parse the EDID again for this. Add drm_dp_cec_attach() to do this. Seems like the set_edid/unset_edid naming is a bit specific now that there's no need to pass the EDID at all, so aim for attach/detach going forward. v2: Fix the embarrashing build failures Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: linux-media@vger.kernel.org Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230825130120.1250089-1-jani.nikula@intel.com
-
Jani Nikula authored
CEC needs the source physical address. Parsing it is trivial with the existing EDID CEA DB infrastructure. Default to CEC_PHYS_ADDR_INVALID (0xffff) instead of 0 to cater for easier CEC usage. Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: linux-media@vger.kernel.org Signed-off-by:
-
Jani Nikula authored
Reduce the use of struct edid and drm_edid_raw(). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/dbc0269d34f3140aff410eefae8a2711c59299b3.1692884619.git.jani.nikula@intel.com
-
Jani Nikula authored
Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to deserve a helper that also lets us abstract the raw EDID a bit better. Signed-off-by:
-
Suraj Kandpal authored
Send the correct aux rather than the one derived from intel_digital_port so that the HDCP version of both monitors are fetched rather than just the primary one's Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Use intel_connector as argument instead of intel_digital_port in hdcp_2_2_capable function and dig_port can be later derived from connector. This will help with getting the correct hdcp version of particular monitor in a MST setup. Signed-off-by:
-
- 31 Aug, 2023 3 commits
-
-
Jani Nikula authored
Split out frontbuffer related declarations and static inlines from gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. The main goal is to reduce header interdependencies. With gem/i915_gem_object.h including display/intel_frontbuffer.h, modification of the latter causes a whopping 300+ objects to be rebuilt, while many of the source files actually needing it aren't explicitly including it at all. After the change, only 21 objects depend on display/intel_frontbuffer.h, directly or indirectly. Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Imre Deak authored
Similarly to earlier platforms, assert in the MTL AUX power well enabling handler for TC AUX CH power wells that the TC port using the AUX CH is locked. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230830140421.2031111-2-imre.deak@intel.com
-
Imre Deak authored
intel_dp_force() takes the AUX power reference as required by the DP AUX transactions in intel_dp_set_edid(). However the low level AUX handler takes this reference already so the get/put in intel_dp_force() can be dropped. This also fixes a problem where the TC port mode changed while the AUX power well was enabled. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8779Signed-off-by:
-
- 30 Aug, 2023 3 commits
-
-
Swati Sharma authored
The bspec has been updated with a new revision 0x1 that translates to A1 GT stepping and C0 display stepping. Bspec: 44477 Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829135945.1201574-1-swati2.sharma@intel.com
-
Ankit Nautiyal authored
Edid specific BPC constraints are stored in limits->max_bpp. Honor these limits while computing the input bpp for DSC. v2: Use int instead of u8 for computations. (Jani) Add closes tag. (Ankit) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9161Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah. Apparently some panels that do support DSC, are not setting the bit for 8bpc. So always assume 8bpc support by DSC decoder, when DSC is claimed to be supported. v2: Use helper to get check dsc support. (Ankit) v3: Fix styling and other typos. (Jani) Signed-off-by:
-
- 29 Aug, 2023 11 commits
-
-
Jouni Högander authored
According to recent Bspec Wa 14015648006 has to be applied for all display 14 steppings. Bspec: 66624 Signed-off-by:
-
Ville Syrjälä authored
To reduce the guesswork a bit let's print out the SDVO device i2c bus and slave address during init. Reviewed-by:
-
Ville Syrjälä authored
Each SDVO device can have up to three sets of DDC pins. Currently we just register a single i2c_adapter for the entire SDVO device and semi-randomly pick the "correct" set of DDC pins during intel_sdvo_tmds_sink_detect(). This doesn't make any real sense especially if we have multiple outputs each with their own dedicated DDC bus. Let's clean up this mess and register a dedicated i2c_adapter for each of the possible pin pairs. Each output (ie. connector) can then pick the correct i2c_adapter to use for its DDC bus. And we can just switch over to drm_connector_init_with_ddc() to take care of the connector->ddc association, which also populates the "ddc" sysfs symlink as a bonus. And now that things are based on the actual connector we can also nuke the sketchy sdvo->controller_output thing. Reviewed-by:
-
Ville Syrjälä authored
We should switch over to the standard "ddc" per-connector symlink instead of rolling our own thing. The i2c specific symlink is also in the way of reworking the SDVO DDC handling (which is a mess atm) so get rid of it. Reviewed-by:
-
Ville Syrjälä authored
We already have encoder->port so get rid of the duplicate sdvo->port. Reviewed-by:
-
Ville Syrjälä authored
Call drm_encoder_init() earlier so that we don't have to keep passing the i915/dev_priv around separately. v2: Reorder drm_encoder_cleanup() in the error path (Jani) Reviewed-by:
-
Ville Syrjälä authored
Instead of operating on the output the user specified (via the connector) the current code tends to operate on whichever outputs it has detected as attached. That is not how the kms uapi is supposed to work. So simply get rid of attached_outputs and instead directly operate on the output the user has specified. Acked-by:
-
Suraj Kandpal authored
For dpmst hdcp scenario increase the message timeout based on the number of ports connected as each port needs to be validated and each will take the prescribed amount of time for the respective msg_id and total timeout will be original_timeout * num_ports. --v2 -Add justification for Adjusting the timeout [Arun] Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Up until now we were sending the base aux stored in dig_port which is not correct as this causes an issue when monitor is connected via a DPMST hub causing it to be remote hence we end up seeing AUX failures so let's send the remote aux in case of DPMST. Signed-off-by:
Arun R Murthy <arun.r.mruthy@intel.com> Signed-off-by:
-
Suraj Kandpal authored
We were propagating dig_port info to dp hdcp2 specific functions. Let us clean that up and send intel_connector in the following functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info, intel_dp_hdcp2_read_rx_status. This optimises mst scenarios where aux ends up being remote and not stored in dig_port and dig_port can always be derived from intel_connector if needed. --v2 -Fix Typo [Arun] -Dont pass drm_dp core structures [Arun] -Fix commit message styling [Arun] Signed-off-by:
-
Suraj Kandpal authored
Update intel_hdcp_shim funcs specifically read_2_2_message, write_2_2_message and config_stream_type to use intel_connector argument instead of intel_digital_port as this will help in getting correct aux later for dp mst scenarios also already hdcp funcs derive digital_port from connector and then many funcs again get back the connector from dig_port which doesn't seem right. Connector specific hdcp functions can derive dig_port on need basis. Signed-off-by:
-
- 25 Aug, 2023 9 commits
-
-
Jani Nikula authored
Abstract the register access better. The DSPCNTR read could be moved to either i9xx_plane.c or intel_color.c. The latter feels better, even if the register is written in the former. Signed-off-by:
-
Jani Nikula authored
Abstract the platform specific register access better. Signed-off-by:
-
Jani Nikula authored
Abstract the platform specific register access better. Signed-off-by:
-
Jani Nikula authored
Abstract the platform specific register access better. The separate hsw_read_gamma_mode() will make more sense with the following changes. Signed-off-by:
-
Jani Nikula authored
Add color .get_config hook to read config other than LUTs and CSCs, and start off with CHV CGM pipe mode to abstract the platform specific register access better. Signed-off-by:
-
Jani Nikula authored
Declutter i915_regs.h. Signed-off-by:
-
Vinod Govindapillai authored
Extend the SDP split audio config for DP-MST Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
-
Vinod Govindapillai authored
Modify intel_dp_has_audio to handle DP-MST as well. v1: fix the wrong port comparison (Jani Nikula) Signed-off-by:
-
Jani Nikula authored
unbind_fence_ops can be const and placed in rodata. Signed-off-by:
-
- 24 Aug, 2023 6 commits
-
-
Dnyaneshwar Bhadane authored
Update pci device ids as per bspec for RPL P/U. v2: - Append new id's instead of replacing the existing in device id list define v3: - Fixed the commit messege with revision details. Bpsec: 55376 Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Instead of warning and continuing with bogus state when the requested dotclock isn't acceptable just print some debug spew and fail gracefully. Signed-off-by:
-
Ville Syrjälä authored
port_clock is what the encoder/dpll code is supposed to calculate, it is not the input clock. Use the dotclock as the target we're trying to achieve instead. TODO: the SDVO TV clocking is a mess atm and needs further work Signed-off-by:
-
Ville Syrjälä authored
Call *_calc_dpll_params() even in cases where the encoder has computed the DPLL params for us. The SDVO TV output code doesn't populate crtc_state->dpll.dot leading to the dotclock getting calculated as zero, and that leads to all kinds of real problems. The g4x DP code also doesn't populate the derived dividers nor .vco, which could also create some confusion. Signed-off-by:
-
Ville Syrjälä authored
Allow *_calc_dpll_params() to be called even if the N/P dividers are zero without warning. We'll want to call these to make sure the derived values are fully computed, but not all users (VLV DSI in particular) even enable the DPLL and thus the dividers will be left at zero. It could also be possible that the BIOS has misprogrammed the DPLL (IIRC happened with some SNB machines with 4k+ displays) and thus we'll currently generate a lot of dmesg spew. Better be silent and just let the normal state checker/etc. deal with any driver bugs. Signed-off-by:
-
Ville Syrjälä authored
The SDVO inputs are reported a simple number, not a bitmask. Adjust the code to match reality. Note that we don't actually support dual input SDVO devices, and we just always use the first input. Signed-off-by:
-
