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: 62afef2811 ("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>
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
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
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
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
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
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>
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>
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>
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>
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>
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Prefer generic poll helpers over i915 custom helpers.
The "two tier" wait_for_us() + wait_for() combination appeared without
much explanation in commit 4e6c2d58ba ("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>
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>
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>
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>
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>
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>
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
There is a possibility that intel_encoder_to_tc() function
returns negative i.e. TC_PORT_NONE (-1) value which may cause
tc_port_power_domain() function to overflow. To fix this,
let's add additional check that returns invalid power domain
i.e. POWER_DOMAIN_INVALID in case tc port equals TC_PORT_NONE.
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250829101226.4085757-1-mika.kahola@intel.com
Since intel_fdi_compute_pipe_bpp() is no longer FDI-specific and
now applies to all connectors. Move it to intel_link_bw.c,
and rename to intel_link_bw_compute_pipe_bpp().
v2: Remove unused header file.
Cc: Shankar Uma <uma.shankar@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
[Imre: Remove unused intel_fdi.h include from intel_hdmi.c]
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250901055721.219995-3-shawn.c.lee@intel.com
While performing HDMI compliance testing, test equipment may request
different bpc output for signal measurement. However, display driver
typically determines the maximum available bpc based on HW bandwidth.
This change leverages the existing debugfs (intel_force_link_bpp)
to manage HDMI bpc, and making it easier to pass HDMI CTS.
v2: Using exist variable max_requested_bpc.
v3: Extend intel_force_link_bpp to support HDMI as suggested by Imre.
v4: Update commit message suggested by Jani.
v5: Remove unused header file.
Cc: Shankar Uma <uma.shankar@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250901055721.219995-2-shawn.c.lee@intel.com
