summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-19drm/dp_mst: Add drm_dp_mst_aux_for_parent()Imre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@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/20240416221010.376865-10-imre.deak@intel.com
2024-04-19drm/dp_mst: Factor out drm_dp_mst_port_is_logical()Imre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@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/20240416221010.376865-9-imre.deak@intel.com
2024-04-19drm/dp: Add drm_dp_128b132b_supported()Imre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> 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/20240417141936.457796-1-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limitImre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-7-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Account with the DSC DPT bpp limit on MTLImre Deak
The DPT/DSC bpp limit should be accounted for on MTL platforms as well, do so. Bspec: 49259 Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-6-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp limitImre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-5-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bppImre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-4-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limitImre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-3-imre.deak@intel.com
2024-04-19drm/i915/dp: Fix DSC line buffer depth programmingImre Deak
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: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Manasi Navare <navaremanasi@chromium.org> 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/20240416221010.376865-2-imre.deak@intel.com
2024-04-19drm/i915/display: force qgv check after the hw state readoutVinod Govindapillai
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
2024-04-19drm/i915/display: handle systems with duplicate psf gv pointsStanislav Lisovskiy
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: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-6-vinod.govindapillai@intel.com
2024-04-19drm/i915/display: Disable SAGV on bw init, to force QGV point recalculationStanislav Lisovskiy
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: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-5-vinod.govindapillai@intel.com
2024-04-19drm/i915/display: extract code to prepare qgv points maskVinod Govindapillai
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: 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-4-vinod.govindapillai@intel.com
2024-04-19drm/i915/display: Extract code required to calculate max qgv/psf gv pointStanislav Lisovskiy
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: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-3-vinod.govindapillai@intel.com
2024-04-19drm/i915/display: Add meaningful traces for QGV point info error handlingStanislav Lisovskiy
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: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-2-vinod.govindapillai@intel.com
2024-04-18drm/i915/dmc: use struct intel_display moreJani Nikula
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 <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/06bc9fd9d0472e899bd9d50f3b10a6066c1a0238.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/de: allow intel_display and drm_i915_private for de functionsJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1b0e8e7c732535e18c8498a2e18fe1e4c123e2f5.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/dmc: convert dmc wakelock interface to struct intel_displayJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3c260bbbce0af8714b07157dc032b038efa3bf1c.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/display: rename __intel_wait_for_register_nowl() to indicate intel_de_Jani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/967d3fc67a9053f7d5f9c03010fd5f94dc8d547d.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/quirks: convert struct drm_i915_private to struct intel_displayJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d90e9d8e91e59d04d38f2743c02c74a8f0e13133.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/display: accept either i915 or display for feature testsJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bed78da39e6bd1587db4dab820602c55c63cdd6a.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915: add generic __to_intel_display()Jani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a999ff8183659a4df68d439ebd31c19b5c56852a.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/display: add generic to_intel_display() macroJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/02cf407961200db4379370856c779ea62b3eaa90.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915/display: add intel_display -> drm_device backpointerJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/47dd7bc4aae3c10b18097824e37617c072c66c0b.1713358679.git.jani.nikula@intel.com
2024-04-18drm/i915: use system include for drm headersJani Nikula
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed02b81fcbbc0d27be4af460c521aefbfdc76375.1712743191.git.jani.nikula@intel.com
2024-04-18drm/i915: limit eDP MSO pipe only for display version 20 and belowLuca Coelho
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404091646.165309-1-luciano.coelho@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Suck snps/cx0 PLL states into dpll_hw_stateVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-19-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Unionize dpll_hw_stateVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-18-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Carve up struct intel_dpll_hw_stateVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-17-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Add local DPLL 'hw_state' variablesVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-16-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: s/pipe_config/crtc_state/ in legacy PLL codeVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-15-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Drop pointless 'crtc' argument from *_crtc_clock_get()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Modernize i9xx_pll_refclk()Ville Syrjälä
Drop the redundant 'dev' argument from i9xx_pll_refclk() and rename its variables to conform to modern standards. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Inline {i9xx,ilk}_update_pll_dividers()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Extract {i9xx,i8xx,ilk,vlv,chv}_dpll()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Extract i965_dpll_md()Ville Syrjälä
We have three copies of the DPLL_MD value computation. Share it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Pass the PLL hw_state to pll->enable()Ville Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Extract i9xx_dpll_get_hw_state()Ville Syrjälä
Start making the GMCH DPLL code a bit more like the more modern platforms by separating out the DPLL hw state readout from the rest of the pipe readout. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Extract ilk_dpll_compute_fp()Ville Syrjälä
Let's not repeat ourselves so much and pull the entire PCH DPLL FP register value calculation into its own function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Extract ilk_fb_cb_factor()Ville Syrjälä
Pull the code to calculate PCH DPLL tuning factor into its own function. Helps declutter ilk_update_pll_dividers(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Introduce some local PLL state variablesVille Syrjälä
Spinkle local PLL hw_state variables into various low level PLL functions. Will make subsequent changes cleaner when we don't have to touch so many places when renaming struct members and whatnot. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Rename PLL hw_state variables/argumentsVille Syrjälä
We have zero consistency in out PLL state naming scheme. Try to unify things a bit by using 'dpll_hw_state' for high level stuff and just 'hw_state' for low level stuff. Currently both are the same, but I want to unionize intel_dpll_hw_state at which point using different names can make it more clear whether we're talking about the whole union or just the embedded platform specific struct. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Use printer for the rest of PLL debugfs dumpVille Syrjälä
Since we now have the printer around for intel_dpll_dump_hw_state() use it for all the other PLL prints as well. Just to make the thing looks less crazy. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915: Replace hand rolled PLL state dump with intel_dpll_dump_hw_state()Ville Syrjälä
Just use intel_dpll_dump_hw_state() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915/display: tie DMC wakelock to DC5/6 state transitionsLuca Coelho
We only need DMC wakelocks when we allow DC5 and DC6 states. Add the calls to enable and disable DMC wakelock accordingly. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-5-luciano.coelho@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915/display: add module parameter to enable DMC wakelockLuca Coelho
This feature should be disabled by default until properly tested and mature. Add a module parameter to enable the feature for testing, while keeping it disabled by default for now. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-4-luciano.coelho@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915/display: don't allow DMC wakelock on older hardwareLuca Coelho
Only allow running DMC wakelock code if the display version is 20 or greater. Also check if DMC is loaded before enabling. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-3-luciano.coelho@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-17drm/i915/display: add support for DMC wakelocksLuca Coelho
In order to reduce the DC5->DC2 restore time, wakelocks have been introduced in DMC so the driver can tell it when registers and other memory areas are going to be accessed and keep their respective blocks awake. Implement this in the driver by adding the concept of DMC wakelocks. When the driver needs to access memory which lies inside pre-defined ranges, it will tell DMC to set the wakelock, access the memory, then wait for a while and clear the wakelock. The wakelock state is protected in the driver with spinlocks to prevent concurrency issues. BSpec: 71583 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-2-luciano.coelho@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-12drm/i915: Allow bigjoiner for MSTVidya Srinivas
We need bigjoiner support with MST functionality for MST monitor resolutions > 5K to work. Adding support for the same. v2: Addressed review comments from Jani. Revert rejection of MST bigjoiner modes and add functionality v3: Fixed pipe_mismatch WARN for mst_master_transcoder Credits-to: Manasi Navare <navaremanasi@chromium.org> v4: Utilize intel_crtc_joined_pipe_mask() also for handling bigjoiner slave pipes for MST case(Stan) [v5: vsyrjala: chunked the modeset squence stuff out, removed bogus mst master transcoder hack, keep mgr_lock near the full_pbn check] [v6: vsyrjala: Calculate DSC slices correctly for bigjoiner (Imre)] Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-7-ville.syrjala@linux.intel.com
2024-04-12drm/i915/mst: Add bigjoiner handling to MST modeset sequenceVille Syrjälä
Loop over all joined pipes at relevant points in the MST modeset sequence. Carved out from Vidya's earlier big patch, with naming/etc. changed to match the earlier hsw_crtc_enable() stuff. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Co-developed-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-6-ville.syrjala@linux.intel.com
generated by cgit (git 2.34.1) at 2025-09-08 18:27:58 +0000