summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_cdclk.c
AgeCommit message (Collapse)Author
2025-04-22drm/i915/display: pass struct intel_display to PCH macrosJani Nikula
Now that INTEL_PCH_TYPE() and HAS_PCH_*() macros are under display, and accept a struct intel_display pointer, use that instead of struct drm_i915_private pointer in display code. This is done naively by running: $ sed -i 's/\(INTEL_PCH_TYPE\|HAS_PCH_[A-Z0-9_-]*\)([^)]*)/\1(display)/g' \ $(find drivers/gpu/drm/i915/display -name "*.c") and fixing the fallout, i.e. removing unused local i915 variables and adding display variables where needed. v2: Rebase Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/r/999f4d7b8ed11739b1c5ec8d6408fc39d5e3776b.1744880985.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-09drm/i915/wm: convert skl_watermark.h external interfaces to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device data pointer. Convert the skl_watermark.h interface to struct intel_display. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/cd2b1863dee25b69b4766090dd183a7467c4edea.1744119460.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-04-04drm/i915: Do more bw readoutVille Syrjälä
Update a bunch of bw related stuff during readout: - bw_state->dbuf_bw possible now that the wm readout has given us access to the plane ddb data - cdclk_state->bw_min_cdclk Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326162544.3642-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-03-13drm/i915/display: Convert intel_bw.c externally to intel_displayGustavo Sousa
We already have internal interface for intel_bw.c converted to use intel_display. Now convert the external interface as well. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311-xe3lpd-bandwidth-update-v5-2-a95a9d90ad71@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-03-07drm/i915: Simplify cdclk_disable_noatomic()Ville Syrjälä
Instead of hand rolling the cdclk state disabling for a pipe in noatomic() let's just recompute the whole thing from scratch. Less code we have to remember to keep in sync. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-15-ville.syrjala@linux.intel.com
2025-03-07sem/i915: Simplify intel_cdclk_update_hw_state()Ville Syrjälä
intel_crtc_calculate_min_cdclk() can't return an error (since commit 5ac860cc5254 ("drm/i915: Fix DBUF bandwidth vs. cdclk handling")) so there is no point in checking for one. Also we can just call it unconditionally since it itself checks crtc_state->hw.enabled. We are currently checking crtc_state->hw.active in the readout path, but active==enabled during readout, and arguably enabled is the more correct thing to check anyway. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-14-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Extract intel_cdclk_update_hw_state()Ville Syrjälä
Hoist the cdclk stuff into a separate function from intel_modeset_readout_hw_state() so that the details are better hidden inside intel_cdclk.c. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-10-ville.syrjala@linux.intel.com
2025-03-07drm/i915: Extract intel_cdclk_crtc_disable_noatomic()Ville Syrjälä
Hoist the cdclk stuff into a separate function from intel_crtc_disable_noatomic_complete() so that the details are better hidden inside intel_cdclk.c. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-5-ville.syrjala@linux.intel.com
2025-02-10drm/i915: Convert intel_display_power_{get,put}*() to intel_displayVille Syrjälä
Pass intel_display to the display power stuff. These are spread all over the place so tend to hinder clean conversions of whole files. TODO: The gt part/unpark power domain shenanigans need some kind of more abstract interface... v2: Deal with cmtg 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/20250206185533.32306-7-ville.syrjala@linux.intel.com
2025-02-05drm/i915/cdclk: switch to new platform checksJani Nikula
Switch the IS_<PLATFORM>() checks to display->platform.<platform>, and drop a number of struct drm_i915_private pointers in the process. While at it, replace /* NOOP */; with ; /* NOOP */ to avoid a checkpatch warning on misleading indentation. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204134228.2934744-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-23drm/i915/display: fix typos in i915/display filesNitin Gote
Fix all typos in files under drm/i915/display reported by codespell tool. v2: - Include british and american spelling, as those are not typos. - Fix commenting style. <Jani> v3: Fix "In case" wrongly capitalized and also fix comment style. <Krzysztof Niemiec> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250120081517.3237326-8-nitin.r.gote@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-14drm/i915/audio: convert to struct intel_displayJani Nikula
Going forward, struct intel_display will be the main display device structure. Convert intel_audio.[ch] to it, as much as possible anyway. Do some minor checkpatch fixes while at it. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4ddcc2e704fc6b1592a878c80e15fadd82c63550.1736345025.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-07drm/i915/display: convert global state to struct intel_displayJani Nikula
Going forward, struct intel_display is the main display device structure. Convert intel_global_state.[ch] to it. This allows us to make intel_pmdemand.c completely independent of i915_drv.h. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2b5e743b285a86a59ee87085727847c758c8d552.1735662324.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-16drm/i915/uncore: add to_intel_uncore() and use itJani Nikula
Add to_intel_uncore() function to avoid the inclusion of i915_drv.h from intel_de.h. This reveals a number of implicit dependencies on i915_drv.h that need to be added. For now, to_intel_uncore() can be an inline function, with all the includes in compat intel_uncore.h, as long as i915_drv.h isn't included. The implicit dependencies on i915_drv.h is a problem in display code, but the same is not true for xe_device.h etc. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/377e2b400d126776224fc49874ed9cb03ac3123c.1732104170.git.jani.nikula@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: 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: 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>
2024-11-07drm/i915: Introduce HAS_DOUBLE_WIDE()Ville Syrjälä
Make the code a bit more self documenting by adding HAS_DOUBLE_WIDE(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029215217.3697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-30drm/i915/display: use x100 version for full version and releaseJani Nikula
Use x100, or ver * 100 + rel, versions for full IP version checks, similar to what xe driver does: - Replace IP_VER(14, 1) inline with 1401, etc. - Convert DISPLAY_VER_FULL() to DISPLAY_VERx100() - Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100() - Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP() This makes ver.rel versions easier to use, follows the xe driver pattern, and drops the dependency on the IP_VER() macro. v2: Rebase, drop IP_VER() from xe compat headers v3: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com
2024-10-23drm/i915/xe3lpd: Add cdclk changesRadhakrishna Sripada
Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table and modify/add higher frequencies. Updating the max cdclk supported by the platform and voltage_level determination is also updated. There are minor changes in cdclk programming sequence compared to lnl, where programming cd2x divider needs to be skipped. This is already handled by the calculations in existing code. v2: update tables v3: xe3lpd doesn't supply the power control unit the voltage index Bspec: 68861, 68863, 68864 Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-3-matthew.s.atwood@intel.com
2024-09-11drm/i915/cdclk: Convert CDCLK code to intel_displayVille Syrjälä
struct intel_display will replace struct drm_i915_private as the main thing for display code. Convert the CDCLK code to use it (as much as possible at this stage). v2: Add local 'display' variable to __intel_display_device_info_runtime_init() (Jani) Simplify the to_intel_display(crtc_state) stuff (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906143306.15937-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-09-11drm/i915/cdclk: Add missing bracesVille Syrjälä
CodingStyle says when one branch of an if ladder is braced then all of them should be. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906143306.15937-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-09-05drm/i915/display: pass display to intel_crtc_for_pipe()Jani Nikula
Convert the intel_crtc_for_pipe() struct drm_i915_private parameter to struct intel_display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240904130633.3831492-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-05drm/i915/display: include media/cec-notifier.h and linux/debugfs.h where neededJani Nikula
Use a forward declaration for struct cec_notifier instead of including media/cec-notifier.h in intel_display_types.h, and only include it where needed. Also realize that a lot of places depend on including linux/debugfs.h via intel_display_types.h -> media/cec-notifier.h -> media/cec.h, and include that too where needed. v2: hsw_ips.c also needs debugfs.h (kernel test robot) Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240827104521.4151471-1-jani.nikula@intel.com
2024-08-06drm/i915: Replace to_bpp_int_roundup() with fxp_q4_to_int_roundup()Imre Deak
Replace the to_bpp_int_roundup() helper defined by the driver with the equivalent fxp_q4_to_int_roundup() helper defined by DRM core. v2: Rebase on s/drm_x16/fxp_q4 change. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240805150802.3568970-4-imre.deak@intel.com
2024-06-17drm/i915: move comments about FSB straps to proper placeJani Nikula
Move the comment about FSB straps to where the relevant register is read. 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/8a5b6cd3db80259c30263861f1a9ff04fea2e7f0.1718356614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-06-17drm/i915/cdclk: use i9xx_fsb_freq() for rawclk_freq initializationJani Nikula
Instead of duplicating the CLKCFG parsing, reuse i9xx_fsb_freq() to figure out rawclk_freq where applicable. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/21511f155f1f446e066117bc6ed3165618d7afd6.1718356614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-06-12drm/i915: Rename all bigjoiner to joinerStanislav Lisovskiy
Lets unify both bigjoiner and ultrajoiner under simple "joiner" name, because in future we might have multiple configurations, involving multiple bigjoiners, ultrajoiner, however it is possible to use same api for handling both. v2: - Renamed back some bigjoiner specific parts for now(Ville) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> [vsyrjala: Catch a few more cases] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240607075457.15700-1-stanislav.lisovskiy@intel.com
2024-05-31drm/i915/cdclk: Plumb the full atomic state deeperVille Syrjälä
Various parts of the cdclk code need access the full atomic state. Currently it's being dug out via the cdclk_state->base.state pointer, which is not great as that pointer isn't always valid. Instead plumb the full atomic state from the top so that it's clear that it is in fact valid. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528184945.24083-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-03drm/i915/xe2hpd: Initial cdclk tableClint Taylor
Add Xe2_HPD specific CDCLK table and use MTL Funcs. Bspec: 65243 CC: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-4-radhakrishna.sripada@intel.com
2024-04-09drm/i915: move max_dotclk_freq to display substructJani Nikula
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ea012aa72c93f3d436ccacf8f75683757d144b82.1712599670.git.jani.nikula@intel.com
2024-04-09drm/i915: move skl_preferred_vco_freq to display substructJani Nikula
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4e9877d1641bce905cc9dd5eabe40df51ddbe9b5.1712599670.git.jani.nikula@intel.com
2024-04-04drm/i915: Use a plain old int for the cdclk/mdclk ratioVille Syrjälä
No point in throwing around u8 when we're dealing with just an integer. Use a plain old boring 'int'. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-14-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Use the correct mdclk/cdclk ratio in MBUS updatesVille Syrjälä
The current cdclk/mbus programming sequence is as follows: 1. intel_set_cdclk_pre_plane_update() 2. update_mbus_pre_enable() 3. intel_set_cdclk_post_plane_update() when the actual mdclk/cdclk programming is postponed to intel_set_cdclk_post_plane_update() we must keep using the old mdclk/cdclk ratio during update_mbus_pre_enable(). This guarantees the programmed ratio matches the rest of the hardware state (mdlk/cdclk/mbus joining). v2: Extracted from the vblank synchronized mbus programming patch Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-12-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Use old mbus_join value when increasing CDCLKStanislav Lisovskiy
In order to make sure we are not breaking the proper sequence let's do updates step by step and don't change MBUS join value during MDCLK/CDCLK programming stage. MBUS join programming would be taken care by pre/post ddb hooks. v2: - Reworded comment about using old mbus_join value in intel_set_cdclk(Ville Syrjälä) Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> [v3: vsyrjala: rebase on top of cdclk changes, reword a bit more] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-11-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Indicate whether CDCLK change happens during pre or post ↵Ville Syrjälä
plane update Currently we just get a plain "Changing CDCLK to ..." in the logs. It would actually be interesting to see whether we're doing the programming during the pre or post plane phase of the commit. Include that information in the debug message. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-5-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacksVille Syrjälä
No one ever figured out why bumping the cdclk helped with whatever issue we were having at the time. Remove the hacks and start from scratch so that we can actually see if any problems still remain. 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/20240402155016.13733-4-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Fix voltage_level programming edge caseVille Syrjälä
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: stable@vger.kernel.org Cc: Gustavo Sousa <gustavo.sousa@intel.com> 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/20240402155016.13733-3-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Fix CDCLK programming order when pipes are activeVille Syrjälä
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: stable@vger.kernel.org Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-2-ville.syrjala@linux.intel.com
2024-03-13drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changesGustavo Sousa
Commit 394b4b7df9f7 ("drm/i915/lnl: Add CDCLK table") and commit 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL") started adding support for CDCLK programming support for Xe2LPD. One final piece is missing, which is the programming necessary for changed in the ratio between MDCLK and CDCLK. Let's do that now. BSpec instructs us to update MBUS_CTL and DBUF_CTL_S* registers when the ratio between MDCLK and CDCLK changes. The updates must be done before changing the CDCLK when decreasing the frequency; or after it when increasing the frequency. Ratio-related updates to MBUS_CTL also depend on the state of MBus joining, so they are performed by either CDCLK change sequence or by changes in MBus joining. Since one might happen independently of the other, we need to make sure that both logics see the necessary state values when programming that register. MBus joining logic needs to know the MDCLK:CDCLK ratio and that's already provided via mdclk_cdclk_ratio field of struct intel_dbuf_state. For the CDCLK logic, we need to have something similar: we need to propagate the status of MBus joining to struct intel_cdclk_state. Do that by adding the field joined_mbus to struct intel_cdclk_config. (Preferably, that field would be added to intel_cdclk_state, however currently only intel_cdclk_config is passed down to the functions that do the register programming. We might revisit this decision if we find that refactoring the code to pass the whole intel_cdclk_state is worth it.) Bspec: 68864, 68868, 69090, 69482 Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-7-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-13drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_stateGustavo Sousa
Xe2LPD always selects the CDCLK PLL as source for the MDCLK. Because of that, the ratio between MDCLK and CDCLK is not be constant anymore. As such, make sure to have the current ratio available in intel_dbuf_state so that it can be used during dbuf programming. Note that we write-lock the global state instead of serializing to a hardware commit because a change in the ratio should be rather handled in the CDCLK change sequence, which will need to take care of updating the necessary registers in that case. We will implement that in upcoming changes. That said, changes in the MBus joining state should be handled by the DBUF/MBUS logic, just like it is already done, but the logic will need to know the ratio to properly update the registers. v2: - Make first sentence of commit message more intelligible. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-6-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-13drm/i915/cdclk: Only compute squash waveform when necessaryGustavo Sousa
It is no use computing the squash waveform if we are not going to use it. Move the call to cdclk_squash_waveform() inside the block guarded by HAS_CDCLK_SQUASH(dev_priv). v2: - Move "u16 waveform" declaration to inside the block where it is initialized and used. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-4-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-13drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()Gustavo Sousa
Currently, only Xe2LPD uses CDCLK PLL as the source of MDCLK and previous display IPs use the CD2XCLK. There will be changes in code paths common to those platforms that will rely on which source is being used. As such, let's make that information explicit with the addition of the predicate function mdclk_source_is_cdclk_pll(). Arguably, an enum could be created, but using a boolean should suffice here, since we there are only two possible sources and the logic that will rely on it will be very localized. In order to get the code into a more consistent state, let's also take this opportunity to hook the selection of CDCLK_CTL's "MDCLK Source Select" to that new function. Even though currently only MDCLK_SOURCE_SEL_CDCLK_PLL will be returned, having this extra logic is arguably better than keeping stuff untied and prone to bugs. v2: - Extract mdclk_source_is_cdclk_pll() out of xe2lpd_mdclk_source_sel() to make latter only about the register's field. Bspec: 69090, 68861 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-3-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-13drm/i915/cdclk: Rename lnl_cdclk_table to xe2lpd_cdclk_tableGustavo Sousa
The CDCLK table is tied to Xe2LPD display and not to the platform. Let's rename lnl_cdclk_table to xe2lpd_cdclk_table in order to reflect that. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312163639.172321-2-gustavo.sousa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-03-11drm/i915: Reuse RPLU cdclk fns for MTL+Radhakrishna Sripada
MTL/LNL use the same cdclk functions as RPLU albeit with different tables. Having separate tables and not requiring special handling for the platforms, reuse RPLU cdclk functions. v2: Update subject and the commit message(Jani) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228214854.2530205-1-radhakrishna.sripada@intel.com
generated by cgit (git 2.34.1) at 2025-07-10 04:43:22 +0000