Commit Graph

1368385 Commits

Author SHA1 Message Date
Jani Nikula
54846c2ea7 drm/i915/ddi: prefer poll_timeout_us() over readx_poll_timeout()
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-04 14:02:59 +03:00
Jani Nikula
f141590008 drm/i915/opregion: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:59 +03:00
Jani Nikula
19b31edb0a drm/i915/lspcon: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:59 +03:00
Jani Nikula
bcd23d8ee0 drm/i915/dsb: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:59 +03:00
Jani Nikula
7987b76433 drm/i915/tc: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:59 +03:00
Jani Nikula
46013820f4 drm/i915/vblank: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:59 +03:00
Jani Nikula
476721f28e drm/i915/dp: use generic poll_timeout_us() instead of wait_for() in link 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-04 14:02:58 +03:00
Jani Nikula
39b555b3ea drm/i915/dp: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
e38e3c50a1 drm/i915/power-well: use generic poll_timeout_us() instead of wait_for() for 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-04 14:02:58 +03:00
Jani Nikula
a8eb4cdced drm/i915/power-well: use generic poll_timeout_us() instead of wait_for() for 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-04 14:02:58 +03:00
Jani Nikula
c698a48e9f drm/i915/power: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
032a3bd4d6 drm/i915/cdclk: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
7f38db435c drm/i915/wm: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
11080a5ea8 drm/i915/gmbus: use generic poll_timeout*() instead of wait_for*()
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>
2025-09-04 14:02:58 +03:00
Jani Nikula
0399a33685 drm/i915/dsi-pll: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
17d56494c1 drm/i915/dsi: use generic poll_timeout_us() instead of wait_for_us()
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-04 14:02:58 +03:00
Jani Nikula
e54d34e4b3 drm/i915/hdcp: use generic poll_timeout_us() instead of wait_for()
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-04 14:02:58 +03:00
Jani Nikula
6f1759df0f drm/i915/hdcp: use generic poll_timeout_us() instead of __wait_for()
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-04 14:02:58 +03:00
Jani Nikula
00cbd55557 drm/i915/hdmi: use generic poll_timeout_us() instead of __wait_for()
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-04 14:02:58 +03:00
Luca Coelho
a304609be2 drm/i915: use REG_BIT on FW_BLC_SELF_* macros
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-04 13:36:43 +03:00
Jouni Högander
e9a1d54ed9 drm/i915/bios: Remove unnecessary checks of PSR idle frames in VBT binary
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
2025-09-03 13:40:39 +03:00
Jani Nikula
98463a8d9c drm/i915/power: drop a couple of &i915->drm usages
Switch from &i915->drm to display->drm.

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250902144929.3026700-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-03 13:32:33 +03:00
Jani Nikula
38f9262b05 drm/i915/dp: convert open-coded timeout to poll_timeout_us()
Use poll_timeout_us() instead of open-coding the timeout loop.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250829113311.1930618-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-03 12:05:21 +03:00
Mika Kahola
765531faa4 drm/i915/display: Fix possible overflow on tc power domain selection
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
2025-09-03 09:48:57 +03:00
Lee Shawn C
5f9bab8081 drm/i915: compute pipe bpp from link bandwidth management
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
2025-09-02 13:53:33 +03:00
Lee Shawn C
51bfda2e76 drm/i915/hdmi: add debugfs to contorl HDMI bpc
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
2025-09-02 13:43:34 +03:00
Suraj Kandpal
e548e04e61 drm/i915/hdcp: Remove the encoder check in hdcp enable
Remove the intel_encoder NULL check from _intel_hdcp_enable. With
all the changes it has gone through this check has become unnecessary
since at this point the connector is supposed to have the encoder
in it.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250819150729.88561-1-suraj.kandpal@intel.com
2025-09-02 10:31:26 +05:30
Ville Syrjälä
3b6f62b6b5 iopoll: Reorder the timeout handling in poll_timeout_us()
Currently poll_timeout_us() evaluates 'op' and 'cond' twice
within the loop, once at the start, and a second time after
the timeout check. While it's probably not a big deal to do
it twice almost back to back, it does make the macro a bit messy.

Simplify the implementation to evaluate the timeout at the
very start, then follow up with 'op'/'cond', and finally
check if the timeout did in fact happen or not.

For good measure throw in a compiler barrier between the timeout
and 'op'/'cond' evaluations to make sure the compiler can't reoder
the operations (which could cause false positive timeouts).
The similar i915 __wait_for() macro already has the barrier, though
there it is between the 'op' and 'cond' evaluations, which seems
like it could still allow 'op' and the timeout evaluations to get
reordered incorrectly. I suppose the ktime_get() might itself act
as a sufficient barrier here, but better safe than sorry I guess.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Matt Wagantall <mattw@codeaurora.org>
Cc: Dejin Zheng <zhengdejin5@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250826121859.15497-3-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-28 12:17:39 +03:00
Ville Syrjälä
563e5eca4e iopoll: Avoid evaluating 'cond' twice in poll_timeout_us()
Currently poll_timeout_us() evaluates 'cond' twice at the end
of the success case. This not desirable in case 'cond' itself
is expensive.

Avoid the double evaluation by tracking the return value in
a variable. Need to use a triple undescore '___ret' name to
avoid a conflict with an existing double undescore '__ret'
variable in the regmap code.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Matt Wagantall <mattw@codeaurora.org>
Cc: Dejin Zheng <zhengdejin5@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250826121859.15497-2-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-28 12:17:32 +03:00
Ville Syrjälä
9df8043a54 iopoll: Generalize read_poll_timeout() into poll_timeout_us()
While read_poll_timeout() & co. were originally introduced just
for simple I/O usage scenarios they have since been generalized to
be useful in more cases.

However the interface is very cumbersome to use in the general case.
Attempt to make it more flexible by combining the 'op', 'var' and
'args' parameter into just a single 'op' that the caller can fully
specify.

For example i915 has one case where one might currently
have to write something like:
	ret = read_poll_timeout(drm_dp_dpcd_read_byte, err,
				err || (status & mask),
				0 * 1000, 200 * 1000, false,
				aux, DP_FEC_STATUS, &status);
which is practically illegible, but with the adjusted macro
we do:
	ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, &status),
			      err || (status & mask),
			      0 * 1000, 200 * 1000, false);
which much easier to understand.

One could even combine the 'op' and 'cond'  parameters into
one, but that might make the caller a bit too unwieldly with
assignments and checks being done on the same statement.

This makes poll_timeout_us() closer to the i915 __wait_for()
macro, with the main difference being that __wait_for() uses
expenential backoff as opposed to the fixed polling interval
used by poll_timeout_us(). Eventually we might be able to switch
(at least most of) i915 to use poll_timeout_us().

v2: Fix typos (Jani)
    Fix delay_us docs for poll_timeout_us_atomic() (Jani)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Matt Wagantall <mattw@codeaurora.org>
Cc: Dejin Zheng <zhengdejin5@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250826121859.15497-1-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-28 12:16:36 +03:00
Jouni Högander
61a0ef5921 drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked
PSR work is using __psr_wait_for_idle_locked to ensure PSR exit is
completed before continuing to PSR activation. __psr_wait_for_idle_locked
is unlocking PSR mutex which allows PSR disable/enable and PSR
pause/resume while PSR idle is being wait. PSR enable status is already
checked after locking again PSR mutex but PSR pause counter check is
missing. Due to this PSR work may continue to PSR activation even PSR is
paused.

Fix this by checking PSR pause counter in __psr_wait_for_idle_locked after
PSR mutex is locked again.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jeevan B <jeevan.b@intel.com>
Link: https://lore.kernel.org/r/20250826074457.1992524-1-jouni.hogander@intel.com
2025-08-27 09:48:54 +03:00
Jouni Högander
c65ee1b1ff drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA
We are currently removing underrun on idle PSR WA even if it's not
applied. Fix this by checking pkg_c_latency_used on PSR exit as well.

Fixes: 9b1795e9b0 ("drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblank")
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://lore.kernel.org/r/20250822105846.1023631-1-jouni.hogander@intel.com
2025-08-26 10:23:21 +03:00
Jouni Högander
9cc10041e9 drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init
Currently we are ignoriong drm_dp_dpcd_read return values when reading PSR
and Panel Replay capability DPCD register. Rework intel_psr_dpcd a bit to
take care of checking the return value.

v2: use drm_dp_dpcd_read_data

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250821045918.17757-1-jouni.hogander@intel.com
2025-08-25 09:12:46 +03:00
Suraj Kandpal
2dbb3d70af drm/i915/edp: eDP Data Overrride
We need override certain link rates in favour of the next available
higher link rate. The Link rates that need to be overridden are
indicated by a mask in VBT. To make sure these modes are skipped we
don't add them in them in the sink rates array.

--v2
-Update the link rates after we have a final set of link rates [Ankit]
-Break this patch up [Ankit]
-Optimize the assingment during loop [Ankit]

--v3
-Add protection against broken VBTs [Jani]

--v4
-Fix build errors
-Create a seprate function to check if edp data override is selected
and using the correct vbt

--v5
-Use correct number to check the num of edp rates [Ankit]

--v6
-No seprate function check if vbt is broken in the reject rate function
[Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-4-suraj.kandpal@intel.com
2025-08-25 10:06:47 +05:30
Suraj Kandpal
835a0d544d drm/i915/bios: Add function to check if edp data override is needed
Add a function that helps identify if the rate provided needs to
be overridden. For this we need a function that compares the rate
provided and bitmask of rates provided in VBT.

--v2
-Rename functions [Jani]
-Return the mask instead of parsing it in function [Jani]
-Move the declaration in header [Jani]

--v3
-Change function name to depict what the function does [Ankit]

--v4
-Lets not use hweight [Ankit]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-3-suraj.kandpal@intel.com
2025-08-25 09:53:11 +05:30
Suraj Kandpal
4d33c77cf2 drm/i915/vbt: Add eDP Data rate overrride field in VBT
Add edp_data_rate_override field VBT which gives us a mask
of rates which needs to be skipped in favour of
subsequent higher rate.

--v2
-Rename vbt field [Jani]
-Fix comment to 263+ [Jani]
-Use BIT_U32 [Jani]
-Fix the bits assignment in vbt [Jani]

--v3
-Add a mask which represents all link rates [Ankit]

Bspec: 20124
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250821042653.269227-2-suraj.kandpal@intel.com
2025-08-25 09:53:10 +05:30
Jouni Högander
7c8c76272e drm/i915/psr: Check pause counter before continuing to PSR activation
Currently intel_psr_work is re-activating PSR even when pause_counter > 0
which is incorrect. Fix this by checking pause_counter before re-activating
PSR.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14822
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250815084534.1637030-4-jouni.hogander@intel.com
2025-08-21 13:40:31 +03:00
Jouni Högander
73b60be7f6 drm/i915/psr: Do not activate disabled PSR on irq_aux_error
Currently intel_psr_work is continuing to activation of PSR which was just
disabled when irq_aux_error == true.

Fix this by skipping everything else than intel_psr_handle_irq in
intel_psr_work when irq_aux_error == true.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250815084534.1637030-3-jouni.hogander@intel.com
2025-08-21 13:40:31 +03:00
Jouni Högander
f9ad930c52 drm/i915/psr: drm_WARN_ON when activating disabled PSR
Add drm_WARN_ON for scenario where PSR is activated while it is disabled.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250815084534.1637030-2-jouni.hogander@intel.com
2025-08-21 13:40:30 +03:00
Suraj Kandpal
11c09b55b3 drm/i915/backlight: Fix divide by 0 error in i9xx_set_backlight
pwm_level_max maybe 0 we do throw a warning but move ahead with
execution which may later cause a /0 error.

--v2
-return if the warn_on gets hit [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250819160438.145734-1-suraj.kandpal@intel.com
2025-08-21 09:45:10 +05:30
Jouni Högander
9b1795e9b0 drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblank
Underrun on idle PSR workaround (Wa_16025596647) is supposed to be
applied only when pkg c latency > delayed vblank. Currently we are
applying it always when other criterias are met.

Fix this by adding new boolean flag which is supposed to be set when
calculating watermark levels and pkgc latency > delayed vblank is
detected. currently this scenario is blocked but might be added
later. Due to this add also TODO comment into
skl_max_wm_level_for_vblank.

Bspec: 74151
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://lore.kernel.org/r/20250519075223.443266-1-jouni.hogander@intel.com
2025-08-20 08:00:28 +03:00
Jani Nikula
0492e13eb8 drm/i915/dram: move fsb_freq and mem_freq to dram info
Store fsb_freq and mem_freq in dram info the same way we do for other
memory info on later platforms for a slightly more unified approach.

This allows us to remove fsb_freq, mem_freq and is_ddr3 members from
struct drm_i915_private and struct xe_device.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/a38c4b105ba9098fa0b128cb86cd4eb63bcc27e8.1755511595.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:20:40 +03:00
Jani Nikula
10e656f8c4 drm/i915/dram: bypass fsb/mem freq detection on dg2 and no display
Non-display now calls the intel_fsb_freq() and intel_mem_freq()
functions, so we don't have to have the frequencies initialized for dg2
or non-display cases.

This is in preparation for unifying the pre-gen9 handling in dram info.

DG2 remains a special case as described in commit 5eb6bf0b44
("drm/i915/dg2: Don't read DRAM info").

v2: Rebase

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/7bfed06d431354f3918ea73d43a2ec8ed9426a76.1755511595.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:20:40 +03:00
Jani Nikula
6c9f41d8fa drm/i915/rps: use intel_fsb_freq() and intel_mem_freq()
The rps init only happens once, so it's not important to use the cached
versions, and we can drop the dependency on them.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/6f3b703f7cb5605bf139cbe27697c1d4ffe7e719.1755511595.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:20:40 +03:00
Jani Nikula
6e977fe781 drm/i915/dram: add intel_mem_freq()
Add a more generic intel_mem_freq() function instead of platform
specific ones. Expose it for future use outside of intel_dram.c.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/602103b290a92ba26d581eeb595ba5e707eb5bc4.1755511595.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:20:40 +03:00
Jani Nikula
e0b1bbed5e drm/i915/dram: add intel_fsb_freq() and use it
Add a more generic intel_fsb_freq() function instead of platform
specific ones.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/c5b77311c5f64b7163c86a042b7d023c07a685e2.1755511595.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:20:40 +03:00
Jani Nikula
1d409b0a77 drm/i915/switcheroo: check for NULL before dereferencing
Both i915_switcheroo_set_state() and i915_switcheroo_can_switch() check
for i915 == NULL. Commit d2e184f8e1 ("drm/i915/switcheroo: pass
display to HAS_DISPLAY()") started dereferencing it before the NULL
check. Fix it.

Fixes: d2e184f8e1 ("drm/i915/switcheroo: pass display to HAS_DISPLAY()")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202508160035.hmzuKiww-lkp@intel.com/
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250818071605.2541523-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19 11:17:52 +03:00
Chaitanya Kumar Borah
ba49a4643c drm/i915/dp: Set min_bpp limit to 30 in HDR mode
Update intel_dp_compute_config_limits() to use a minimum of
30 bits per pixel when the connector is in HDR mode
(specifically, when EOTF is SMPTE ST2084), aligning with HDR
display requirements.

To support this, the function now takes a drm_connector_state
instead of an intel_connector, and the required updates are
made in all call sites, including MST handling.

This ensures sufficient bitdepth for HDR content to avoid
banding.

If the required bandwidth for 30 bpp cannot be supported,
the driver will either fall back to DSC or reject the mode
during atomic check if DSC is not supported.

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250730055523.2214966-3-chaitanya.kumar.borah@intel.com
2025-08-19 12:02:40 +05:30
Chaitanya Kumar Borah
2e9da93d60 drm/i915/dp: Refactor intel_dp_in_hdr_mode() for broader reuse
The intel_dp_in_hdr_mode() helper was previously defined in
intel_dp_aux_backlight.c but is generally useful beyond that
context. Move the function to intel_dp.c and declare it in
intel_dp.h to make it accessible to other DP-related code
paths that need to check HDR metadata state.

This is a pure refactor with no functional change and
prepares for a follow-up patch that uses this helper.

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250730055523.2214966-2-chaitanya.kumar.borah@intel.com
2025-08-19 12:02:38 +05:30
Jani Nikula
63e0b17ae7 drm/i915/bo: remove unnecessary include
intel_bo.c doesn't need intel_display_types.h for anything. Remove.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20250814132445.1573035-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-15 14:13:20 +03:00