- 11 Mar, 2024 7 commits
-
-
Radhakrishna Sripada authored
MTL/LNL use the same cdclk functions as RPLU albeit with different tables. Having separate tables and not requiring special handling for the platforms, reuse RPLU cdclk functions. v2: Update subject and the commit message(Jani) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228214854.2530205-1-radhakrishna.sripada@intel.com
-
Radhakrishna Sripada authored
Make debugfs vbt only shows valid vbt when read from ACPI opregion. Make it work when read from firmware/spi/pci oprom cases. In the cases where VBT needs to be read from spi/pci oprom, take the wakeref to prevent WARN while reading DE registers during debugfs vbt dump. v2: Extract getting vbt from different sources to its own function. Protect sysfs write with vbt check(Jani) v3: Fix CI error by probing bios vbt with runtime_pm wakeref v4: Update commit message and skip waking up runtime while accessing vbt from opregion/firmware(Jani) v5: Skip grabbing unnecessary wakeref(Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Radhakrishna Sripada authored
In the case of vbt residing in opregion, we simply remap the region into the kernel and pass the memory reference. Instead duplicate the memory to handle a saner cleanup in intel_bios_init. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
We want to later change intel_opregion_get_vbt to duplicate the vbt memory if present, which would be an overkill when we just want to peek into the presence of opregion vbt. Carve out the presence check into its own function to use in places where only the presence of vbt is required. Suggested-by:
-
Radhakrishna Sripada authored
VBT read from firmware is currently nested within opregion vbt read. Extract it and place it together with other vbt read mechanisms and dis-associate vbt-firmware from opregion structure. v2: Return NULL in failure cases and use a null check in intel_bios_init(Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Radhakrishna Sripada authored
spi_oprom_get_vbt will later be used to show the contents of vbt for which the size of vbt is needed. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
oprom_get_vbt will later be used to show the contents of vbt for which the size of vbt is needed. v2: Avoid overuse of *size and remove dummy size variable in intel_bios_init(Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 08 Mar, 2024 3 commits
-
-
Ville Syrjälä authored
Stop passing in so much redundant stuff to intel_old_crtc_state_disables(). Top level atomic state + crtc is all we need. And while at it constify the states to make it clear they should not be mutated. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240305084730.19182-4-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Follow in the footsteps of commit c610e841 ("drm/i915: Do plane/etc. updates more atomically across pipes") and do the plane disables back to back for all pipes also when we are disabling pipes. This should provide for a potentially more atomic user experience, which might be especially nice when using joiner or tiled displays. Signed-off-by:
-
Ville Syrjälä authored
Copy the pipe bitmask based approach from skl_commit_modeset_enables() into intel_commit_modeset_disables(). This avoids doing so many duplicated checks in all the loops, and also let's WARN at the end if we screwed up somewhere and forgot to disable some pipe. Signed-off-by:
-
- 07 Mar, 2024 12 commits
-
-
Ville Syrjälä authored
Move all DPFC_CHICKEN programming into intel_fbc_program_workarounds(). We already have one thing programmed there, whereas the rest is strewn about in intel_display_wa_apply() and init_clock_gating(). Since we have a single place doing all the programming (and it's serialized by the crtc commits) there should be no danger of rmw races. Other FBC related workarounds also exist, but those require fiddling with other registers that may also get programmed from other places, so we'll need to think harder what to do with those. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com>
-
Ville Syrjälä authored
No point in wasting a fence on a plane if it can't do FBC anyway. Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com>
-
Ville Syrjälä authored
Drop the pointless phy/port detour from the eDP handling in icl_combo_phy_aux_power_well_enable(). We can just directly consult the dig_port and determine whether it's eDP or not. This also removes the assumption that port==phy, although that is always trued on ICL, so it wasn't really doing any harm. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
We don't actually know whether we should be picking the PHY simply based on the AUX_CH/power well, or based on the VBT defined AUX_CH->DDI->PHY relationship. At the moment we are doing the former for the ANAOVRD workaround, and the latter for the ICL_LANE_ENABLE_AUX override. Windows seems to use the first approach for everything. So let's unify this to follow that same approach for both. Eventually we should try to figure out which is actually correct, or whether any of this even matters (ie. whether there are any real machines where the DDI and its AUX_CH do not match 1:1). Note that this also changes the behaviour if we do end up poking an AUX power well not associated with any port (as per VBT). Previously we would have skipped the PHY register write, but now we always write it. Signed-off-by:
-
Ville Syrjälä authored
Modernize the ICL+ combo PHY register refinitions by using REG_BIT() & co. Signed-off-by:
-
Ville Syrjälä authored
ICL_AUX_ANAOVRD1 is actually ICL_PORT_TX_DW6_AUX. Give it its proper name, and relocate to the correct file (intel_combo_phy_regs.h). Signed-off-by:
-
Ville Syrjälä authored
Bspec asks us to always set the DSB_SKIP_WAITS_EN bit in DSB_CHICKEN. This seems to instruct DSB to skip vblank and scanline waits when PSR is entered. I don't think we have any cases currently where we would want to enter PSR while DSB is waiting for something, but let's set the bit anyway to align with Bspec's wishes. Signed-off-by:
Animesh Manna <animesh.manna@intel.com>
-
Ville Syrjälä authored
Looks like the undelayed vblank gets signalled exactly when the active period ends. That is a problem for DSB+VRR when we are already in vblank and expect DSB to start executing as soon as we send the push. Instead of starting, the DSB just keeps on waiting for the undelayed vblank which won't signal until the end of the next frame's active period, which is far too late. The end result is that DSB won't have even started executing by the time the flips/etc. have completed. We then wait for an extra 1ms, after which we terminate the DSB and report a timeout: [drm] *ERROR* [CRTC:80:pipe A] DSB 0 timed out waiting for idle (current head=0xfedf4000, head=0x0, tail=0x1080) To fix this let's configure DSB to use the so called VRR "safe window" instead of the undelayed vblank to trigger the DSB vblank logic, when VRR is enabled. Cc: stable@vger.kernel.org Fixes: 34d8311f ("drm/i915/dsb: Re-instate DSB for LUT updates") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9927Signed-off-by:
-
Ville Syrjälä authored
Looks like TRANS_CHICKEN bit 31 means something totally different depending on the platform: TGL: generate VRR "safe window" for DSB ADL/DG2: make TRANS_SET_CONTEXT_LATENCY effective with VRR So far we've only set this on ADL/DG2, but when using DSB+VRR we also need to set it on TGL. And a quick test on MTL says it doesn't need this bit for either of those purposes, even though it's still documented as valid in bspec. Cc: stable@vger.kernel.org Fixes: 34d8311f ("drm/i915/dsb: Re-instate DSB for LUT updates") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9927Signed-off-by:
-
Bhanuprakash Modem authored
Remove duplicate checks for debugfs entry "DRRS capable:". Fixes: 20af1084 ("drm/i915/display/debugfs: New entry "DRRS capable" to i915_drrs_status") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by:
-
Bhanuprakash Modem authored
Rename cpu_transcoder_has_drrs() to intel_cpu_transcoder_has_drrs() and move it to intel_drrs.[ch]. V2: - Move helpers to intel_drrs.[ch] (Jani) - Fix commit message (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Reinstate commit 88b06594 ("drm/i915/dsi: Do display on sequence later on icl+"), for the most part. Turns out some machines (eg. Chuwi Minibook X) really do need that updated order. It is also the order the Windows driver uses. However we can't just undo the revert since that would again break Lenovo 82TQ. After staring at the VBT sequences for both machines I've concluded that the Lenovo 82TQ sequences look somewhat broken: - INIT_OTP is not present at all - what should be in INIT_OTP is found in DISPLAY_ON - what should be in DISPLAY_ON is found in BACKLIGHT_ON (along with the actual backlight stuff) The Chuwi Minibook X on the other hand has a full complement of sequences in its VBT. So let's try to deal with the broken sequences in the Lenovo 82TQ VBT by simply swapping the (non-existent) INIT_OTP sequence with the DISPLAY_ON sequence. Thus we execute DISPLAY_ON when intending to execute INIT_OTP, and execute nothing at all when intending to execute DISPLAY_ON. That should be 100% equivalent to the revert, for such broken VBTs. Cc: stable@vger.kernel.org Fixes: dc524d05 ("Revert "drm/i915/dsi: Do display on sequence later on icl+"") References: https://gitlab.freedesktop.org/drm/intel/-/issues/10071 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10334Signed-off-by:
-
- 06 Mar, 2024 2 commits
-
-
Juha-Pekka Heikkila authored
AuxCCS framebuffers don't work on Xe driver hence disable them from plane capabilities until they are fixed. FlatCCS framebuffers work and they are left enabled. CCS is left untouched for i915 driver. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/933Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Tested-by:
-
Ville Syrjälä authored
Looks like I misplaced a few hunks when I moved the audio enable/disable out from the encoder enable/disable hooks. So we are now doing a double audio enable/disable on SDVO and g4x+ DP. Probably harmless as doing it twice shouldn't really change anything, but let's do it just once, as intended. Fixes: cff742cc ("drm/i915: Hoist the encoder->audio_{enable,disable}() calls higher up") Signed-off-by:
-
- 05 Mar, 2024 1 commit
-
-
Imre Deak authored
The DSC HW state of DP connectors is read out during driver loading and system resume in intel_modeset_update_connector_atomic_state(). This function is called for all connectors though and so the state of DSI connectors will also get updated incorrectly, triggering a WARN there wrt. the DSC decompression AUX device. Fix the above by moving the DSC state readout to a new DP connector specific sync_state() hook. This is anyway the logical place to update the connector object's state vs. the connector's atomic state. Fixes: b2608c6b ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by:
Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.orgReviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
- 04 Mar, 2024 2 commits
-
-
Imre Deak authored
Fix the documentation issues below, also reported by 'make htmldocs': drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or struct member 'tunnel' not described in 'drm_dp_tunnel_put' drivers/gpu/drm/display/drm_dp_tunnel.c:447: warning: Function parameter or struct member 'tracker' not described in 'drm_dp_tunnel_put' drivers/gpu/drm/display/drm_dp_tunnel.c:1185: warning: expecting prototype for drm_dp_tunnel_atomic_get_allocated_bw(). Prototype was for drm_dp_tunnel_get_allocated_bw() instead drivers/gpu/drm/display/drm_dp_tunnel.c:1903: warning: Function parameter or struct member 'max_group_count' not described in 'drm_dp_tunnel_mgr_create' Fixes: 295654f7 ("drm/dp: Add support for DP tunneling") Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Arthur Grillo authored
The drm_rect_intersect() already returns if the intersection is visible or not, so the use of drm_rect_visible() is duplicate. Signed-off-by:
Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by:
-
- 01 Mar, 2024 2 commits
-
-
Nirmoy Das authored
Add missing doc for struct drm_i915_reset_stats. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229132918.10205-1-nirmoy.das@intel.com
-
Animesh Manna authored
Move psr_init_dpcd() from init-connector to connector-detect function. The dpcd probe for checking panel replay capability for external dp connector is causing delay during boot which can be optimized by moving dpcd probe to connector specific detect(). v1: Initial version. v2: Add details in commit description. [Jani] Suggested-by:
-
- 29 Feb, 2024 7 commits
-
-
Ville Syrjälä authored
Just return the correct thing from within the loop to make the code more readable. We have no ref counts/etc. to deal with here so no point in breaking from the loop just to return something. Signed-off-by:
-
Ville Syrjälä authored
The icl+ power well code currently assumes that every AUX power well maps to an encoder which is using said power well. That is by no menas guaranteed as we: - only register encoders for ports declared in the VBT - combo PHY HDMI-only encoder no longer get an AUX CH since commit 9856308c ("drm/i915: Only populate aux_ch if really needed") However we have places such as intel_power_domains_sanitize_state() that blindly traverse all the possible power wells. So these bits of code may very well encounbter an aux power well with no associated encoder. In this particular case the BIOS seems to have left one AUX power well enabled even though we're dealing with a HDMI only encoder on a combo PHY. We then proceed to turn off said power well and explode when we can't find a matching encoder. As a short term fix we should be able to just skip the PHY related parts of the power well programming since we know this situation can only happen with combo PHYs. Another option might be to go back to always picking an AUX CH for all encoders. However I'm a bit wary about that since we might in theory end up conflicting with the VBT AUX CH assignment. Also that wouldn't help with encoders not declared in the VBT, should we ever need to poke the corresponding power wells. Longer term we need to figure out what the actual relationship is between the PHY vs. AUX CH vs. AUX power well. Currently this is entirely unclear. Cc: stable@vger.kernel.org Fixes: 9856308c ("drm/i915: Only populate aux_ch if really needed") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184Signed-off-by:
-
Christophe JAILLET authored
'name' may still be "intel_backlight" when backlight_device_register() is called. In such a case, using kstrdup_const() saves a memory duplication when dev_set_name() is called in backlight_device_register(). Use kfree_const() accordingly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Jani Nikula authored
Add a function to return the expected child device size. Flip the if ladder around and use the same versions as in documentation to make it easier to verify. Return an error for unknown versions. No functional changes. v2: Move BUILD_BUG_ON() next to the expected sizes Reviewed-by:
-
Jani Nikula authored
Separate the child device size check to a separate function for clarity. No functional changes. Reviewed-by:
-
Jani Nikula authored
VBT versions since 256 have an extra byte for EFP index. v2: Update BUILD_BUG_ON() (Matt) Reviewed-by:
-
Jani Nikula authored
Sync to get the drm_printer changes to drm-intel-next. Signed-off-by:
-
- 28 Feb, 2024 4 commits
-
-
Gustavo Sousa authored
Improve documentation by giving an overview of the components involved in the generation of the CDCLK. v2: Fix htmldoc error because of missing blank line at the start of bulleted list. Reviewed-by:Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221185131.287302-2-gustavo.sousa@intel.com
-
Gustavo Sousa authored
Looks like the name and description of intel_cdclk_needs_modeset() became inaccurate as of commit 59f9e9ca ("drm/i915: Skip modeset for cdclk changes if possible"), when it became possible to update the cdclk without requiring disabling the pipes when only changing the cd2x divider was enough. Later on we also added the same type of support with squash and crawling with commit 25e0e5ae ("drm/i915/display: Do both crawl and squash when changing cdclk"), commit d4a23930 ("drm/i915: Allow cdclk squasher to be reconfigured live") and commit d62686ba ("drm/i915/adl_p: CDCLK crawl support for ADL"). As such, update that function's name and documentation to something more appropriate, since the real checks for requiring modeset are done elsewhere. v2: - Rename to intel_cdclk_clock_changed instead of intel_cdclk_params_changed. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a drm_dbg_kms message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228092042.4125617-1-colin.i.king@gmail.comSigned-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2024-02-27-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull #2 for v6.9: Features and functionality: - DP tunneling and bandwidth allocation support (Imre) - Add more ADL-N PCI IDs (Gustavo) - Enable fastboot also on older platforms (Ville) - Bigjoiner force enable debugfs option for testing (Stan) Refactoring and cleanups: - Remove unused structs and struct members (Jiri Slaby) - Use per-device debug logging (Ville) - State check improvements (Ville) - Hardcoded cd2x divider cleanups (Ville) - CDCLK documentation updates (Ville, Rodrigo) Fixes: - HDCP MST Type1 fixes (Suraj) - Fix MTL C20 PHY PLL values (Ravi) - More hardware access prevention during init (Imre) - Always enable decompression with tile4 on Xe2 (Juha-Pekka) - Improve LNL package C residency (Suraj) drm core changes: - DP tunneling and bandwidth allocation helpers (Imre) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87sf1devbj.fsf@intel.com
-
