Prefer the register read specific wait function over i915 wait_for_us().
The existing condition is quite complicated. Simplify by checking for
requesters first, and determine timeout based on that. Refresh
requesters in case of timeouts, should one have popped up during the
wait. The downside is that this does not cut the wait short if
requesters show up *during* the wait, but we're talking about 1 ms so
shouldn't be an issue.
v2: Refresh requesters only if there were none before (Imre)
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250626192632.2330349-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Only use the ms granularity wait in snb_pcode_write_timeout(), primarily
to better align with the xe driver, which also only has the millisecond
wait.
Use an arbitrary 250 us fast wait before the specified ms wait, and have
snb_pcode_write() default to 1 ms.
This means snb_pcode_write() and snb_pcode_write_timeout() will always
be sleeping functions. There should not be any atomic users for pcode
writes though, and any display code using pcode via xe has already been
non-atomic. The uncore wait will do a might_sleep() annotation that
should catch any problems.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/ba86280f53cea2d020308db35f1ecbd615d07d8a.1750678991.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently we have some asserts to make sure the main DMC has been
loaded. Add similar asserts for the pipe DMCs. And we might as well
just check all the mmio registers the firmware has asked us to
initialize. That also covers the hardcoded SSP/HTP registers we were
checking for the main DMC.
TODO: Maybe always configure DMC_EVT_CTL_ENABLE the way the firmware
has it set so that we wouldn't need to special case in the assert?
v2: Also assert in intel_dmc_load_program()
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250617170759.19552-8-ville.syrjala@linux.intel.com
This is a scripted split of the display related register macros from
i915_reg.h to display/intel_display_regs.h. As a starting point, move
all the macros that are only used in display code (or GVT). If there are
users in core i915 code or soc/, or no users anywhere, keep the macros
in i915_reg.h. This is done in groups of macros separated by blank
lines, moving the comments along with the groups.
Some manually picked macro groups are kept/moved regardless of the
heuristics above.
This is obviously a very crude approach. It's not perfect. But there are
4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This
is the big hammer that splits the file to two, and enables further
cleanup.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v2
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250606102256.2080073-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch is applying workaround for underrun on idle PSR HW issue
(Wa_16025596647) when PSR is getting enabled. It uses vblank enable/disable
status, DC5/6 enabled disabled and enabled pipes count information made
available.
This patch is also adding calls to dc5/dc6, vblank enable/disable and pipe
enable/disable notification functions as needed.
intel_psr_needs_block_dc_vblank is modified to get vblank enable/disable
notification on PSR capable system.
v2: use intel_dmc interface instead of directly writing dmc register
Bspec: 74151
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250414100508.1208774-12-jouni.hogander@intel.com
Starting from MTL we don't have a platform agnostic way to validate
DC6 state due to dc6 counter has been removed to validate DC state.
The goal is to validate that the display HW can reach the DC6 power
state. There is no HW DC6 residency counter (and there wasn't such
a counter earlier either), so an alternative way is required. According
to the HW team the display driver has programmed everything correctly in
order to allow the DC6 power state if the DC5 power state is reached
(indicated by the HW DC5 residency counter incrementing) and DC6 is
enabled by the driver.
Driver could take a snapshot of the DC5 residency counter right
after it enables DC6 (dc5_residency_start) and increment the SW
DC6 residency counter right before it disables DC6 or when user space
reads the DC6 counter. So the driver would update the counter at these
two points in the following way:
dc6_residency_counter += dc5_current_count - dc5_start_count
v2: Update the discription. (Imre)
Read dc5 count during dc6 enable and disable then and update
dc6 residency counter. (Imre)
Remove variable from dmc structure. (Jani)
Updated the subject title.
v3: Add i915_power_domains lock to updated dc6 count in debugfs. (Imre)
Use flags to check dc6 enable/disable states. (Imre)
Move the display version check and counter read/update to
a helper. (Imre)
Resize the variable length. (Rodrigo)
Use old dc6 debugfs entry for every platform. (Rodrigo)
v4: Remove superfluous whitespace. (Jani)
Read DMC registers in intel_dmc.c (Jani)
Rename dc6_en_dis to dc6_enabled and change its type to bool. (Jani)
Rename update_dc6_count and move it to intel_dmc.c (Jani)
Rename dc6_en_dis to start_tracking. (Imre)
Have lock for dc6 state read aswelll. (Imre)
Keep the existing way print 'DC5 -> DC6 count' along with
new 'DC6 Allowed Count' print. (Imre)
Add counters in intel_dmc struct. (Imre)
Have interface to return dc6 allowed count. (Imre)
Rename dc6_count to dc6_allowed_count. (Rodrigo)
v5: Rename counters and move in to dc6_allowed structure. (Imre)
Order declaration lines in decreasing line length. (Imre)
Update start_tacking logic. (Imre)
Move get couner inside lock and DISPLAY_VER code to helper. (Imre)
v6: Change intel_dmc_get_dc6_allowed_count return type to bool. (Imre)
Update debugfs print to better allien with old print. (Imre)
Remove braces at if/else for signle line statements. (Imre)
v7: Remove in line variable declaration. (Imre)
v8: Rebase the changes.
Signed-off-by: Mohammed Thasleem <mohammed.thasleem@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321123707.287745-1-mohammed.thasleem@intel.com
Enabling and disabling the DMC wakelock should be done as part of
enabling and disabling of dynamic DC states, respectively. We should not
enable or disable DMC wakelock independently of DC states, otherwise we
would risk ending up with an inconsistent state where dynamic DC states
are enabled and the DMC wakelock is disabled, going against current
recommendations and making MMIO transactions potentially slower. In
future display IPs that could have a worse outcome if DMC trap
implementation is completely removed.
So, let's make things safer by tying stuff together, removing the
independent calls, and also put warnings in place to detect inconsistent
calls.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-13-gustavo.sousa@intel.com
There are extra registers that require the DMC wakelock when specific
dynamic DC states are in place. Those are registers that are touched by
the DMC and require DC exit for proper access. Add the range tables for
them and use the correct one depending on the enabled DC state.
v2:
- Do not look into power domains guts (i.e.
display->power.domains.dc_state). (Jani)
- Come up with better names for variables containing register ranges.
(Luca)
- Keep a copy of dc_state in struct intel_dmc_wl.
- Update commit message for a clearer explanation for the need of
these new tables.
Bspec: 71583
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-10-gustavo.sousa@intel.com
The intel_pps_reset_all() function does similar but not quite the same
things for VLV/CHV and BXT/GLK. Observe that it's called from platform
specific code only, and a split to two functions vlv_pps_reset_all() and
bxt_pps_reset_all() is natural.
Remove the platform checks and warnings from the functions. We don't
usually have them, unless we're unsure. To make this easier to reason
about for BXT/GLK, change the condition on caller side from "!PCH" to
"BXT || GLK".
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240919090427.1859032-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We don't actually know whether we should be picking the PHY
simply based on the AUX_CH/power well, or based on the VBT
defined AUX_CH->DDI->PHY relationship. At the moment we are
doing the former for the ANAOVRD workaround, and the latter
for the ICL_LANE_ENABLE_AUX override. Windows seems to use the
first approach for everything. So let's unify this to follow
that same approach for both.
Eventually we should try to figure out which is actually
correct, or whether any of this even matters (ie. whether there
are any real machines where the DDI and its AUX_CH do not match
1:1).
Note that this also changes the behaviour if we do end up
poking an AUX power well not associated with any port (as
per VBT). Previously we would have skipped the PHY register
write, but now we always write it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240229200357.7969-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
