- 22 Apr, 2024 5 commits
-
-
Jani Nikula authored
The dmc_firmware_path parameter is clearly a display parameter. Move it there so it's available to both i915 and xe modules. This also cleans up the ugly member in struct xe_device. v2: - New try with the NULL/"" param value issue resolved Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7c8223b68fdafbc72bee0bf5afdb2ab15261cf00.1713519628.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
The distinction between the dmc_firmware_path module param being NULL and the empty string "" is problematic. It's not possible to set the parameter back to NULL via sysfs or debugfs. Remove the distinction, and consider NULL and the empty string to be the same thing, and use the platform default for them. This removes the possibility to disable DMC (and runtime PM) via i915.dmc_firmware_path="". Instead, use "/dev/null" as the magic firmware path to skip DMC firmware loading and disable runtime PM. v2: Add support for i915.dmc_firmware_path="/dev/null" (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
The big if ladder clutters intel_dmc_init(). Split it out to a separate function. Reviewed-by:
-
Jani Nikula authored
Return failures from parse_dmc_fw() instead of relying on intel_dmc_has_payload(). Handle and error report them slightly better, including a new error message for when the firmware does not contain the main program. v2: Print specific error message for payload not found (Gustavo) Reviewed-by:
-
Jani Nikula authored
Clarify request_firmware() error handling. Don't proceed to trying to parse non-existent firmware or check for payload when request_firmware() failed to begin with. There's no reason to release_firmware() either when request_firmware() failed. Also move the message about DMC firmware homepage here, as in other cases the user probably has some firmware, although its parsing fails for some reason. Reviewed-by:
-
- 19 Apr, 2024 25 commits
-
-
Ville Syrjälä authored
Now the bxt/glk PHY code is ready for per-lane drive settings so enable it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-9-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Program each bxt/glk PHY TX lane with its own settings instead of blasting them all with the same stuff via group access. Signed-off-by:
-
Ville Syrjälä authored
Since all of this lives in intel_dpio_phy.c let's rename the bxt/glk functions to have bxt_dpio_phy_ namespace. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled intel_de_rmw() with the real thing. Signed-off-by:
-
Ville Syrjälä authored
Add a helper to do the "read from one per-lane register and write to the group register" rmw cycle. Signed-off-by:
-
Ville Syrjälä authored
Extract the BXT/GLK DPIO PHY register definitions into their own file. v2: Adjust gvt accordingly Reviewed-by:
-
Ville Syrjälä authored
Add consistent definitions for the per-lane PHY TX registers on bxt/glk. The current situation is a slight mess with some registers having a LN0 define, while others have a parametrized per-lane definition. v2: Adjust gvt accordingly Reviewed-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. for the bxt/glk PHY register definitons. Signed-off-by:
-
Imre Deak authored
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA monitor results in a blank screen, at least on MTL platforms on UHBR link rates with some (<30) uncompressed bpp values. Enabling compression fixes the problem, so do that for now. Windows enables DSC always if the sink supports it and forcing it to enable the mode without compression leads to the same problem above (which suggests a panel issue with uncompressed mode). The same 5k mode on non-UHBR link rates is not affected and lower resolution modes are not affected either. The problem is similar to the one fixed by the HBLANK expansion quirk on Synaptics hubs, with the difference that the problematic mode has a longer HBLANK duration. Also the monitor doesn't report supporting HBLANK expansion; either its internal MST hub does the expansion internally - similarly to the Synaptics hub - or the issue has another root cause, but still related to the mode's short HBLANK duration. Enable the quirk for the monitor adjusting the detection for the above differences. v2: Rebase on drm_dp_128132b_supported() change. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417142217.457902-1-imre.deak@intel.com
-
Imre Deak authored
The DPCD OUI of the logical port on a Dell UHBR monitor - on which the AUX device is used to enable DSC - is all 0. To detect if the HBLANK expansion quirk is required for this monitor use the OUI of the port's parent instead. Since in the above case the DPCD of both the logical port and the parent port reports being a sink device (vs. branch device) type, read the proper sink/branch OUI based on the DPCD device type. This is required by a follow-up patch enabling the quirk for the above Dell monitor. Reviewed-by:
-
Imre Deak authored
Add a function to get the AUX device of the parent of an MST port, used by a follow-up i915 patch in the patchset. v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch (Ankit) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: -
Imre Deak authored
Factor out a function to check if an MST port is logical, used by a follow-up i915 patch in the patchset. v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next patch. (Ankit) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: -
Imre Deak authored
Factor out a function to check for 128b/132b channel coding support used by a follow-up patch in the patchset. v2: s/drm_dp_uhbr_channel_coding_supported()/drm_dp128b132b_supported() (Jani) Cc: dri-devel@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:Manasi Navare <navaremanasi@chromium.org> Acked-by:
-
Imre Deak authored
Instead of checking each compressed bpp value against the maximum DSC/DPT bpp, simplify things by calculating the maximum bpp upfront and limiting the range of bpps looped over using this maximum. While at it add a comment about the origin of the DSC/DPT bpp limit. Bspec: 49259, 68912 Reviewed-by:
-
Imre Deak authored
The DPT/DSC bpp limit should be accounted for on MTL platforms as well, do so. Bspec: 49259 Reviewed-by:
-
Imre Deak authored
The DSC DPT interface BW limit check should take into account the link clock's (aka DDI clock in bspec) channel coding efficiency overhead. Bspec suggests that the FEC overhead needs to be applied, however HW people claim this isn't the case, nor is any overhead applicable. However based on testing various 5k/6k modes both on the DELL U3224KBA monitor and the Unigraf UCD-500 CTS test device, both the channel coding efficiency (which includes the FEC overhead) and an additional 3% overhead must be accounted for to get these modes working. Bspec: 49259 v2: - Apply an additional 3% overhead, add a commit log and code comment about these overheads and the relation to the Bspec BW limit formula. Reviewed-by:
-
Imre Deak authored
The DSC DPT bpp limit check should only fail if the available DPT BW is less than the required BW, fix the check accordingly. Reviewed-by:
-
Imre Deak authored
The expected link symbol clock unit when calculating the DSC DPT bpp limit is kSymbols/sec, aligning with the dotclock's kPixels/sec unit based on the crtc clock. As opposed to this port_clock is used - which has a 10 kbits/sec unit - with the resulting symbol clock in 10 kSymbols/sec units (disregarding the rounding error for the 13.5Gbps rate). Fix the calculation using the expected 10x factor. Reviewed-by:
-
Imre Deak authored
Fix the calculation of the DSC line buffer depth. This is limited both by the source's and sink's maximum line buffer depth, but the former one was not taken into account. On all Intel platform's the source's maximum buffer depth is 13, so the overall limit is simply the minimum of the source/sink's limit, regardless of the DSC version. This leaves the DSI DSC line buffer depth calculation as-is, trusting VBT. On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16 the line buffer depth was incorrectly programmed as 0, leading to a corruption in color gradients / lines on the decompressed screen image. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Vinod Govindapillai authored
The current intel_bw_atomic_check do not check the possbility of a sagv configuration change after the hw state readout. Hence cannot update the sagv configuration until some other relevant changes like data rates, number of planes etc. happen. Introduce a flag to force qgv check in such cases. Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-7-vinod.govindapillai@intel.com
-
Stanislav Lisovskiy authored
There could be multiple qgv and psf gv points with similar values. Apparently pcode's handling of psf and qgv points are different. For qgv case, pcode sets whatever is asked by the driver. But in case of psf gv points, it compares the bw from points before setting the mask. This can cause problems in scenarios where we have to disable sagv by setting the highest bw point and there could be multiple points with highest bw. So to set the maximum psf gv point, find out all the points with the highest bw and set all together. v1: - use the same treatment to qgv points as well (Vinod) v2: - pcode confirms that for qgv points, it sets whatever the driver sets (Vinod) Reviewed-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
Problem is that on some platforms, we do get QGV point mask in wrong state on boot. However driver assumes it is set to 0 (i.e all points allowed), however in reality we might get them all restricted, causing issues. Lets disable SAGV initially to force proper QGV point state. If more QGV points are available, driver will recalculate and update those then after next commit. v2: - Added trace to see which QGV/PSF GV point is used when SAGV is disabled. v3: - Move force disable function to intel_bw_init in order to initialize bw state as well, so that hw/sw are immediately in sync after init. v4: - Don't try sending PCode request, seems like it is not possible at intel_bw_init, however assigning bw->state to be restricted as if SAGV is off, still forces driveer to send PCode request anyway on next modeset, so the solution still works. However we still need to address the case, when no display is connected, which anyway requires much more changes. v5: - Put PCode request back and apply temporary hack to make the request succeed(in case if there 2 PSF GV points with same BW, PCode accepts only if both points are restricted/unrestricted same time) - Fix argument sequence for adl_qgv_bw(Ville Syrjälä) v6: - Fix wrong platform checks, not to break everything else. v7: - Split the handling of quplicate QGV/PSF GV points (Vinod) Restrict force disable to display version below 14 (Vinod) v8: - Simplify icl_force_disable_sagv (Vinod) Reviewed-by: -
Vinod Govindapillai authored
Extract the code to prepare the QGV points mask as per the format expected by the pcode as this could be utlized from multiple points. Reviewed-by:
-
Stanislav Lisovskiy authored
We need that in order to force disable SAGV in next patch. Also it is beneficial to separate that code, as in majority cases, when SAGV is enabled, we don't even need those calculations. Also we probably need to determine max PSF GV point as well, however currently we don't do that when we disable SAGV, which might be actually causing some issues in that case. v2: - Introduce helper adl_qgv_bw(counterpart to adl_psf_bw) (Ville Syrjälä) - Don't restrict psf gv points for SAGV disable case (Ville Syrjälä) v3: - Update icl_max_bw_qgv_point_mask to return max qgv point mask (Vinod) v4: - Minor changes in icl_find_qgv_points (Vinod) v5: - use max_bw_point instead of max_bw_point_mask (stan) Reviewed-by: -
Stanislav Lisovskiy authored
For debug purposes we need those - error path won't flood the log, however there has been already numerous cases, when due to lack of debugs, we couldn't immediately tell what was the problem on customer machine, which slowed down the investigation, requiring to get access to target device and adding those traces manually. v2: - Make the debug more generic and move it to intel_dram_detect (Gustavo Sousa) v3: - Use %u for unsigned variable in debug prints (Gustavo) Reviewed-by:
-
- 18 Apr, 2024 10 commits
-
-
Jani Nikula authored
Now that the intel_de_ functions and DISPLAY_VER() accept struct intel_display *, use it more. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
It would be too much noise to convert the intel_de_* functions from using struct drm_i915_private to struct intel_display all at once. Add generic wrappers using __to_intel_display() to accept both. v2: Take the intel_dmc_wl_* changes into account Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Jani Nikula authored
Convert the dmc wakelock interface to struct intel_display instead of struct drm_i915_private. We'll want to convert the intel_de interfaces, and there's a bit of coupling between the two, so start here. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Jani Nikula authored
Rename __intel_wait_for_register_nowl() to __intel_de_wait_for_register_nowl() to be in line with the rest of intel_de.h. Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
Jani Nikula authored
Use struct intel_display instead of struct drm_i915_private for quirks. Also do drive-by conversions in call sites of intel_has_quirk(). Reviewed-by:
-
Jani Nikula authored
Use the generic __to_intel_display() to allow passing either struct drm_i915_private * or struct intel_display * to the feature test macros. Reviewed-by:
-
Jani Nikula authored
Add generic __to_intel_display() macro that accepts either struct drm_i915_private * or struct intel_display *. This is to be used for transitional stuff that eventually needs to be converted to use struct intel_display *, and therefore is not part of to_intel_display(). Add new intel_display_conversion.h to host the helper to avoid duplication between xe and i915 drivers. v2: put it in the new header (Rodrigo) Reviewed-by:
-
Jani Nikula authored
Convert various pointers to struct intel_display * using _Generic(). Add some macro magic to make adding new conversions easier, and somewhat abstract the need to cast each generic association. The cast is required because all associations needs to compile, regardless of the type and the generic selection. The use of *p in the generic selection assignment expression removes the need to add separate associations for const pointers. Note: This intentionally does *not* cover struct drm_i915_private or struct xe_device. They are not to be used in the long run, so avoid using this macro for them. Reviewed-by:
-
Jani Nikula authored
As a baby step towards making struct intel_display the main data structure for display, add a backpointer to struct drm_device that can be used instead of &i915->drm. Reviewed-by:
-
Jani Nikula authored
Use <> instead of "" for including headers from include/, even if the file is in the same directory. Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Acked-by:
-
