summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-12drm/i915/display: identify discrete graphicsJani Nikula
Identify discrete graphics separately in display, using the platform group mechanism. This enables dropping the dependency on i915_drv.h IS_DGFX() from display code. Start grouping platform groups separately in INTEL_DISPLAY_PLATFORMS() in anticipation of more groups to come. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c02230d26cc0d9dbd7ddcc064661b2ad03739b6a.1731321183.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-12drm/i915/hdcp: Fix when the first read and write are retriedSuraj Kandpal
Make sure that the first read/write in hdcp2_authentication_key_exchange are only retried when we have either DP/DPMST encoder connected, since we do this to give docks and dp encoders some extra time to get their HDCP DPCD registers ready only for DP/DPMST encoders as this issue is only observed here no need to burden other encoders with extra retries as this causes the HDMI connector to have some other timing issue and fails HDCP authentication. --v2 -Add intent of patch [Chaitanya] -Add reasoning for loop [Jani] -Make sure we forfiet the 50ms wait for non DP/DPMST encoders. --v3 -Remove the is_dp_encoder check [Jani/Chaitanya] -Make the commit message more clearer [Jani] Fixes: 9d5a05f86d2f ("drm/i915/hdcp: Retry first read and writes to downstream") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241104035951.517837-1-suraj.kandpal@intel.com
2024-11-12drm/i915/scaler: Extract intel_allocate_scaler()Ville Syrjälä
intel_atomic_setup_scaler() is a mess. Make it a bit less so by moving the scaler allocation loop into its own function. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-9-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Make scaler in_use a boolVille Syrjälä
Make scaler in_use a boolean since that's how it's used. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-8-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Carve up intel_atomic_setup_scalers()Ville Syrjälä
Declutter intel_atomic_setup_scalers() a bit by splitting the crtc scaling/pfit vs. plane scaling cases into their own functions. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-7-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Convert the scaler code to intel_displayVille Syrjälä
struct intel_display will replace struct drm_i915_private as the main thing for display code. Convert the scaler code to use it (as much as possible at this stage). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-6-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Clean up intel_atomic_setup_scalers() a bitVille Syrjälä
intel_atomic_setup_scalers() is currently messing around with the internals of the atomic states. Stop doing that and instead use the regular interfaces so that we don't need to know any ugly implementation details. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-5-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Pass the whole atomic state into intel_atomic_setup_scalers()Ville Syrjälä
intel_atomic_setup_scalers() currently digs out the full atomic state from the crtc state. Flip that on its head so that we instead pass in the full atomic state and dig out the crtc state (and whatever else we need). This is generallte the better approach as it works in all phases of the atomic commit, whereas the other apporoach only really works during .atomic_check(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-4-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: Remove redudant junk from skl_scaler.hVille Syrjälä
Nuke some redundant includes and forward declarations from skl_scaler.h. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-3-ville.syrjala@linux.intel.com
2024-11-12drm/i915/scaler: s/intel_crtc/crtc/ etc.Ville Syrjälä
Rename some variables from the intel_foo to just foo, to match the more modern style used throughout the driver. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107122658.21901-2-ville.syrjala@linux.intel.com
2024-11-11drm/i915/crt: Nuke unused crt->connectorVille Syrjälä
crt->connector is never used, nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Rename some variablesVille Syrjälä
Rename a bunch of local variables to the preferred encoder/connector from intel_encoder/intel_connector. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Drop pointless drm_device variablesVille Syrjälä
Remove a bunch of pointless 'struct drm_device *dev' local variables. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: s/pipe_config/crtc_state/Ville Syrjälä
Call the crtc state 'crtc_state' rather than 'pipe_config', as is the modern style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Extract intel_crt_regs.hVille Syrjälä
Move the analog port register definitions into their own file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Clean up ADPA_HOTPLUG_BITS definitionsVille Syrjälä
ADPA_HOTPLUG_BITS is defined in terms of the individual register bits and is defined in intel_crt.c, whereas the counterpart mask (ADPA_CRT_HOTPLUG_MASK) is just defined as a raw hex constant and lives in i915_reg.h. Just define both the same way (with unified name to boot) and move both to intel_crt.c since they are more an implementation detail rather than anything to do with the actual register definitions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Use REG_BIT() & co.Ville Syrjälä
Follow the modern style and use REG_BIT() & co. for the analog port register definitions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Drop the unused ADPA_DPMS bit definitionsVille Syrjälä
The ADPA_DPMS bit definitions are just an alias for the sync disable bits, and unused one at that. Drop the pointless definitions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/crt: Split long lineVille Syrjälä
Split an overly long line in the CRT code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915: Grab intel_display from the encoder to avoid potential oopsiesVille Syrjälä
Grab the intel_display from 'encoder' rather than 'state' in the encoder hooks to avoid the massive footgun that is intel_sanitize_encoder(), which passes NULL as the 'state' argument to encoder .disable() and .post_disable(). TODO: figure out how to actually fix intel_sanitize_encoder()... Fixes: 40eb34c3f491 ("drm/i915/crt: convert to struct intel_display") Fixes: ab0b0eb5c85c ("drm/i915/tv: convert to struct intel_display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/psr: stop using bitwise OR with booleans in wm_optimization_wa()Jani Nikula
Bitwise OR for booleans is a bit of an abuse. We can trivially drop the usage. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f7ea5854c9a306f56f4142f8d37d567ee2f768a7.1730201504.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/psr: add LATENCY_REPORTING_REMOVED() register bit helperJani Nikula
Drop the wa_16013835468_bit_get() function in favour of the register macro. It doesn't have to be so complicated, and we don't have to use the workaround name in everything that's related to it. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/22934fee1ea37c777c35e4b520d5f11b6cd953d0.1730201504.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-11drm/i915/dp: demote source OUI read/write failure logging to debugJani Nikula
Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP sinks as well") started writing source OUI for non-eDP sinks as well, increasing the possibilities of hitting read/write failures either due to the sink behaviour or hotplug or whatever. Even before that, commit 3fb0501f0c07 ("drm/i915/display/dp: Reduce log level for SOURCE OUI write failures") already reduced write failures to info level when source OUI was just for eDP. Further reduce the log level to just debug. Switch to struct intel_display while at it. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3372 Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106162325.4065078-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-08drm/i915/xe3lpd: Use DMC wakelock by defaultGustavo Sousa
Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using DMC wakelock is the officially recommended way of accessing registers that would be off during DC5/DC6 and the legacy method (where the DMC intercepts MMIO to wake up the hardware) is to be avoided. As such, update the driver to use the DMC wakelock by default starting with Xe3_LPD. Since the feature is somewhat new to the driver, also allow disabling it via a module parameter for debugging purposes. For that, make the existing parameter allow values -1 (per-chip default), 0 (disabled) and 1 (enabled), similarly to what is done for other parameters. v2: - Describe -1 in the same area where 0 and 1 are described. (Luca) 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-16-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Sanitize enable_dmc_wl according to hardware supportGustavo Sousa
Instead of checking for HAS_DMC_WAKELOCK() multiple times, let's use it to sanitize the enable_dmc_wl parameter and use that variable when necessary. 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-15-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Add and use HAS_DMC_WAKELOCK()Gustavo Sousa
A HAS_DMC_WAKELOCK() macro gives more semantic than openly checking the display version. Define it and use it where appropriate. v2: - Make this patch contain only the non-functional refactor. Functional changes related to including HAS_DMC() in the macro are done in upcoming changes. (Jani) 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-14-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Couple enable/disable with dynamic DC statesGustavo Sousa
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
2024-11-08drm/i915/dmc_wl: Deal with existing references when disablingGustavo Sousa
It is possible that there are active wakelock references at the time we are disabling the DMC wakelock mechanism. We need to deal with that in two ways: (A) Implement the missing step from Bspec: The Bspec instructs us to clear any existing wakelock request bit after disabling the mechanism. That gives a clue that it is okay to disable while there are locks held and we do not need to wait for them. However, since the spec is not explicit about it, we need still to get confirmation with the hardware team. Let's thus implement the spec and add a TODO note. (B) Ensure a consistent driver state: The enable/disable logic would be problematic if the following sequence of events would happen: 1. Function A calls intel_dmc_wl_get(); 2. Some function calls intel_dmc_wl_disable(); 3. Some function calls intel_dmc_wl_enable(); 4. Function A is done and calls intel_dmc_wl_put(). At (2), the refcount becomes zero and then (4) causes an invalid decrement to the refcount. That would cause some issues: - At the time between (3) and (4), function A would think that the hardware lock is held but it could not be really held until intel_dmc_wl_get() is called by something else. - The call made to (4) could cause the refcount to become zero and consequently the hardware lock to be released while there could be innocent paths trusting they still have the lock. To fix that, we need to keep the refcount correctly in sync with intel_dmc_wl_{get,put}() calls and retake the hardware lock when enabling the DMC wakelock with a non-zero refcount. One missing piece left to be handled here is the following scenario: 1. Function A calls intel_dmc_wl_get(); 2. Some function calls intel_dmc_wl_disable(); 3. Some function calls intel_dmc_wl_enable(); 4. Concurrently with (3), function A performs the MMIO in between setting DMC_WAKELOCK_CFG_ENABLE and asserting the lock with __intel_dmc_wl_take(). I'm mostly sure this would cause issues future display IPs if DMC trap implementation was completely removed. We need to check with the hardware team whether it would be safe to assert the hardware lock before setting DMC_WAKELOCK_CFG_ENABLE to avoid this scenario. If not, then we would have to deal with that via software synchronization. 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-12-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Allow simpler syntax for single reg in range tablesGustavo Sousa
Allow simpler syntax for defining entries for single registers in range tables. That makes them easier to type as well as to read, allowing one to quickly tell whether a range actually refers to a single register or a "true range". 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-11-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Track registers touched by the DMCGustavo Sousa
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
2024-11-08drm/i915/dmc_wl: Rename lnl_wl_range to powered_off_rangesGustavo Sousa
In an upcoming change, we will add extra range tables for registers that are touched by the DMC during DC states. The range table that we are currently using is meant for registers that are powered off during DC states. As such, let's rename the table to powered_off_ranges and also add a comment regarding its purpose in the function that uses it. 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-9-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Extract intel_dmc_wl_reg_in_range()Gustavo Sousa
We will be using more than one range table in intel_dmc_wl_check_range(). As such, move the logic to a new function and name it intel_dmc_wl_reg_in_range(). 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-8-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use sentinel item for range tablesGustavo Sousa
We are currently using ARRAY_SIZE() to iterate address ranges in intel_dmc_wl_check_range(). In upcoming changes, we will be using more than a single table and will extract the range checking logic into a dedicated function that takes a range table as argument. As we will not able to use ARRAY_SIZE() then, let's make range tables contain a sentinel item at the end and use that instead of having to pass the size as parameter in this future function. 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-7-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Get wakelock when disabling dynamic DC statesGustavo Sousa
Bspec says that disabling dynamic DC states require taking the DMC wakelock to cause an DC exit before writing to DC_STATE_EN. Implement that. In fact, testing on PTL revealed we end up failing to exit DC5/6 without this step. Bspec: 71583 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-6-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Check for non-zero refcount in release workGustavo Sousa
When the DMC wakelock refcount reaches zero, we know that there are no users and that we can do the actual release operation on the hardware, which is queued with a delayed work. The idea of the delayed work is to avoid performing the release if a new lock user appears (i.e. refcount gets incremented) in a very short period of time. Based on the above, the release work should bail out if refcount is non-zero (meaning new lock users appeared in the meantime), but our current code actually does the opposite: it bails when refcount is zero. That means that the wakelock is not released when it should be; and that, when the work is not canceled in time, it ends up being releasing when it should not. Fix that by inverting the condition. 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-5-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use non-sleeping variant of MMIO waitGustavo Sousa
Some display MMIO transactions for offsets in the range that requires the DMC wakelock happen in atomic context (this has been confirmed during tests on PTL). That means that we need to use a non-sleeping variant of MMIO waiting function. Implement __intel_de_wait_for_register_atomic_nowl() and use it when waiting for acknowledgment of acquire/release. v2: - No __intel_de_wait_for_register_atomic_nowl() wrapper to convert i915 to display. (Jani) - Add a quick explanation why DMC_WAKELOCK_CTL_TIMEOUT_US is defined in microseconds. (Luca) 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-4-gustavo.sousa@intel.com
2024-11-08drm/xe: Mimic i915 behavior for non-sleeping MMIO waitGustavo Sousa
In upcoming display changes, we will modify the DMC wakelock MMIO waiting code to choose a non-sleeping variant implementation, because the wakelock is also taking in atomic context. While xe provides an explicit parameter (namely "atomic") to prevent xe_mmio_wait32() from sleeping, i915 does not and implements that behavior when slow_timeout_ms is zero. So, for now, let's mimic what i915 does to allow for display to use non-sleeping MMIO wait. In the future, we should come up with a better and explicit interface for this behavior in i915, at least while display code is not an independent entity with proper interfaces between xe and i915. v2: - Make the tone in comment the comment added in __intel_wait_for_register() more explanatory than a FIXME-like text. (Luca) 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-3-gustavo.sousa@intel.com
2024-11-08drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.regGustavo Sousa
The macro i915_mmio_reg_offset() is the proper interface to get a register's offset. Use that instead of looking directly at reg.reg. Reviewed-by: 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-2-gustavo.sousa@intel.com
2024-11-08drm/i915/psr: Disable Panel Replay as well if VRR is enabledJouni Högander
Having Panel Replay enabled together with VRR is causing following errors: xe 0000:00:02.0: [drm] *ERROR* Timed out waiting PSR idle state xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 xe 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00040080 xe 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00040080 Let's disable Panel Replay as well if VRR is enabled. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031081025.3215966-1-jouni.hogander@intel.com
2024-11-07drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4Suraj Kandpal
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in hdcp 2.2 and we are not using an hdmi transcoder and it need to be enabled when we are using an HDMI transcoder to enable HDCP 1.4. We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so we cannot depend on the value being 0 by default everytime which calls for seprate handling of HDCP 1.4 case. --v2 -Use the exising function and modify it based on a bool rather than have a different function [Matt] --v3 -No need for kzalloc [Jani] --v4 -i915_reg_t should not be pointer [Jani] -use rekey_bit to ensure when writing to reg everything is initialized Bspec: 69964, 50493, 50054 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107022807.869744-1-suraj.kandpal@intel.com
2024-11-07drm/i915/cdclk: Unify cdclk max() parameter orderVille Syrjälä
In some places we do min_cdclk = max(min_cdclk, other_min_cdclk) and in other places we have the arguments swapped as min_cdclk = max(other_min_cdclk, min_cdclk) Unify everyone to use the first order of arguments, because it looks cleaner, especially within intel_crtc_compute_min_cdclk() which is doing a lot of these back-to-back. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Relocate intel_vdsc_min_cdclk()Ville Syrjälä
Move intel_vdsc_min_cdclk() into intel_vdsc.c from intel_cdclk.c so that details about DSC are better contained. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Drop pointles max_t() usage in intel_vdsc_min_cdclk()Ville Syrjälä
min_cdclk==0 when intel_vdsc_min_cdclk() calls max_t() on it. Drop the redundant max_t(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Suck the compression_enable check into intel_vdsc_min_cdclk()Ville Syrjälä
Declutter intel_crtc_compute_min_cdclk() by moving the crtc_state->dsc.compression_enable check into intel_vdsc_min_cdclk(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Factor out INTEL_OUTPUT_DSI check in vlv_dsi_min_cdclk()Ville Syrjälä
All the if statements in vlv_dsi_min_cdclk() check for INTEL_OUTPUT_DSI. Make life simpler by checking that just once at the start. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract vlv_dsi_min_cdclk()Ville Syrjälä
Pull the DSI min cdclk calculation into a helper and hide it inside vlv_dsi.c in order to keep most DSI related details in one place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Factor out has_audio check in intel_audio_min_cdclk()Ville Syrjälä
All the if statements in intel_audio_min_cdclk() check for has_audio==true. Check that once ahead of time to make things a bit simpler. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract intel_audio_min_cdclk()Ville Syrjälä
Pull the audio min cdclk calculation into a helper and hide it inside intel_audio.c in order to keep most audio related details in one place. The one audio related thing that remains in intel_cdclk.c is commit 451eaa1a614c ("drm/i915: Bump GLK CDCLK frequency when driving multiple pipes") but given that's implemented in terms of the cdclk_state I think it should stay put. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract hsw_ips_min_cdclk()Ville Syrjälä
Pull the whole BDW IPS min CDCLK stuff into the IPS code so that all the details around IPS are contained in once place. Note that while - min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 95); vs. + min_cdclk = max(DIV_ROUND_UP(crtc_state->pixel_rate * 100, 95), min_cdclk) may look different, they are in fact the same because min_cdclk==crtc_state->pixel_rate at this point in intel_crtc_compute_min_cdclk() on BDW. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-07drm/i915/cdclk: Extract intel_cdclk_guardband() and intel_cdclk_ppc()Ville Syrjälä
We are duplicating the CDCLK guardband and "pixels per clock" figures in two places. Pull those out into small helpers that can be used by both places. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 23:15:12 +0000