- 14 Mar, 2024 5 commits
-
-
Jouni Högander authored
Increasing number of fast wake sync pulses seem to fix problems with certain PSR panels. This should be ok for other panels as well as the eDP specification allows 10...16 precharge pulses and we are still within that range. v3: mention laptop model and panel manufacturer and model in comment v2: add comment explaining pulse count is increased Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9739Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240313133221.868391-5-jouni.hogander@intel.com
-
Jouni Högander authored
Bspec mentions 50 us for IO wake time and 32 us for fast wake time. 32 us is most probably wrong as it doesn't meet the specification as fast wake time is calculated in Bspec like this: 10..16 us (precharge) + 8 us (preamble) + 4 us (phy_wake) + 20 us (tfw_exit_latency) Instead of using these constants calculate IO wake and fast wake for DISPLAY_VER < 12 as well. v3: - do not handle < 9 separately - add own helper for skl and tgl io buffer wake times v2: - initialize io/fast_wake_time for display version < 9 Signed-off-by:
-
Jouni Högander authored
Current fast and IO wake lines calculation is assuming fast wake sync length is 18 pulses. Let's improve this by checking actual length. Add getter for IO buffer wake time and return 10 us there which was assumed with static 42 us IO wake time. Upcoming patches will extent this for different display versions. Bspec: 65450 v3: - s/get_io_buffer_wake_time/io_buffer_wake_time/ and use it directly in calculation. v2: - rename io_wake_time in if block to io_buffer_wake_time - rename get_io_wake_time to get_io_buffer_wake_time Signed-off-by: -
Jouni Högander authored
ALPM AUX-Wake fast wake sync pulse count is needed by PSR to calculate IO wake and fast wake lines. Convert intel_dp_aux_fw_sync_len as non-static to make it available for PSR code. v2: use int instead of u8 Signed-off-by:
-
Shekhar Chauhan authored
The driver currently waits 1ms for idle patterns, but for Xe2LPD and possibly future display IPs, it requires a 1640us (rounded up to 2ms) timeout whilst waiting for idle patterns for MST streams. To simplify the code, the timeout is uniformly increased by 1ms across all platforms/display IPs. v1: Introduced the 2ms wait timeout. v2: Segregated the wait timeout for platforms before & after LNL. v3: Fixed 2 cosmetic changes. v4: Revert to v2 design with commit message enhancements. v5: Minor cosmetic changes to the commit message. BSpec: 68849 Signed-off-by:
Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240311041504.806058-1-shekhar.chauhan@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 13 Mar, 2024 10 commits
-
-
Janusz Krzysztofik authored
In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an rpm wakeref. That results in lock inversion: <4> [197.079335] ====================================================== <4> [197.085473] WARNING: possible circular locking dependency detected <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted <4> [197.098096] ------------------------------------------------------ <4> [197.104231] prometheus-node/839 is trying to acquire lock: <4> [197.109680] ffffffff82764d80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc+0x9a/0x350 <4> [197.116939] but task is already holding lock: <4> [197.122730] ffff88811b772a40 (&hwmon->hwmon_lock){+.+.}-{3:3}, at: hwm_energy+0x4b/0x100 [i915] <4> [197.131543] which lock already depends on the new lock. ... <4> [197.507922] Chain exists of: fs_reclaim --> >->reset.mutex --> &hwmon->hwmon_lock <4> [197.518528] Possible unsafe locking scenario: <4> [197.524411] CPU0 CPU1 <4> [197.528916] ---- ---- <4> [197.533418] lock(&hwmon->hwmon_lock); <4> [197.537237] lock(>->reset.mutex); <4> [197.543376] lock(&hwmon->hwmon_lock); <4> [197.549682] lock(fs_reclaim); ... <4> [197.632548] Call Trace: <4> [197.634990] <TASK> <4> [197.637088] dump_stack_lvl+0x64/0xb0 <4> [197.640738] check_noncircular+0x15e/0x180 <4> [197.652968] check_prev_add+0xe9/0xce0 <4> [197.656705] __lock_acquire+0x179f/0x2300 <4> [197.660694] lock_acquire+0xd8/0x2d0 <4> [197.673009] fs_reclaim_acquire+0xa1/0xd0 <4> [197.680478] __kmalloc+0x9a/0x350 <4> [197.689063] acpi_ns_internalize_name.part.0+0x4a/0xb0 <4> [197.694170] acpi_ns_get_node_unlocked+0x60/0xf0 <4> [197.720608] acpi_ns_get_node+0x3b/0x60 <4> [197.724428] acpi_get_handle+0x57/0xb0 <4> [197.728164] acpi_has_method+0x20/0x50 <4> [197.731896] acpi_pci_set_power_state+0x43/0x120 <4> [197.736485] pci_power_up+0x24/0x1c0 <4> [197.740047] pci_pm_default_resume_early+0x9/0x30 <4> [197.744725] pci_pm_runtime_resume+0x2d/0x90 <4> [197.753911] __rpm_callback+0x3c/0x110 <4> [197.762586] rpm_callback+0x58/0x70 <4> [197.766064] rpm_resume+0x51e/0x730 <4> [197.769542] rpm_resume+0x267/0x730 <4> [197.773020] rpm_resume+0x267/0x730 <4> [197.776498] rpm_resume+0x267/0x730 <4> [197.779974] __pm_runtime_resume+0x49/0x90 <4> [197.784055] __intel_runtime_pm_get+0x19/0xa0 [i915] <4> [197.789070] hwm_energy+0x55/0x100 [i915] <4> [197.793183] hwm_read+0x9a/0x310 [i915] <4> [197.797124] hwmon_attr_show+0x36/0x120 <4> [197.800946] dev_attr_show+0x15/0x60 <4> [197.804509] sysfs_kf_seq_show+0xb5/0x100 Acquire the wakeref before the lock and hold it as long as the lock is also held. Follow that pattern across the whole source file where similar lock inversion can happen. v2: Keep hardware read under the lock so the whole operation of updating energy from hardware is still atomic (Guenter), - instead, acquire the rpm wakeref before the lock and hold it as long as the lock is held, - use the same aproach for other similar places across the i915_hwmon.c source file (Rodrigo). Fixes: 1b44019a ("drm/i915/guc: Disable PL1 power limit when loading GuC firmware") Signed-off-by:Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: <stable@vger.kernel.org> # v6.5+ Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Balasubramani Vivekanandan authored
Enable display support for Lunar Lake. Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-9-gustavo.sousa@intel.comSigned-off-by:
-
Balasubramani Vivekanandan authored
Load DMC for Xe2LPD. The value 0x8000 is the maximum payload size for any Xe2LPD DMC firmware. v2: - s/XE2LPD_MAX_FW_SIZE/XE2LPD_DMC_MAX_FW_SIZE/. (Lucas) Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by:
-
Gustavo Sousa authored
Commit 394b4b7d ("drm/i915/lnl: Add CDCLK table") and commit 3d3696c0 ("drm/i915/lnl: Start using CDCLK through PLL") started adding support for CDCLK programming support for Xe2LPD. One final piece is missing, which is the programming necessary for changed in the ratio between MDCLK and CDCLK. Let's do that now. BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the ratio between MDCLK and CDCLK changes. The updates must be done before changing the CDCLK when decreasing the frequency; or after it when increasing the frequency. Ratio-related updates to MBUS_CTL also depend on the state of MBus joining, so they are performed by either CDCLK change sequence or by changes in MBus joining. Since one might happen independently of the other, we need to make sure that both logics see the necessary state values when programming that register. MBus joining logic needs to know the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio field of struct intel_dbuf_state. For the CDCLK logic, we need to have something similar: we need to propagate the status of MBus joining to struct intel_cdclk_state. Do that by adding the field joined_mbus to struct intel_cdclk_config. (Preferably, that field would be added to intel_cdclk_state, however currently only intel_cdclk_config is passed down to the functions that do the register programming. We might revisit this decision if we find that refactoring the code to pass the whole intel_cdclk_state is worth it.) Bspec: 68864, 68868, 69090, 69482 Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Xe2LPD always selects the CDCLK PLL as source for the MDCLK. Because of that, the ratio between MDCLK and CDCLK is not be constant anymore. As such, make sure to have the current ratio available in intel_dbuf_state so that it can be used during dbuf programming. Note that we write-lock the global state instead of serializing to a hardware commit because a change in the ratio should be rather handled in the CDCLK change sequence, which will need to take care of updating the necessary registers in that case. We will implement that in upcoming changes. That said, changes in the MBus joining state should be handled by the DBUF/MBUS logic, just like it is already done, but the logic will need to know the ratio to properly update the registers. v2: - Make first sentence of commit message more intelligible. (Matt) Reviewed-by:
-
Gustavo Sousa authored
As of Xe2LPD, it is now possible to select the source of the MDCLK as either the CD2XCLK or the CDCLK PLL. Previous display IPs were hardcoded to use the CD2XCLK. For those, the ratio between MDCLK and CDCLK remained constant, namely 2. For Xe2LPD, when we select the CDCLK PLL as the source, the ratio will vary according to the squashing configuration (since the cd2x divisor is fixed for all supported configurations). To help the transition to supporting changes in the ratio, extract the function intel_dbuf_mdclk_cdclk_ratio_update() from the existing logic and call it using 2 as hardcoded ratio. Upcoming changes will use that function for updates in the ratio due to CDCLK changes. Bspec: 50057, 69445, 49213, 68868 Reviewed-by:
-
Gustavo Sousa authored
It is no use computing the squash waveform if we are not going to use it. Move the call to cdclk_squash_waveform() inside the block guarded by HAS_CDCLK_SQUASH(dev_priv). v2: - Move "u16 waveform" declaration to inside the block where it is initialized and used. (Matt) Reviewed-by: -
Gustavo Sousa authored
Currently, only Xe2LPD uses CDCLK PLL as the source of MDCLK and previous display IPs use the CD2XCLK. There will be changes in code paths common to those platforms that will rely on which source is being used. As such, let's make that information explicit with the addition of the predicate function mdclk_source_is_cdclk_pll(). Arguably, an enum could be created, but using a boolean should suffice here, since we there are only two possible sources and the logic that will rely on it will be very localized. In order to get the code into a more consistent state, let's also take this opportunity to hook the selection of CDCLK_CTL's "MDCLK Source Select" to that new function. Even though currently only MDCLK_SOURCE_SEL_CDCLK_PLL will be returned, having this extra logic is arguably better than keeping stuff untied and prone to bugs. v2: - Extract mdclk_source_is_cdclk_pll() out of xe2lpd_mdclk_source_sel() to make latter only about the register's field. Bspec: 69090, 68861 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: -
Gustavo Sousa authored
The CDCLK table is tied to Xe2LPD display and not to the platform. Let's rename lnl_cdclk_table to xe2lpd_cdclk_table in order to reflect that. Reviewed-by:
-
Jani Nikula authored
The opregion code needs stubs for ACPI=n. Add the missing stub for intel_opregion_vbt_present(). Reported-by:
Thomas Weißschuh <thomas.weissschuh@linutronix.de> Closes: https://lore.kernel.org/r/20240312120240-afdb1b83-8517-434b-be79-06f41bafd71f@linutronix.de Fixes: 9d9bb71f ("drm/i915: Extract opregion vbt presence check") Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312115757.683584-1-jani.nikula@intel.comSigned-off-by:
-
- 12 Mar, 2024 1 commit
-
-
Imre Deak authored
Commit a62e1459 ("drm/i915/dp: Fix connector DSC HW state readout") moved the DSC HW state readout to a connector specific hook, however only added the hook for DP MST connectors, not for DP SST ones. Fix adding the hook for SST connectors as well. This fixes the following warn on platforms where BIOS enables DSC: [ 66.208601] i915 0000:00:02.0: drm_WARN_ON(!connector->dp.dsc_decompression_aux || !connector->dp.dsc_decompression_enabled) ... [ 66.209024] RIP: 0010:intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.209333] ? intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.210068] intel_disable_ddi+0x135/0x1d0 [i915] [ 66.210302] intel_encoders_disable+0x9b/0xc0 [i915] [ 66.210565] hsw_crtc_disable+0x153/0x170 [i915] [ 66.210823] intel_old_crtc_state_disables+0x52/0xb0 [i915] [ 66.211107] intel_atomic_commit_tail+0x5cf/0x1330 [i915] [ 66.211366] intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211612] ? intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211872] drm_atomic_commit+0x9d/0xd0 [drm] [ 66.211921] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 66.211975] intel_initial_commit+0x1a8/0x260 [i915] [ 66.212234] intel_display_driver_probe+0x2a/0x80 [i915] [ 66.212479] i915_driver_probe+0x7c6/0xc60 [i915] [ 66.212664] ? drm_privacy_screen_get+0x168/0x190 [drm] [ 66.212711] i915_pci_probe+0xe2/0x1c0 [i915] Fixes: a62e1459 ("drm/i915/dp: Fix connector DSC HW state readout") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10410 Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> 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/20240311145626.2454923-1-imre.deak@intel.com
-
- 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:
-
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ä 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:
-
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:
-
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:
-
