- 19 Apr, 2024 18 commits
-
-
Ville Syrjälä authored
Use REG_BIT() & co. for the bxt/glk PHY register definitons. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
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:Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
- 18 Apr, 2024 11 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:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Luca Coelho authored
The pipes that can be used for eDP MSO are limited to pipe A (and sometimes also pipe B) only for display version 20 and below. Modify the function that returns the pipe mask for eDP MSO so that these limitations only apply to version 20 and below, enabling all pipes otherwise. Bspec: 68923 Cc: Jani Nikula <jani.nikula@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
- 17 Apr, 2024 11 commits
-
-
Ville Syrjälä authored
For some reason the snps/cx0 PLL states were added into a union alongside dpll_hw_state. Just suck them into dpll_hw_state so that we don't have so many levels of unions/etc. TODO: Get rid of 'clock' from the snps/cx0 PLL states as it is not a register values and thus doesn't belong there Signed-off-by: -
Ville Syrjälä authored
intel_dpll_hw_state contains space for all possible PLL register values across all platforms. That is rather wasteful as each machine only needs to store the registers values that are appropriate for the platform. Turn intel_dpll_hw_state into a union so that we don't waste memory for the register values of other platforms. And let's use an anonymous union so that we don't have to do tons of s/struct/union/ all over the place. pahole: struct intel_dpll_hw_state { - struct i9xx_dpll_hw_state i9xx; /* 0 16 */ - struct hsw_dpll_hw_state hsw; /* 16 8 */ - struct skl_dpll_hw_state skl; /* 24 12 */ - struct bxt_dpll_hw_state bxt; /* 36 44 */ - /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ - struct icl_dpll_hw_state icl; /* 80 60 */ + union { + struct i9xx_dpll_hw_state i9xx; /* 0 16 */ + struct hsw_dpll_hw_state hsw; /* 0 8 */ + struct skl_dpll_hw_state skl; /* 0 12 */ + struct bxt_dpll_hw_state bxt; /* 0 44 */ + struct icl_dpll_hw_state icl; /* 0 60 */ + }; /* 0 60 */ - /* size: 140, cachelines: 3, members: 5 */ - /* last cacheline: 12 bytes */ + /* size: 60, cachelines: 1, members: 1 */ + /* last cacheline: 60 bytes */ Signed-off-by: -
Ville Syrjälä authored
struct intel_dpll_hw_state has a spot for all possible PLL registers across all platforms (well, apart from cx0/snps). This makes it rather confusing when trying to figure out which members belong to which platform(s). Split the struct up into five different platform specific sub-structures. For now this will actually increase the size a little bit as we have to duplicate a few members from skl to icl, but that will be remedied soon when we turn the thing into a union. Signed-off-by:
-
Ville Syrjälä authored
Add some local 'hw_state' variables to the old DPLL code. Will help with unionizing the dpll_hw_state later. Signed-off-by:
-
Ville Syrjälä authored
Rename all the ye olde 'pipe_config's to the modern 'crtc_state' name in the legacy DPLL code. Signed-off-by:
-
Ville Syrjälä authored
We are alreayd passing the crtc_state to *_crtc_clock_get(). Passing the crtc as well is 100% redundant, so don't do it. Signed-off-by:
-
Ville Syrjälä authored
Drop the redundant 'dev' argument from i9xx_pll_refclk() and rename its variables to conform to modern standards. Signed-off-by:
-
Ville Syrjälä authored
Now that *_compute_dpll() are no longer a mess {i9xx,ilk}_update_pll_dividers() don't serve any real purpose anymore. Just inline them into the callers. Signed-off-by: -
Ville Syrjälä authored
The *_compute_dpll() functions generally contain two things: - huge pile of inline code to calculate the DPLL register value - a few calls to helpers to calculate the DPLL_MD and FP register values Pull the DPLL register value calculations into a helpers as well, so that *_compute_dpll() can focus on higher level tasks. Signed-off-by:
-
Ville Syrjälä authored
We have three copies of the DPLL_MD value computation. Share it. Signed-off-by:
-
Ville Syrjälä authored
Stop rummaging around inside pll->state directly in the low level pll->enable() functions, and instead let the higher level code figure out where the correct state is stored and pass it in. Signed-off-by:
-
