- 08 Nov, 2023 2 commits
-
-
Ville Syrjälä authored
The current code does '(bpp << 4) / 16' in the MST PBN calculation, but that is just the same as 'bpp' so the DSC codepath achieves absolutely nothing. Fix it up so that the fractional part of the bpp value is actually used instead of truncated away. 64*1006 has enough zero lsbs that we can just shift that down in the dividend and thus still manage to stick to a 32bit divisor. And while touching this, let's just make the whole thing more straightforward by making the passed in bpp value .4 binary fixed point always, instead of having to pass in different things based on whether DSC is enabled or not. v2: - Fix DSC kunit test cases. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: dc48529f ("drm/dp_mst: Add PBN calculation for DSC modes") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [Imre: Fix kunit test cases] Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-3-imre.deak@intel.com
-
Imre Deak authored
After drm_connector_init() is called the connector is visible to the rest of the kernel via the drm_mode_config::connector_list. Make sure that the DSC AUX device and capabilities are setup by that time. Another race condition is adding the connector to the connector list before drm_connector_helper_add() sets the connector helper functions. That's an unrelated issue, for which the fix is for a follow-up. One solution would be adding the connector to the connector list only during its registration in drm_connector_register(). Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 808b43fa ("drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX") Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
- 07 Nov, 2023 3 commits
-
-
Jani Nikula authored
The gem code has no business accessing i915->display directly. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231102155223.2298316-2-jani.nikula@intel.com
-
Jani Nikula authored
The core code has no business accessing i915->display directly. These could be further spread to respective files, but this is a start. Signed-off-by:
-
Mika Kahola authored
Display driver shall read DPCD 00071h[3:1] during configuration to get PSR setup time. This register provides the setup time requirement on the VSC SDP entry packet. If setup time cannot be met with the current timings (e.g., PSR setup time + other blanking requirements > blanking time), driver should enable sending VSC SDP one frame earlier before sending the capture frame. BSpec: 69895 (PSR Entry Setup Frames 17:16) v2: Write frames before su entry to correct register (Ville, Jouni) Move frames before su entry calculation to it's own function (Ville, Jouni) Rename PSR Entry Setup Frames register to indicate Lunarlake specificity (Jouni) v3: Modify setup entry frames calculation function to return the actual frames (Ville) Match comment with actual implementation (Jouni) v4: Drop "set" from function naming (Jouni, Ville) Use i915 instead of dev_priv (Jouni) Signed-off-by:Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231106114228.146574-1-mika.kahola@intel.com
-
- 06 Nov, 2023 10 commits
-
-
Imre Deak authored
Enabling DSC on ICL MST outputs is broken leading to FIFO pipe / transcoder underruns and blank screen. On TGL+ platforms MST/DSC works - after fixing the known issues in [1] - however to make this work on ICL requires more work. So far DSC on MST probably didn't get enabled for users - due to an issue fixed by [2] - but after fixing that, DSC could get enabled, leading to a blank screen in ICL/MST configurations which do work atm. To prevent this disable MST/DSC on ICL for now. [1] https://lore.kernel.org/all/20231030155843.2251023-1-imre.deak@intel.com [2] https://lore.kernel.org/all/20231030155843.2251023-31-imre.deak@intel.com v2 (Ville): - Use DISPLAY_VER >= 12 instead of > 11. - Explain the ICL DSC issue in code comment. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Nirmoy Das authored
Fix below compiler warning: intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] "%c/TC#%d", port_name(port), tc_port + 1); ^~ intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 8 snprintf(tc->port_name, sizeof(tc->port_name), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%c/TC#%d", port_name(port), tc_port + 1); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v2: use kasprintf(Imre) v3: use const for port_name, and fix tc mem leak(Imre) Fixes: 3eafcddf ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Iterators operate on struct intel_gt so lets move it to intel_gt.h in order to make i915_drv.h less of a dumping ground for stuff. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Unused macro after 99919be7 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by:
-
Ville Syrjälä authored
The code to determine the pre-ICL DSI port control register is repeated several times. Consolidate. vlv_dsi_clear_device_ready() is left with the open-coded version due to the weirdness with port A vs. C on VLV/CHV. Signed-off-by:
-
Ville Syrjälä authored
GLK has its own glk_dsi_clear_device_ready() so remove the dead GLK checks from vlv_dsi_clear_device_ready(). Sadly BXT still uses vlv_dsi_clear_device_ready() so the code still looks like a mess due to the difference in VLV/CHV vs. BXT port A/C shenanigans. Signed-off-by:
-
Ville Syrjälä authored
Stop repeating the same logic to determine the correct config space register for MCHBAR. Signed-off-by:
-
Ville Syrjälä authored
'reg' is a very non-descriptive name. Just get rid of the silly local variable and spell out the full register name always. Signed-off-by:
-
Ville Syrjälä authored
We have the same code to determine the CHICKEN_TRANS register offset sprinkled in a dozen places. Hoover it up into a small helper. TODO: find a better home for this Signed-off-by:
-
Jouni Högander authored
We are preparing for Xe. Xe_bo doesn't have obj->base. Due to this use intel_bo_to_drm_bo instead in intel_prepare_plane_fb. Signed-off-by:
-
- 03 Nov, 2023 1 commit
-
-
Ville Syrjälä authored
On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing the audio hardware. Currently we bump the CDCLK frequency up temporarily (if not high enough already) whenever audio hardware is being accessed, and drop it back down afterwards. With a single active pipe this works just fine as we can switch between all the valid CDCLK frequencies by changing the cd2x divider, which doesn't require a full modeset. However with multiple active pipes the cd2x divider trick no longer works, and thus we end up blinking all displays off and back on. To avoid this let's just bump the CDCLK frequency to >=2*96MHz whenever multiple pipes are active. The downside is slightly higher power consumption, but that seems like an acceptable tradeoff. With a single active pipe we can stick to the current more optiomal (from power comsumption POV) behaviour. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9599Signed-off-by:
-
- 02 Nov, 2023 1 commit
-
-
Jouni Högander authored
We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence implementation. Lets drop i915_sw_fence usage from display code and use dma_fence interfaces directly. For this purpose stack dma fences from related objects into new plane state. Drm_gem_plane_helper_prepare_fb can be used for fences in new fb. Separate local implementation is used for Stacking fences from old fb into new plane state. Then wait for these stacked fences during atomic commit. There is no be need for separate GPU reset handling in intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is detected and GPU is being reset. v4: - Drop to_new_plane_state suffix from add_dma_resv_fences - Use dma_resv_usage_rw(false) (DMA_RESV_USAGE_WRITE) v3: - Rename add_fences and it's parameters - Remove signaled check - Remove waiting old_plane_state fences v2: - Add fences from old fb into new_plane_state->uapi.fence rather than into old_plane_state->uapi.fence Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
- 01 Nov, 2023 4 commits
-
-
Ville Syrjälä authored
Since we're asked to disable FECSTALL_DIS_DPTSTREAM_DPTTG when the transcoder is disabled it seems prudent to also clear it when enabliing the transcoder w/o FEC, just in case someone else left it enabled by mistake. Signed-off-by:
-
Ville Syrjälä authored
Follow the bspec sequence more closely and clear ACT sent just before triggering the allocation. Can't see why we'd want to deviate from the spec sequence here. Signed-off-by:
-
Ville Syrjälä authored
Bspec tells us that we should disable the transcoder before deleting the payload. Looks like this has been reversed since MST support was added. I suppose this shouldn't matter in practice since the downstream device shouldn't really do anything with the new payload until we send the ACT. But I see no compelling reason to deviate from the bspec sequence regardless. Signed-off-by:
-
Ville Syrjälä authored
The DP modeset sequence asks us to disable TRANSCONF before clearing the FECSTALL_DIS_DPTSTREAM_DPTTG bit, although we are still asked to wait for the transcoder to stop only after both steps have been done. Signed-off-by:
-
- 31 Oct, 2023 10 commits
-
-
Nirmoy Das authored
Handle platforms with multiple GTs by iterate over all GTs. Add a Fixes commit so this gets propagated for MTL support. Fixes: 213c4367 ("drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake") Suggested-by:
John Harrison <john.c.harrison@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
-
Suraj Kandpal authored
When we dock a monitor we end up with a enable and disable connector cycle but if hdcp content is running we get the userspace in enabled state and driver maintaining a undesired state which causes the content to stop playing and we only enable hdcp if the userspace state in desired. This patch fixes that. --v2 -Move code to intel_hdcp [Jani] Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Let's convert intel_hdcp_enable to a blanket function which just has some conditions which needs to be checked before connectors enable hdcp. This cleans up code and avoids code duplication. --v3 -Keep function name as intel_hdcp_enable() [Jani] Signed-off-by:
-
Suraj Kandpal authored
Rename hdcp 1.4 enablement function from _intel_hdcp_enable to intel_hdcp1_enable to better represent what version of hdcp is being enabled Signed-off-by:
-
Ville Syrjälä authored
We are asked to reprogram PEG_BAND_GAP_DATA prior to enabling hotplug detection on the g45 HDMI/DP ports. Currently we do said reprogamming from the DP/HDMI connector initialization functions. That code should be mostly platform agnostic so clearly not the best place for this. Move the workaround to the place where we actually enable HPD detection. Signed-off-by:
-
Ville Syrjälä authored
We have a bit of duplicated code around the DPLL disabling. Extract that to a new function, and for symmetry also do the same for the enable direction. Signed-off-by:
-
Ville Syrjälä authored
The extra DPLL power domain is currently handled in three places: - combo_pll_enable() - combo_pll_disable() - readout_dpll_hw_state() First two of those are low level PLL funcs, but the third is a higher level thing. So the current situation is rather inconsistent. Unify this by moving the PLL enable/disable up one level. This also means the extra power domain could be trivially be used by other platforms as well. Signed-off-by:
-
Ville Syrjälä authored
Just include the JSL/EHL DPLL4 extra power domain in the dpll_info struct. This way the same approach could be used by other platforms as well (should the need arise), and we don't have to sprinkle platform checks all over the place. Note that I'm perhaps slightly abusing things here as power_domain==0 (which is actually POWER_DOMAIN_DISPLAY_CORE) now indicates that no extra power domain is needed. I suppose using POWER_DOMAIN_INVALID would be more correct, but then we'd have to sprinkle that to all the other DPLLs. Signed-off-by:
-
Ville Syrjälä authored
Use named initializers when populating the DPLL info. This is just more convenient and less error prone as we no longer have to keep the initializers in a specific order. Signed-off-by:
-
Ville Syrjälä authored
Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with a VBT inherited from some earlier HSW model. On HSW the HDMI level shift value could go up to 11, whereas on BDW the maximum value is 9. The DDI code does clamp the bogus value, but it does so with a WARN which we don't really want. To avoid that let's just sanitize the bogus VBT HDMI level shift value ahead of time for all BDW machines. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9461Signed-off-by:
-
- 30 Oct, 2023 3 commits
-
-
Jani Nikula authored
Keep the display build lists together. v2: Rebase Reviewed-by:
-
Jani Nikula authored
Unify the line continuations and indents, and sort the build lists. Reviewed-by:
-
Chaitanya Kumar Borah authored
eDP specification supports HBR3 link rate since v1.4a. Moreover, C10 phy can support HBR3 link rate for both DP and eDP. Therefore, do not clamp the supported rates for eDP at 6.75Gbps. Cc: <stable@vger.kernel.org> BSpec: 70073 74224 Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
-
- 29 Oct, 2023 4 commits
-
-
Lucas De Marchi authored
As done with the hw readout, properly abstract the C10/C20 phy details inside intel_cx0_phy.c. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231018222831.4132968-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
intel_cx0_phy.[ch] should contain the details about C10/C20, not leaking it to the rest of the driver. Start abstracting this by exporting a single PLL hw readout that handles the differences between C20 and C10 internally to that compilation unit. Signed-off-by:
-
Lucas De Marchi authored
With MTL adding PICA between the port and the real phy, the path add for DG2 stopped being followed and newer platforms are simply using the older path for TC phys. LNL is no different than MTL in this aspect, so just add it to the mess. In future the phy and port designation and deciding if it's TC should better be cleaned up. To make it just a bit better, also change intel_phy_is_snps() to show this is DG2-only. Signed-off-by:
-
Lucas De Marchi authored
For Lunar Lake, DDI-A is connected to C10 PHY, while TC1-TC3 are connected to C20 phy, like in Meteor Lake. Update the check in intel_is_c10phy() accordingly. This reverts the change in commit e388ae97 ("drm/i915/display: Eliminate IS_METEORLAKE checks") that turned that into a display engine version check. The phy <-> port connection is very SoC-specific and not related to that version. IS_LUNARLAKE() is defined to 0 in i915 as it's expected that the (upcoming) xe driver is the one defining the platform, with i915 only driving the display side. Bspec: 70818 Reviewed-by:
-
- 27 Oct, 2023 1 commit
-
-
Jani Nikula authored
Move sprite_name() where its only user is, and convert it to a function, removing the implicit dev_priv usage. Signed-off-by:
-
- 26 Oct, 2023 1 commit
-
-
Mika Kahola authored
Every know and then we receive the following error when running for example IGT test kms_flip. [drm] *ERROR* PHY G Read 0d80 failed after 3 retries. [drm] *ERROR* PHY G Write 0d81 failed after 3 retries. Since the error is sporadic in nature, the patch proposes to reset the message bus after every successful or unsuccessful read or write operation. v2: Add FIXME's to indicate the experimental nature of this workaround (Rodrigo) v3: Dropping the additional delay as moving reset to *_read_once() and *_write_once() functions seem unnecessary delay Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231016125544.719963-1-mika.kahola@intel.com
-
