- 30 Aug, 2023 1 commit
-
-
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:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230824125121.840298-2-ankit.k.nautiyal@intel.com
-
- 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:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230825134431.24391-7-ville.syrjala@linux.intel.com
-
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:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230828063401.600414-5-suraj.kandpal@intel.com
-
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 9 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:
-
Ville Syrjälä authored
Put parens around macro argument evaluation for safety. Signed-off-by:
-
Ville Syrjälä authored
I have at least one SDVO device (some Lenovo DVI-I ADD2 card, based on Conexant CX25904) where GetAttachedDisplays returns success but fails to report any attached displays unless we precede the command with a SetTargetOutput. Make it so. I wasn't able to spot anything in the SDVO spec stating that this should be necessary, but real world wins over spec. Signed-off-by:
-
Juha-Pekka Heikkila authored
Add missing spin_lock/unlock Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
-
- 23 Aug, 2023 2 commits
-
-
Imre Deak authored
After the commit in the Fixes: line below, HPD polling stopped working on i915, since after that change calling drm_kms_helper_poll_enable() doesn't restart drm_mode_config::output_poll_work if the work was stopped (no connectors needing polling) and enabling polling for a connector (during runtime suspend or detecting an HPD IRQ storm). After the above change calling drm_kms_helper_poll_enable() is a nop after it's been called already and polling for some connectors was disabled/re-enabled. Fix this by calling drm_kms_helper_poll_reschedule() added in the previous patch instead, which reschedules the work whenever expected. Fixes: d33a54e3 ("drm/probe_helper: sort out poll_running vs poll_enabled") CC: stable@vger.kernel.org # 6.4+ Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-2-imre.deak@intel.com
-
Imre Deak authored
Add a helper to reschedule drm_mode_config::output_poll_work after polling has been enabled for a connector (and needing a reschedule, since previously polling was disabled for all connectors and hence output_poll_work was not running). This is needed by the next patch fixing HPD polling on i915. CC: stable@vger.kernel.org # 6.4+ Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
- 22 Aug, 2023 4 commits
-
-
Vinod Govindapillai authored
Combine all DP audio configs into a single function Signed-off-by:
-
Vinod Govindapillai authored
The needed functionality can be performed using crtc_state here. Signed-off-by:
-
Matt Roper authored
Most of the IS_METEORLAKE checks in the display code shouldn't actually be tied to MTL as a platform, but rather to the Xe_LPD+ display IP (which is used in MTL, but may show up again in future platforms). In cases where we're trying to match that specific IP, use a version check against IP_VER(14, 0). For cases where we're just handling new behavior introduced by this IP (but which may also be inherited by future IP as well), use a ver >= 14 check. The one exception here is the stolen memory workaround Wa_13010847436 (which is mislabelled as "Wa_22018444074" in the code). That's truly a MTL-specific issue rather than being tied to any of the IP blocks, so leaving the condition as IS_METEORLAKE is correct there. v2: - cdclk check should be >=, not >. (Gustavo) Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-19-matthew.d.roper@intel.com
-
Matt Roper authored
Stepping-specific display behavior shouldn't be tied to MTL as a platform, but rather specifically to the Xe_LPD+ IP. Future non-MTL platforms may re-use this IP and will need to follow the exact same logic and apply the same workarounds. IS_MTL_DISPLAY_STEP() is dropped in favor of a new macro IS_DISPLAY_IP_STEP() that only checks the display IP version. v2: - Rename macro to IS_DISPLAY_IP_STEP for consistency with the corresponding GT macro and handle steppings the same way. v3: - Drop the automatic "STEP_" pasting. v4: - Implement IS_DISPLAY_IP_STEP on top of IS_DISPLAY_IP_RANGE / IS_DISPLAY_STEP building blocks and make the parameters from/until instead of begin/fixed. (Jani) - Fix usage details in comment. v5: - Tweak macro comment. (Gustavo) Signed-off-by:
-
- 21 Aug, 2023 1 commit
-
-
Gustavo Sousa authored
That power domain became unused after commit 41b4c7fe ("drm/i915: Disable DC states for all commits"). Signed-off-by:
-
- 18 Aug, 2023 3 commits
-
-
Ankit Nautiyal authored
Currently for testing an output format with DSC, we just force the output format, without checking if it can be supported. This also creates an issue where there is a PCON which might need to convert from forced output format to the format to sink format. Signed-off-by:
-
Ankit Nautiyal authored
Use checks for src and sink limits before computing compressed bpp for eDP. Signed-off-by:
-
Ankit Nautiyal authored
Currently, we take the max lane, rate and pipe bpp, to get the maximum compressed bpp possible. We then set the output bpp to this value. This patch provides support to have max bpp, min rate and min lanes, that can support the min compressed bpp. v2: -Avoid ending up with compressed bpp, same as pipe bpp. (Stan) -Fix the checks for limits->max/min_bpp while iterating over list of valid DSC bpcs. (Stan) v3: -Refactor the code to have pipe bpp/compressed bpp computation and slice count calculation separately for different cases. v4: -Separate the pipe_bpp calculation for eDP and DP. v5: -Get rid of magic numbers for max and min bpp, and improve documentation. (Stan). -Use functions for {src_sink}_{min_max}_compressed_bpp (Ville). v6: -Remove lines to set link config to max. v7: -Split the part to separate edp and dp functions for computing DSC BPP into separate patch. v8: -Separate mechanism to get compressed bpp for ICL,TGL and XELPD+. Signed-off-by:
-
