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
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
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>
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>
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 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
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
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
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
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
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
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>
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>
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>
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
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
There shouldn't be anything requiring irqs to be enabled at the point of
LPE audio setup. Regardless, we've never hit the warning, as irqs are
always enabled at the time LPE audio is initialized. Drop the
superfluous warning, and the dependency on i915_drv.h.
Fix style a bit while at it.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://lore.kernel.org/r/20250801122832.249985-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
All the places that use DSPCLK_GATE_D are specific to certain platforms,
and the parametrization of it to support VLV/CHV MMIO display base isn't
really buying us anything. Add a separate macro for VLV_DSPCLK_GATE_D
and use it.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/ac16d9d5192595944bf9bcf70aa721b504bc90c0.1754499175.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Underneath, the HAS_PCH_NOP(), DISPLAY_VER(), HAS_FBC(), and
HAS_HOTPLUG() macros really expect a struct intel_display. Switch to it
in preparation for removing the transitional __to_intel_display() macro.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/de3302dd9ebc21226a9dadcbcdeeaf01e57186be.1754499175.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 8d9908e8fe ("drm/i915/display: remove small micro-optimizations
in irq handling") not only removed the optimizations, it also enabled
wakeref asserts for the GEN11_GU_MISC_IIR access. Silence the asserts by
wrapping the access inside intel_display_rpm_assert_{block,unblock}().
Reported-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Closes: https://lore.kernel.org/r/aG0tWkfmxWtxl_xc@zx2c4.com
Fixes: 8d9908e8fe ("drm/i915/display: remove small micro-optimizations in irq handling")
Cc: stable@vger.kernel.org # v6.13+
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250805115656.832235-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
WCL has 3 pipes and two TC ports, create power well mapping to reflect
HW. Rest remains similar to Xe3 power well configuration.
v2: Remove TC3/4 ports as they do not exist.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250808081931.4101388-1-chaitanya.kumar.borah@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Debug print the TypeC pin assignment and max lane count value during HW
readout and after resetting the TypeC mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-20-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Cache the pin assignment value. This is more consistent with the way the
max lane count value is tracked and a bit more efficient than reading
out the same value from HW each time it's queried.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-19-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
The pin assignment is only relevant in case the PHY is owned by the
display, that is in legacy and DP-alt mode. In TBT-alt mode the PHY is
owned by the TBT FW/driver and so the pin assignment/configuration is
managed by those components. A follow-up change will cache the pin
assignment value in all the TypeC modes - querying this by calling
get_pin_assignment() - prepare for that here, by reporting pin
assignment NONE in the TBT-alt mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-18-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Pass the intel_tc_port pointer instead of intel_digital_port to all lane
mask and count query helpers internal to intel_tc.c, to avoid the
redundant intel_digital_port -> intel_tc_port conversions.
While at it shorten the function names, keeping the intel_tc_port_
prefix only for exported functions and use the mtl_, icl_ prefixes
making it clear which platforms a given query function is specific for.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-17-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
For consistency, handle the case where
intel_tc_port_get_pin_assignment() is called for a non-TypeC encoder,
returning the default NONE pin assignment value, similarly to how this
is done in intel_tc_port_max_lane_count().
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-16-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
