- Aug 22, 2023
-
-
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:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230821180619.650007-17-matthew.d.roper@intel.com
-
Gustavo Sousa authored
That power domain became unused after commit 41b4c7fe ("drm/i915: Disable DC states for all commits"). Signed-off-by:
-
- Aug 18, 2023
-
-
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 <ankit.k.nautiyal@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-19-ankit.k.nautiyal@intel.com
-
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: -
Ankit Nautiyal authored
Pull the code to get joiner constraints on maximum compressed bpp into separate function. Signed-off-by:
-
Ankit Nautiyal authored
Currently we check if the pipe_bpp selected is >= the min DSC bpc/bpp requirement. We do not check if it is <= the max DSC bpc/bpp requirement. Add checks for max DSC BPC/BPP constraints while computing the pipe_bpp when DSC is in use. v2: Fix the commit message. Signed-off-by:
-
Ankit Nautiyal authored
Refactor code to separate functions for eDP and DP for computing pipe_bpp/compressed bpp when DSC is involved. This will help to optimize the link configuration for DP later. v2: Fix checkpatch warning. Signed-off-by:
-
Ankit Nautiyal authored
The helper intel_dp_dsc_compute_bpp gives the maximum pipe bpp that is allowed with DSC. Rename the this to reflect that it returns max pipe bpp supported with DSC. Signed-off-by:
-
Ankit Nautiyal authored
To make way for fractional bpp support, avoid left shifting the output_bpp by 4 in helper intel_dp_dsc_get_output_bpp. Signed-off-by:
-
Ankit Nautiyal authored
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24. Check this condition for cases where bpc is forced by debugfs flag dsc_force_bpc. If the check fails, then WARN and ignore the debugfs flag. For MST case the pipe_bpp is already computed (hardcoded to be 24), and this check is not required. Signed-off-by:
-
Ankit Nautiyal authored
Separate out functions for getting maximum and minimum input BPC based on platforms, when DSC is used. v2: Use HAS_DSC macro instead of platform check while getting min input bpc. (Stan) Signed-off-by:
-
Ankit Nautiyal authored
For MST the bpc is hardcoded to 8, and pipe bpp to 24. So avoid forcing DSC bpc for MST case. v2: Warn and ignore the debug flag than to bail out. (Jani) v3: Fix dbg message to mention forced bpc instead of bpp. v4: Fix checkpatch longline warning. Signed-off-by:
-
Ankit Nautiyal authored
DSC compressed bpp and slice counts are already getting printed at the end of dsc compute config. Remove extra logs. Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-8-ankit.k.nautiyal@intel.com
-
Ankit Nautiyal authored
As per Bsepc:49259, Bigjoiner BW check puts restriction on the compressed bpp for a given CDCLK, pixelclock in cases where Bigjoiner + DSC are used. Currently compressed bpp is computed first, and it is ensured that the bpp will work at least with the max CDCLK freq. Since the CDCLK is computed later, lets account for Bigjoiner BW check while calculating Min CDCLK. v2: Use pixel clock in the bw calculations. (Ville) v3: Use helper to account for FEC overhead. (Stan) Signed-off-by:
-
Ankit Nautiyal authored
In Bigjoiner check for DSC, bigjoiner interface bits for DP for DISPLAY > 13 is 36 (Bspec: 49259). v2: Corrected Display ver to 13. v3: Follow convention for conditional statement. (Ville) v4: Fix check for display ver. (Ville) v5: Added note for 2 PPC. (Stan) Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ankit Nautiyal authored
Currently there are many places where we use output_bpp for link bpp and compressed bpp. Lets use consistent naming: output_bpp : The intermediate value taking into account the output_format chroma subsampling. compressed_bpp : target bpp for the DSC encoder. link_bpp : final bpp used in the link. For 444 sampling without DSC: link_bpp = output_bpp = pipe_bpp For 420 sampling without DSC: output_bpp = pipe_bpp / 2 link_bpp = output_bpp For 444 sampling with DSC: output_bpp = pipe_bpp link_bpp = compressed_bpp, computed with output_bpp (i.e. pipe_bpp in this case) For 420 sampling with DSC: output_bpp = pipe_bpp/2 link_bpp = compressed_bpp, computed with output_bpp Signed-off-by:
-
Ankit Nautiyal authored
The final link bpp used to calculate the m_n values depend on the output_format. Though the output_format is set to RGB for MST case and the link bpp will be same as the pipe bpp, for the sake of semantics, lets calculate the m_n values with the link bpp, instead of pipe_bpp. Signed-off-by:
-
Ankit Nautiyal authored
Move the check for limiting compressed bits_per_pixel for 420,422 formats in the helper to compute bits_per_pixel. v2: Fix typo in commit message. (Ankit) Signed-off-by:
-
Ankit Nautiyal authored
While using DSC the compressed bpp is computed assuming RGB output format. Consider the output_format and compute the compressed bpp during mode valid and compute config steps. For DP-MST we currently use RGB output format only, so continue using RGB while computing compressed bpp for MST case. v2: Use output_bpp instead for pipe_bpp to clamp compressed_bpp. (Ville) Signed-off-by:
-
Matt Roper authored
We don't really need a feature flag for has_4tile since there's a well-defined cutover point (DG2) at which all new platforms started using Tile4 as their Y-major tiling layout. The GT side of the code already handles Tile4 vs legacy TileY with checks on the IP version rather than looking at the feature flag, and we can simplify the display code similarly (which will also make it more self-contained for re-use in the Xe driver). Signed-off-by:
Haridhar Kalvala <haridhar.kalvala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230810234618.3738870-4-matthew.d.roper@intel.com
-
Matt Roper authored
Rather than picking random tiling formats from a pool that contains both TileY and Tile4 and then trying to replace one with the other depending on the platform, it's simpler to just use a single enum value that represents whatever the platform-appropriate Y-major tiling format is (i.e., Tile4 on Xe_HP and beyond, legacy TileY on earlier platforms). Signed-off-by:
-
Matt Roper authored
All production DG2 cards have display stepping C0 or later. We can drop Wa_14013215631 (only applies to pre-C0) and make Wa_14010547955 unconditional (applies to everything B0 and beyond). Also drop the now-unused IS_DG2_DISPLAY_STEP macro. Bspec: 44477 Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230816214201.534095-9-matthew.d.roper@intel.com
-
Matt Roper authored
The first production SoC steppings for DG2 were C0 (for G10), B1 (for G11), and A1 (for G12). This corresponds to PCI revision IDs 0x8, 0x5, and 0x1 respectively. Add this information to the driver's pre-production detection. Bspec: 44477 Signed-off-by:
-
Gustavo Sousa authored
According to the BSpec, voltage swing programming should be done for owned PHY lanes. Do not program a not-owned PHY lane. BSpec: 74103, 74104 Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Display must not enable or disable transmitters for not-owned PHY lanes. BSpec: 64539 Reviewed-by:
-
Gustavo Sousa authored
It is possible to generalize the "disable" value for the transmitters to be a bit mask based on the port width and the port reversal boolean, with a small exception for DP-alt mode with "x1" port width. Simplify the code by using such a mask and a for-loop instead of using switch-case statements. v2: - Use (i < 2) instead of (i / 2 == 0) for PHY lane mask selection. (Jani) BSpec: 64539 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Gustavo Sousa authored
There are more parts of C10/C20 programming that need to take owned lanes into account. Define the function intel_cx0_get_owned_lane_mask() and use it. There will be new users of that function in upcoming changes. BSpec: 64539 Reviewed-by:
-
- Aug 17, 2023
-
-
Anshuman Gupta authored
System wide suspend already has support for lmem save/restore during suspend therefore enabling d3cold for s2idle and keepng it disable for runtime PM.(Refer below commit for d3cold runtime PM disable justification) 'commit 66eb93e7 ("drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU")' It will reduce the DG2 Card power consumption to ~0 Watt for s2idle power KPI. v2: - Added "Cc: stable@vger.kernel.org". Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8755 Cc: stable@vger.kernel.org Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
Aaron Ma <aaron.ma@canonical.com> Tested-by:
Jianshui Yu <Jianshui.yu@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230816125216.1722002-1-anshuman.gupta@intel.com
-
Gustavo Sousa authored
That macro became unused with commit 323286c8 ("drm/i915: Move the power domain->well mappings to intel_display_power_map.c"). Signed-off-by:
-
- Aug 16, 2023
-
-
Alan Previn authored
After recent discussions with Mesa folks, it was requested that we optimize i915's GET_PARAM for the PXP_STATUS without changing the UAPI spec. Add these additional optimizations: - If any PXP initializatoin flow failed, then ensure that we catch it so that we can change the returned PXP_STATUS from "2" (i.e. 'PXP is supported but not yet ready') to "-ENODEV". This typically should not happen and if it does, we have a platform configuration issue. - If a PXP arbitration session creation event failed due to incorrect firmware version or blocking SOC fusing or blocking BIOS configuration (platform reasons that won't change if we retry), then reflect that blockage by also returning -ENODEV in the GET_PARAM:PXP_STATUS. - GET_PARAM:PXP_STATUS should not wait at all if PXP is supported but non-i915 dependencies (component-driver / firmware) we are still pending to complete the init flows. In this case, just return "2" immediately (i.e. 'PXP is supported but not yet ready'). Difference from prio revs: v3: - Rebase with latest tip that has pulled in setting the gsc fw load to fail if proxy init fails. v2: - Use a #define for the default readiness timeout (Vivaik). - Improve comments around the failing of proxy-init. v1: - Change the commit msg style to be imperative. (Jani) - Rename timeout to timeout_ms. (Jani) - Fix is_fw_err_platform_config to use higher order param (pxp) first. (Jani) Signed-off-by:Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
Balasubrawmanian, Vivaik <vivaik.balasubrawmanian@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230802182550.1592926-1-alan.previn.teres.alexis@intel.com
-
Alan Previn authored
In the case of failed suspend flow or cases where the kernel does not go into full suspend but goes from suspend_prepare back to resume_complete, we get called for a pm_complete but without runtime_pm guaranteed. Thus, ensure we take the runtime_pm when calling intel_pxp_init_hw from within intel_pxp_resume_complete. v2: resume_complete and runtime_resume should abstract a common helper with different wakeref requirements. (Daniele) Signed-off-by:
-
- Aug 14, 2023
-
-
Arun R Murthy authored
The debug print for enabling SDP CRC16 is applicable only for DP2.0, but this debug print was not within the uhbr check and was always printed. Fix this by adding proper checks and returning. v2: Fix typo in commit message (Ankit) Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
Suraj Kandpal authored
On checking DSC1.1 Errata and DSC 1.2 spec the current formula we were using was incorrect to calculate first_line_bpg_offset. The new fixed formula is derived from C model. --v2 -Use clamp function in linux/minmax.h [Ankit] --v3 -remove linux/minmax.h header Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
-
- Aug 11, 2023
-
-
Imre Deak authored
As described in the previous patch a connector shouldn't change its status while it's forced to a connected/disconnected state. This can still happen while running the connector detect function to account for lost HPD events in a low-power state. Fix this by reusing the connector detect function which handles a hotplug event and prevents updating the status for forced connectors as expected. Testcase: igt@kms_force_connector_basic@force-connector-state Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-3-imre.deak@intel.com
-
Imre Deak authored
DRM display connectors forced to a connected/disconnected state via the drm_connector::force member shouldn't change their status. Atm, this can still happen in the connector's detect function when called to handle a hotplug event. This in turn may lead to the GETCONNECTOR ioctl to report the incorrect state if it's called to return the connector properties without doing an actual detection (by calling the ioctl with a non-zero drm_mode_get_connector::count_modes). Fix the above by updating the connector state during hotplug detect only if the connector state is not forced. Testcase: igt@kms_force_connector_basic@force-connector-state Signed-off-by:
-
Imre Deak authored
The issue fixed in commit a8ddac7c ("drm/i915: Avoid HPD poll detect triggering a new detect cycle") on VLV, CHV is still present on platforms where the display hotplug detection functionality is available whenever the device is in D0 state (hence these platforms switch to HPD polling only when the device is runtime suspended). The above commit avoids an endless i915_hpd_poll_init_work() -> connector detect loop by making sure that by the end of i915_hpd_poll_init_work() all display power references acquired by the connector detect functions which can trigger a new cycle (display core power domain) are dropped. However on platforms where HPD polling is enabled/disabled only from the runtime suspend/resume handlers, this is not ensured: for instance eDP VDD, TypeC port PHYs and the runtime autosuspend delay may still keep the device runtime resumed (via a power reference acquired during connector detection and hence result in an endless loop like the above). Solve the problem described in the above commit on all platforms, by making sure that a i915_hpd_poll_init_work() -> connector detect sequence can't take any power reference in the first place which would trigger a new cycle, instead of relying on these power references to be dropped by the end of the sequence. With the default runtime autosuspend delay (10 sec) this issue didn't happen in practice, since the device remained runtime resumed for the whole duration of the above sequence. CI/IGT tests however set the autosuspend delay to 0, which makes the problem visible, see References: below. Tested on GLK, CHV. v2: Don't warn about a requeued work, to account for disabling polling directly during driver loading, reset and system resume. References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403 Signed-off-by:
-
- Aug 10, 2023
-
-
Jani Nikula authored
Unify on making the calls from display code. Need to add an if ladder in gen8_de_irq_postinstall() for now, but the function looks like it could be overall be better split by platform. Something for the future. The display version check for mtp seems a bit suspect, but this matches current code. Signed-off-by:
-
Jani Nikula authored
Add a dedicated de postinstall function. Signed-off-by:
-
Jani Nikula authored
Add a dedicated de postinstall function. Signed-off-by:
-
