- 18 Mar, 2024 1 commit
-
-
Jonathon Hall authored
Since commit 0c65dc06 ("drm/i915/jsl: s/JSL/JASPERLAKE for platform/subplatform defines"), boot freezes on a Jasper Lake tablet (Librem 11), usually with graphical corruption on the eDP display, but sometimes just a black screen. This commit was included in 6.6 and later. That commit was intended to refactor EHL and JSL macros, but the change to ehl_combo_pll_div_frac_wa_needed() started matching JSL incorrectly when it was only intended to match EHL. It replaced: return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) && IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) || with: return (((IS_ELKHARTLAKE(i915) || IS_JASPERLAKE(i915)) && IS_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) || Remove IS_JASPERLAKE() to fix the regression. Signed-off-by:
Jonathon Hall <jonathon.hall@puri.sm> Cc: stable@vger.kernel.org Fixes: 0c65dc06 ("drm/i915/jsl: s/JSL/JASPERLAKE for platform/subplatform defines") Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240313135424.3731410-1-jonathon.hall@puri.smSigned-off-by:
-
- 15 Mar, 2024 16 commits
-
-
Ville Syrjälä authored
Create the drm_printer at the start of intel_pipe_config_compare() and pass it on to all the mismatch() functions. v2: Rebase Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229184234.31272-1-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Just call pipe_config_mismatch() from all the more specialized mismatch() functions instead of hand rolling the same printfs all over. v2: Eliminate the dpll drm_debug_enabled() in an earlier patch (Jani) Reviewed-by:
-
Ville Syrjälä authored
Hoist pipe_config_mismatch() upwards a bit so that it can get reused by the other mismatch() functions. Signed-off-by:
-
Ville Syrjälä authored
intel_crtc_state_dump() does a whole boatload of string formatting which is all wasted energy if the debugs aren't even enabled. Skip the whole thing in that case. Signed-off-by:
-
Ville Syrjälä authored
Plumb the drm_printer to all the little helpers called by intel_crtc_state_dump() and use it there as well. The exceptions are the ELD and infoframe stuff as they call helpers outside of the drm and thus can't use drm_printer. Signed-off-by:
-
Ville Syrjälä authored
Convert all the direct drm_dbg_kms() stuff in intel_crtc_state_dump() over to drm_printf() since we now have the drm_printer around. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
Utilize drm_printer in pipe_config_pll_mismatch() to avoid a bit of code duplication. To achieve this we need to plumb the printer all way to the dpll_mgr .dump_hw_state() functions. Those are also used by intel_crtc_state_dump() which needs to be adjusted as well. v2: Convert a few misplaecd drm_dbg_kms() calls (Rodrigo) Drop the redundant drm_debug_enabled() check here instead of later (Jani) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Ville Syrjälä authored
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid a bit of code duplication. print_hex_dump() doesn't know anything about the printer so it still needs the DRM_UT_KMS check and special handling for the loglevel. But at least we end up with a bit less copy-pasta. Signed-off-by:
-
Ville Syrjälä authored
Utilize drm_printer in pipe_config_infoframe_mismatch() to avoid a bit of code duplication. hdmi_infoframe_log() can't use the printer of course, but for that we can just figure out which loglevel to use. And we do need to keep the explicit drm_debug_enabled(DRM_UT_KMS) since hdmi_infoframe_log() won't do it for us. Signed-off-by:
-
Ville Syrjälä authored
Most crtc state mismatches include the CRTC id+name in the prints. Also include it in the VSC SDP mismatches. Signed-off-by:
-
Ville Syrjälä authored
Most crtc state mismatches include the CRTC id+name in the prints. Also include it in the infoframe mismatches. Signed-off-by:
-
Ville Syrjälä authored
intel_crtc_check_fastset() is done per-pipe, so it would be nice to know which pipe it was that failed its checkup. Signed-off-by:
-
Ville Syrjälä authored
Remove the pointless (void*) cast, the incoming pointer is already the correct type. Signed-off-by:
-
Ville Syrjälä authored
commit 64f6a5d1 ("container_of: add container_of_const() that preserves const-ness of the pointer") is nice. Let's use it so that we don't accidentally cast away the const from our state pointers. The only thing I don't particularly like about container_of_const() is that it still accepts void* in addition to the proper pointer types, but that's how most other things in C work anyway so I guess we can live with it. And while at it rename the macro arguments to be a bit more descriptive than just 'x'. TODO: maybe convert *all* container_of() uses to container_of_const()? Signed-off-by:
-
Ville Syrjälä authored
The connector state passed to .atomic_get_property() is const. We should preserve that when downcasting to our version. Signed-off-by:
-
Ville Syrjälä authored
Use enc_to_intel_dsi() instead hand rolling it. Signed-off-by:
-
- 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:
-
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:
-
- 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:
-
