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
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 "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>
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>
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
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
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>
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
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
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
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
