aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-08drm/i915/fb: add intel_framebuffer_alloc()Jani Nikula4-4/+11
Add intel_framebuffer_alloc() to hide intel_bo_alloc_framebuffer(), as that doesn't feel like the correct abstraction. Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/379c306c692c50f6af3b6f2488c213f12627954f.1756835342.git.jani.nikula@intel.com
2025-09-08drm/i915/display: Remove FBC modulo 4 restriction for ADL-P+Uma Shankar1-2/+2
WA:22010751166 does not apply past display version 12. Or, in other words, the FBC restriction where FBC is disabled for non-modulo 4 plane sizes (including plane size + yoffset) is fixed from display version 13 and onwards. Relax the restriction for the same. v4: Dropped redundant commit message v3: Update comments for clarity (Jonathan Cavitt) v2: Update the macro for display version check (Vinod) Suggested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250904095338.300813-2-uma.shankar@intel.com
2025-09-08drm/i915/gvt: Remove redundant ternary operatorsLiao Yuanhong1-1/+1
For ternary operators in the form of "a ? false : true", if 'a' itself returns a boolean result, the ternary operator can be omitted. Remove redundant ternary operators to clean up the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250904112644.350512-1-liaoyuanhong@vivo.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-08drm/i915/ddi: abstract figuring out encoder nameJani Nikula1-31/+38
The encoder name deduction has become a bit cumbersome within intel_ddi_init(). Split it out to a separate function to declutter intel_ddi_init(), even if that means having to use a temp seq buffer for the name. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250903101050.3671305-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-08drm/i915/power: fix size for for_each_set_bit() in abox iterationJani Nikula1-3/+3
for_each_set_bit() expects size to be in bits, not bytes. The abox mask iteration uses bytes, but it works by coincidence, because the local variable holding the mask is unsigned long, and the mask only ever has bit 2 as the highest bit. Using a smaller type could lead to subtle and very hard to track bugs. Fixes: 62afef2811e4 ("drm/i915/rkl: RKL uses ABOX0 for pixel transfers") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v5.9+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250905104149.1144751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-08drm/i915/psr: Panel Replay SU cap dpcd read return valueJouni Högander1-5/+7
Currently return value of drm_dpcd_readb is not checked when reading sink Panel Replay Selective Update capabilities. Fix this and switch to drm_dpcd_read_byte. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://lore.kernel.org/r/20250827060809.2461725-1-jouni.hogander@intel.com
2025-09-08drm/i915/psr: Add poll for checking PSR is idle before starting updateJouni Högander1-0/+3
We are currently observing crc failures after we started using dsb for PSR updates as well. This seems to happen because PSR HW is still sending couple of updates using old framebuffers on wake-up. Fix this by adding poll ensuring PSR is idle before starting update. v2: pass new_crtc_state->dsb_commit to intel_psr_wait_for_idle_dsb Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250905072708.2659411-5-jouni.hogander@intel.com
2025-09-08drm/i915/psr: New interface adding PSR idle poll into dsb commitJouni Högander2-4/+37
We are currently observing crc failures after we started using dsb for PSR updates as well. This seems to happen because PSR HW is still sending couple of updates using old framebuffers on wake-up. This patch is preparing to fix that by adding interface which can be used to add poll ensuring PSR HW is idle into dsb commit. v3: add intel_dsb as a parameter to intel_psr_wait_for_idle_dsb v2: add pass crtc_state->dsb_commit as parameter Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250905072708.2659411-4-jouni.hogander@intel.com
2025-09-08drm/i915/psr: Add new define for PSR idle timeoutJouni Högander1-8/+12
Currently we are using value 50ms as timeout for waiting PSR to idle. Add own define for this purpose. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250905072708.2659411-3-jouni.hogander@intel.com
2025-09-08drm/i915/psr: Pass intel_crtc_state instead of intel_dp in wait_for_idleJouni Högander1-8/+10
This is preparation to add own function for polling PSR being ready for update when doing dsb commit. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250905072708.2659411-2-jouni.hogander@intel.com
2025-09-05drm/i915/display: Avoid divide by zeroJuha-Pekka Heikkila1-1/+1
skl_crtc_allocate_plane_ddb allow iter.data_rate to be zero which could cause divide by zero in skl_allocate_plane_ddb, check against that. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250905104626.1274147-3-juhapekka.heikkila@gmail.com
2025-09-05drm/i915/display: log fail from intel_sdvo_enable_hotplugJuha-Pekka Heikkila1-2/+4
Report in log if intel_sdvo_enable_hotplug failed Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250905104626.1274147-2-juhapekka.heikkila@gmail.com
2025-09-05drm/i915/display: take out dead codeJuha-Pekka Heikkila1-2/+0
if __waitfor timeout, ret will have -ETIMEDOUT. Then if condition was met, and read_ret will have error that's handled. Then if ret was zero, read_ret was zero ksv_ready must have value. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250905104626.1274147-1-juhapekka.heikkila@gmail.com
2025-09-05drm/i915/dram: Print memory details even if something went wrongVille Syrjälä1-4/+5
Print the memory details even if the detection failed in some way but we continued the driver initialization anyway. It'll be easier to debug issues if we at least know what the final results were. And while at it also print the number of PSF GV points. Previously we only printed the QGV points. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Don't call skl_get_dram_info()/skl_get_dram_type() on iclVille Syrjälä1-1/+2
Currently the icl codepaths first determine the memory type from the memory controller registers (via skl_get_dram_info()->skl_get_dram_type()) and then overwrite the results with icl_pcode_read_mem_global_info(). Get rid of the pointless (and potentially incorrect) skl_get_dram_type() stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Fix some spelling around the 16Gb DIMM w/aVille Syrjälä1-2/+2
Use consistent spelling when talking about the 16Gb DIMM w/a. Even currently language is a bit off as the w/a is actually about DIMMs with 16Gb DRAM devices on them, not the total capacity of the whole DIMM. But this language does more or less match how Bspec talks about this stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Move 16Gb DIMM detection fully to the skl/icl codepathsVille Syrjälä1-11/+6
We are incorrectly applying the 16Gb DIMM w/a (adding 1 extra usec to WM0 latency) on MTL+ even though the w/a is only needed for SKL/ICL. The current way of setting this is up is a bit of a disaster: 1. always set has_16gb_dimms=true for all platforms except BXT/GLK 2. has_16gb_dimms potentially gets overwritten with something else * BXT/GLK don't do anything since we never set has_16gb_dimms to begin with * skl_get_dram_info() overwrites has_16gb_dimms with the actual detection results for SKL/ICL/derivatives * gen12_get_dram_info() (correctly) resets has_16gb_dimms for TGL/ADL/derivatives * xelpdp_get_dram_info() doesn't do anything, leaving has_16gb_dimms incorrectly set for MTL+ Clean up the whole mess by only setting has_16gb_dimms in the SKL/ICL codepaths where we have the actual detection code for it. This avois applying the w/a incorrectly on MTL+. v2: Rewrite commit msg (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: s/wm_lv0.../has_16gb_dimms/Ville Syrjälä3-8/+8
The DRAM code shouldn't know anything about watermarks. Rename wm_lv_0_adjust_needed to has_16gb_dimms. How this gets used is up to the watermark code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Pack dram_info betterVille Syrjälä1-5/+5
struct dram_info has two holes in the middle. Shuffle things around to plug them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Use intel_dram_type_str() for pnvVille Syrjälä3-3/+5
Replace the hand rolled PNV memory type printk string stuff with intel_dram_type_str(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/dram: Populate PNV memory type accuratelyVille Syrjälä2-4/+7
If PNV doesn't have DDR3 then it has DDR2. Add the appropriate memory type for it. No functional change since we currently only care about the DDR3 vs. not difference. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902133113.18778-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/hpd: Fix mtp_tc_hpd_enable_detection()Ville Syrjälä1-1/+1
Set the MTP TC hotplug bits in the correct register. Shouldn't matter really as this only gets used for eDP detection and there should be never eDP on TC ports on current hw. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250902153915.4423-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-09-05drm/i915/display: Remove power state verification before HW readoutImre Deak1-2/+0
During system resume the display power state verification will print the "power well x state mismatch (refcount 0/enabled 1)" error message from the early resume sequence for a power well left enabled by BIOS. This power well was probably left enabled by BIOS inadvertently, since BIOS versions on current platforms do not leave any display output enabled while resuming from an Sx power state, hence the enabled display power well is unused. In theory however it is possible that BIOS leaves a display output enabled, in that case the enabled power well shouldn't be reported as an error. According to the above, remove the display power state verification from the early resume phase to avoid incorrectly reporting an enabled power well without a power reference as an error. Note: The refcount for any enabled and used power well (i.e. used for an enabled display output) will be acquired following the early resume sequence, after the HW state for display outputs (encoder/crtc etc.) is read out. Any power well enabled but not used (hence not holding a reference) will be disabled after the HW state readout. The display power state will be verified afterwards in intel_power_domains_enable(). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6012 Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250903122152.2526050-1-imre.deak@intel.com
2025-09-05drm/i915/alpm: Use actual lfps cycle and silence periods in wake timeJouni Högander1-7/+5
Currently we are using maximum lfps cycle and silence period times when calculating AUXLess wake time. Use actual values instead. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250829053929.3585636-5-jouni.hogander@intel.com
2025-09-05drm/i915/alpm: Replace hardcoded LFPS cycle with proper calculationJouni Högander1-52/+38
Currently LFPS is hadcoded for different port clocks. Replace this with proper calculation. v2: replace hardcoded 20 with 2 * LFPS_CYCLE_COUNT Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250829053929.3585636-4-jouni.hogander@intel.com
2025-09-05drm/i915/alpm: Add own define for LFPS countJouni Högander1-1/+3
Add own define for LFPS count and use it for the configuration. This new define will be used for calculating ALPM parameters as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250829053929.3585636-3-jouni.hogander@intel.com
2025-09-05drm/i915/alpm: Calculate silence periodJouni Högander1-20/+17
Calculate silence period instead of hardcoding it in switch case. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://lore.kernel.org/r/20250829053929.3585636-2-jouni.hogander@intel.com
2025-09-04change the calling conventions for vfs_parse_fs_string()Al Viro1-7/+2
Absolute majority of callers are passing the 4th argument equal to strlen() of the 3rd one. Drop the v_size argument, add vfs_parse_fs_qstr() for the cases that want independent length. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2025-09-04drm/i915/pps: prefer poll_timeout_us() over read_poll_timeout()Jani Nikula1-5/+3
Unify on using poll_timeout_us() throughout instead of mixing with readx_poll_timeout(). Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/260fd455df743453f123d96fc01e7ca96a36f0fa.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/ddi: prefer poll_timeout_us() over readx_poll_timeout()Jani Nikula1-21/+11
Unify on using poll_timeout_us() throughout instead of mixing with readx_poll_timeout(). While the latter can be ever so slightly simpler, they are both complicated enough that it's better to unify on one approach only. While at it, better separate the handling of error returns from drm_dp_dpcd_readb() and the actual status byte. This is best achieved by inlining the read_fec_detected_status() function, and switching to drm_dp_dpcd_read_byte(). v2: Use drm_dp_dpcd_read_byte() (Imre) Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/63b10a36c7ab545c640b24bc8fc007ce2ea74623.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/opregion: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-4/+6
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 1 ms sleep instead. The timeout remains, being opregion defined, 50 ms by default, and 1500 ms at most. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/63db3a1e1db9e55a18ed322c55f2dffe511a10bb.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/lspcon: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-3/+10
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 5 ms sleep instead. The timeouts remain, being 400 ms or 800 ms, depending on the case. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/4065fa96c0ef6afd51a384f365761d2ca802256b.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/dsb: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-2/+8
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 100 us sleep instead. The timeout remains at 1 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/979eae02af1184b3756746ace61379dd1947a79b.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/tc: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-2/+14
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 200 us sleep for the 5 ms timeout, and 1000 us sleep for the 500 ms timeout. The timeouts remain the same. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/50cd06b61210f541d5bb52a36af2d8bf059dd3a1.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/vblank: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-1/+8
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 100 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/162dff5862d3213304491a6d2eb31a57346b523e.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/dp: use generic poll_timeout_us() instead of wait_for() in link ↵Jani Nikula1-4/+13
training Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 500 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/29ab4738758fe844dc1323c4a59d5d6bdcf87308.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/dp: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-10/+10
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 1 ms sleep instead. The timeouts remain, being 500 ms or 1000 ms depending on the case. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/83d3417d4e5af1db13eb4c6eaa48b5f9c12caeb4.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/power-well: use generic poll_timeout_us() instead of wait_for() for ↵Jani Nikula1-14/+15
VLV/CHV Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 100 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/c644b7b5611a3c047ea5d3d52acd91830b2fa6b4.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/power-well: use generic poll_timeout_us() instead of wait_for() for ↵Jani Nikula1-4/+9
DKL PHY Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 100 us sleep instead. The timeout remains at 1 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/663c9edf4a98b09121d7200f8d734ebc829da85b.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/power: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-2/+5
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 100 us sleep instead. The timeout remains at 1 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/900680516b047ae32e3298b5cdbcede0393e0466.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/cdclk: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-17/+20
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 50 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/6d50031411d5517508867d4b595ce90a2b44073b.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/wm: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-4/+12
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 3 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/52c80860ea7b98e84f2386ed6cdd761f03190b1e.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/gmbus: use generic poll_timeout*() instead of wait_for*()Jani Nikula1-5/+8
Prefer generic poll helpers over i915 custom helpers. The "two tier" wait_for_us() + wait_for() combination appeared without much explanation in commit 4e6c2d58ba86 ("drm/i915: Take forcewake once for the entire GMBUS transaction"). Try to mimic roughly the same with the generic helpers. wait_for_us() with 10 us or shorter timeouts ends up in _wait_for_atomic(). Thus use poll_timeout_us_atomic() for the first try, with the same 2 us timeout and no sleep. For the fallback, the functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 50 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/564b397352c53a1116519fb2d53050c0426bc0dc.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/dsi-pll: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-4/+7
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 500 us sleep instead. The timeout remains at 20 ms. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/476fcc5aad9e2ddbf6d8c14bd5ff5cbf071c5dca.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/dsi: use generic poll_timeout_us() instead of wait_for_us()Jani Nikula1-4/+14
Prefer generic poll helpers over i915 custom helpers. The sleep and timeout remain the same as for wait_for_us(). Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/02ebcd2864819b7eaf9cf455aa2b968980a2f671.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/hdcp: use generic poll_timeout_us() instead of wait_for()Jani Nikula1-7/+10
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us. Use an arbitrary constant 100 us sleep instead. The timeout remains at 1 ms. While at it, use the last failing value for debug logging instead of reading it again. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/2871a07337401c25ef3df44073c5e78fedc45e8e.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/hdcp: use generic poll_timeout_us() instead of __wait_for()Jani Nikula1-4/+4
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of __wait_for(), which used to be 1, 2, 4, ... 64, and 128 ms in this particular case. Use an arbitrary 100 ms sleep instead. The timeout remains at 5000 ms. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/bfc9f941ec1628830644f1419d606e3d085aaba0.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915/hdmi: use generic poll_timeout_us() instead of __wait_for()Jani Nikula1-5/+5
Prefer generic poll helpers over i915 custom helpers. The functional change is losing the exponentially growing sleep of __wait_for(), which used to be 1, 2, 4, and 8 ms in this particular case. Use an arbitrary constant 4 ms sleep instead. The timeout remains, varying between 20 ms and 3000 ms. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/fc3a67f9de0049f415a276bba1c11a4df97e01d6.1756383233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-04drm/i915: use REG_BIT on FW_BLC_SELF_* macrosLuca Coelho1-3/+3
Use REG_BIT() instead of open coding the shift in the FW_BLC_SELF_* macro definitions to avoid potentially typing them as 'int'. For example, this happens when we pass them to _MASKED_BIT_ENABLE(), because of the typeof() construct there. When we pass 1 << 15 (the FW_BLC_SELF_EN macro), we get typeof(1 << 15), which is 'int'. Then the value becomes negative (-2147450880) and we try to assign it to a 'u32'. In practice this is not a problem though, because when we try to assign -2147450880 to the u32, that becomes 0x80008000, which was the intended result. Link: https://lore.kernel.org/intel-gfx/20250827111109.401604-1-luciano.coelho@intel.com/ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2025-09-03drm/i915/bios: Remove unnecessary checks of PSR idle frames in VBT binaryJouni Högander1-4/+1
PSR idle frames in VBT binary is a 4 bits wide bitfield. Checking if it's below 0 or over 15 doesn't make sense. Remove these checks. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250901101033.4176277-1-jouni.hogander@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-04 06:16:51 +0000