aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2024-12-11drm/i915/display: clean up DP Adaptive Sync SDP state mismatch loggingJani Nikula1-19/+10
Pass the drm_printer from intel_pipe_config_compare(), and use it for logging, along with pipe_config_mismatch(), to simplify and unify. While at it, differentiate the VSC and AS SDP log texts from each other. Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241205093042.3028608-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-10drm/i915/display: use drm_print_hex_dump() for buffer mismatch dumpsJani Nikula1-15/+2
Use the drm_printer based printer to get the device specific printing of the hex dump, and avoid the manual loglevel hacking. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a536050b5f9dc2d7de32d29766c98477f58d746c.1733392101.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-10drm/i915/display: use drm_print_hex_dump() for crtc state dumpJani Nikula1-12/+2
Use the drm_printer based printer to get the device specific printing of the hex dump. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/12d76e34ed4c508524f768a46d2a2beb09991a23.1733392101.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-10drm/print: add drm_print_hex_dump()Jani Nikula2-0/+25
Add a helper to print a hex dump to a struct drm_printer. There's no fancy formatting stuff, just 16 space-separated bytes per line, with an optional prefix. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/f650fe1ed3e3bb74760426fa7461c3b028d661fb.1733392101.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-10drm/i915/mst: add beginnings of DP MST documentationJani Nikula1-0/+32
Add a little bit of documentation around DP MST. This is nowhere near complete nor does it have enough detail. But it's better than nothing, and hopefully gives people a basic grasp of what's going on. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241125151933.2382910-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09drm/i915/pps: include panel power cycle delay in debugfsJani Nikula1-0/+2
The debugfs contains all the other timings except panel power cycle delay. Add it for completeness. Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 9360 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241205123720.3278727-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09drm/i915/pps: debug log the remaining power cycle delay to waitJani Nikula1-9/+10
While pps_init_delays() debug logs the power cycle delay, also debug log the actual remaining time to wait in wait_panel_power_cycle(). Note that this still isn't the full picture; the power sequencer may still wait after this one. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13007 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 Link: https://patchwork.freedesktop.org/patch/msgid/20241204160048.2774419-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-09drm/i915/display: convert intel_display_driver.[ch] to struct intel_displayJani Nikula14-220/+238
Going forward, struct intel_display will be the main display driver structure. Convert the main display entry points to struct intel_display. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241204102150.2223455-1-jani.nikula@intel.com
2024-12-05drm/i915/wm: Club initialized variables of same type togetherSuraj Kandpal1-1/+1
Refactor program_dpkgc function so that all initialized variables of same type are clubbed together. --v2 -Modify commit message to reflect what is being done in patch [Mitul] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-6-suraj.kandpal@intel.com
2024-12-05drm/i915/wm: Modify latency programmed into PKG_C_LATENCYSuraj Kandpal1-5/+14
Increase the latency programmed into PKG_C_LATENCY latency to be a multiple of line time which is written into WM_LINETIME. --v2 -Fix commit subject line [Sai Teja] -Use individual DISPLAY_VER checks instead of range [Sai Teja] -Initialize max_linetime [Sai Teja] --v3 -take into account the scenario when adjusted_latency is 0 [Vinod] --v4 -rename adjusted_latency to latency [Mitul] -fix the condition in which dpkgc is disabled [Vinod] --v5 -Add check to see if max_linetime is 0 [Vinod] --v6 -Avoid nested if statements [Mitul] WA: 22020299601 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-5-suraj.kandpal@intel.com
2024-12-05drm/i915/display: Refactor DPKGC code to call it from atomic_commit_tailSuraj Kandpal3-12/+19
Refactor the code to check the fixed refresh rate condition in the dpkgc function itself and call it from intel_atomic_commit_tail so that we have all the required values specially linetime which is computed after intel_wm_compute, this will also help implement some WA's which requires linetime. This also avoid writing into any of the registers while we are in compute_config phase. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-4-suraj.kandpal@intel.com
2024-12-05drm/i915/wm: Use intel_display structure in DPKGC codeSuraj Kandpal1-3/+4
Use intel_display for DPKGC code wherever we can. While we are at it also use intel_de_rmw instead of intel_uncore_rmw as we really don't need the internal uncore_rmw_function. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-3-suraj.kandpal@intel.com
2024-12-05drm/i915/wm: Refactor dpkgc value preprationSuraj Kandpal1-4/+4
Refactor the value getting prepped to be written into the PKG_C_LATENCY register by ORing the REG_FIELD_PREP values instead of having val getting operated on twice. We dont need the clear and val variables to be initialized. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-2-suraj.kandpal@intel.com
2024-12-05drm/i915/wm: Initialize max_latency variable to appropriate valueSuraj Kandpal1-4/+1
Initialize max_latency variable to LNL_PKG_C_LATENCY_MASK which helps to eliminate the else block and make the whole code a lot cleaner. --v2 -Seprate patch to club variables together [Mitul] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203084706.2126189-1-suraj.kandpal@intel.com
2024-12-04drm/i915: Fix memory leak by correcting cache object name in error handlerJiasheng Jiang1-1/+1
Replace "slab_priorities" with "slab_dependencies" in the error handler to avoid memory leak. Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global") Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by: Jiasheng Jiang <jiashengjiangcool@outlook.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127201042.29620-1-jiashengjiangcool@gmail.com
2024-12-04drm/i915: Fix NULL pointer dereference in capture_engineEugene Kobyak1-3/+15
When the intel_context structure contains NULL, it raises a NULL pointer dereference error in drm_info(). Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12309 Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by: Eugene Kobyak <eugene.kobyak@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/xmsgfynkhycw3cf56akp4he2ffg44vuratocsysaowbsnhutzi@augnqbm777at
2024-12-04drm/i915/cx0: split out mtl_get_cx0_buf_trans() to c10 and c20 variantsJani Nikula1-7/+16
The PHY is either c10 or c20, there's no need to check at runtime and complicate the conditions in mtl_get_cx0_buf_trans(). While at it, replace the direct port clock check with intel_dp_is_uhbr(). Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129114158.486418-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-03drm/i915/display: remove unused for_each_crtc()Jani Nikula1-3/+0
This is essentially a duplicate of drm_for_each_crtc() anyway. Remove. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241202125437.1154945-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-02drm/i915/display: replace dig_port->saved_port_bits with flagsJani Nikula4-23/+29
dig_port->saved_port_bits is used to permanently store two DDI_BUF_CTL bits, DDI_BUF_PORT_REVERSAL and DDI_A_4_LANES. Store them separately as bools to make their use more logical and less about storing state as register bits. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129102503.452272-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-02drm/i915/display: convert power map to struct intel_displayJani Nikula1-28/+28
Going forward, struct intel_display is the main device data structure for display. Convert the power map code to it. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9df6b67914cd5afe7107c8431e8c475794b62298.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert high level power interfaces to struct intel_displayJani Nikula8-90/+98
Going forward, struct intel_display is the main device data structure for display. Convert the high level interfaces (init, cleanup, suspend, resume, etc.) of intel_display_power.c over to it. The actual power get/put etc. are left for follow-up. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e1761b0fe5081bf6ca21cca3430befe254f61b32.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert power domain code internally to struct intel_displayJani Nikula1-392/+414
Going forward, struct intel_display is the main device data structure for display. Convert intel_display_power.c internally first, leaving external interfaces for follow-up. v2: Rebase, checkpatch fixes Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d3284b30b53dd2fec786775ccb8992939360d774.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert power wells to struct intel_displayJani Nikula7-332/+321
Going forward, struct intel_display is the main device data structure for display. Switch the power well code over to it. v2: Fix parenthesis alignment Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b8c0ff5502a5df55ec7a160d90257c6f2befc0b6.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert for_each_power_domain_well() to struct intel_displayJani Nikula1-7/+10
Start converting display power domain code to struct intel_display. Start off with for_each_power_domain_well() and the reverse variant. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d21752baef1cab52ac3bec4f4e1f09f9acd6c1bf.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert for_each_power_well() to struct intel_displayJani Nikula3-15/+20
Start converting power well code to struct intel_display. Start off with for_each_power_well() and the reverse variant. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/30c3e44cdb9557a195b2e086bf169da8d8497c6b.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/hdcp: Remove log for HDMI HDCP LIC checkSuraj Kandpal1-2/+0
We don't need to shout out loud if there is a Link Integrity Failure. This does not mean HDCP has failed, it is expected and taken into account in the HDCP Spec. The real failure happens when we are not able to reauthenticate and get HDCP running again for which we already have the right logging. --v2 -Remove the log altogether [Ankit] --v3 -Remove useless display variable Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241202060410.1872121-1-suraj.kandpal@intel.com
2024-11-30drm/xe/display: Flush DMC wakelock release work on runtime suspendGustavo Sousa1-0/+10
We currently are not calling display runtime suspend functions when D3cold is not allowed. Because of that, we end up not disabling dynamic DC states (and do not go to DC9). With dynamic DC states enabled, we will also have DMC wakelock enabled. Since we use a delayed work to release the DMC wakelock, the work might get executed a little too late (after the PCI device has been put to D3hot) and we get a timeout warning ("DMC wakelock release timed out") because the MMIO for releasing the wakelock will be invalid after that point. To fix that, make sure we flush the release work at the end of xe_display_pm_runtime_suspend_late(). We can do that unconditionally because, if there is no pending work, that turns into a no-op. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-4-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-30drm/xe/display: Extract xe_display_pm_runtime_suspend_late()Gustavo Sousa3-2/+13
The current behavior for the runtime suspend case is that xe_display_pm_suspend_late() is only called when D3cold is allowed. Let's incorporate that behavior into a function specific to runtime PM and call it xe_display_pm_runtime_suspend_late(). With that, we keep stuff a bit more self-contained and allow having a place for adding more "late display runtime suspend"-related logic that isn't dependent on the "D3cold allowed" state. v2: - Fix typo in that caused xe_display_pm_runtime_suspend_late() to call itself instead of xe_display_pm_suspend_late(). - Add the empty version of xe_display_pm_runtime_suspend_late() for the !CONFIG_DRM_XE_DISPLAY case. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-3-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-30drm/i915/dmc_wl: Extract intel_dmc_wl_flush_release_work()Gustavo Sousa2-1/+12
We will need to flush the release work from outside in an upcoming change. Let's put that into a public interface and call it intel_dmc_wl_flush_release_work(). Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-2-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-29drm/i915/dp: use seq buf for printing ratesJani Nikula1-22/+14
Hand rolling the buffer overflow handling with snprintf() is a bit tedious. The seq_buf interface is made for this. Switch to it. Use struct intel_display while at it. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127131838.3268735-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Eliminate pointless get_delay() macroVille Syrjälä1-7/+5
Now that we have pps_units_to_msecs(), get_delay() looks rather pointless. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Extract pps_units_to_msecs()Ville Syrjälä1-1/+7
Add pps_units_to_msecs() as the counterpart to msecs_pps_units_to(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Extract msecs_to_pps_units()Ville Syrjälä1-9/+14
Replace all the hand rolled *10 stuff with something a bit more descriptive (msecs_to_pps_units()). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Spell out the eDP spec power sequencing delays a bit more clearlyVille Syrjälä1-2/+2
We determine the "spec" eDP power sequencing delays by referencing some max values from the eDP spec. Write out each number from the spec explicitly instead of precomputing the final number (that's the job of the computer). Makes it a bit easier to see what the supposed spec defined numbers actually are. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/lvds: Use struct intel_pps_delays for LVDS power sequencingVille Syrjälä2-29/+30
Reuse struct intel_pps_delays for the LVDS power sequencing delays instead of hand rolling it all. Perhaps in the future we could reuse some of the same PPS code for both LVDS and eDP (assuming we can decouple the PPS code from intel_dp...). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Rename intel_pps_delay membersVille Syrjälä3-54/+58
Stop using the semi-random eDP spec T1,T3,... names for the power sequencing delays, and instead call them by their human readable names. Much easier to keep track what delay goes where when you don't have to constantly cross reference against the eDP spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Decouple pps delays from VBT struct definitionVille Syrjälä6-25/+42
We currently lack a proper struct definition for the VBT power squencing delays, and instead we use the same struct definition (in intel_bios.h) for both the VBT layout and our driver side state. Decouple those two things by moving the current struct into intel_vbt_defs.h and adding a new one for the driver's use. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Store the power cycle delay without the +1Ville Syrjälä1-16/+12
The code initializing the power sequencing delays is a bit hard to follow. One confusing thing is that we keep doing the +/-1 adjustment for the hardware register value in several places. Simplify this a bit by doing the adjustment only when reading or writing the actual register. This also matches how the LVDS code does things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/dsb: Nuke the MMIO->indexed register write logicVille Syrjälä1-44/+14
We've determined that indexed DSB writes are only faster than MMIO writes when writing the same register ~5 or more times. That seems very unlikely to happen in any other case than when using indexed LUT registers. Simplify the code by removing the MMIO->indexed write conversion logic and just emit the instruction as an indexed write from the get go. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28drm/i915/color: Stop using non-posted DSB writes for legacy LUTVille Syrjälä1-10/+20
DSB LUT register writes vs. palette anti-collision logic appear to interact in interesting ways: - posted DSB writes simply vanish into thin air while anti-collision is active - non-posted DSB writes actually get blocked by the anti-collision logic, but unfortunately this ends up hogging the bus for long enough that unrelated parallel CPU MMIO accesses start to disappear instead Even though we are updating the LUT during vblank we aren't immune to the anti-collision logic because it kicks in briefly for pipe prefill (initiated at frame start). The safe time window for performing the LUT update is thus between the undelayed vblank and frame start. Turns out that with low enough CDCLK frequency (DSB execution speed depends on CDCLK) we can exceed that. As we are currently using non-posted writes for the legacy LUT updates, in which case we can hit the far more severe failure mode. The problem is exacerbated by the fact that non-posted writes are much slower than posted writes (~4x it seems). To mititage the problem let's switch to using posted DSB writes for legacy LUT updates (which will involve using the double write approach to avoid other problems with DSB vs. legacy LUT writes). Despite writing each register twice this will in fact make the legacy LUT update faster when compared to the non-posted write approach, making the problem less likely to appear. The failure mode is also less severe. This isn't the 100% solution we need though. That will involve estimating how long the LUT update will take, and pushing frame start and/or delayed vblank forward to guarantee that the update will have finished by the time the pipe prefill starts... Cc: stable@vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12494 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28drm/i915/dsb: Don't use indexed register writes needlesslyVille Syrjälä3-23/+49
Turns out the DSB indexed register write command has rather significant initial overhead compared to the normal MMIO write command. Based on some quick experiments on TGL you have to write the register at least ~5 times for the indexed write command to come out ahead. If you write the register less times than that the MMIO write is faster. So it seems my automagic indexed write logic was a bit misguided. Go back to the original approach only use indexed writes for the cases we know will benefit from it (indexed LUT register updates). Currently we shouldn't have any cases where this truly matters (just some rare double writes to the precision LUT index registers), but we will need to switch the legacy LUT updates to write each LUT register twice (to avoid some palette anti-collision logic troubles). This would be close to the worst case for using indexed writes (two writes per register, and 256 separate registers). Using the MMIO write command should shave off around 30% of the execution time compared to using the indexed write command. Cc: stable@vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28Revert "drm/i915/dpt: Make DPT object unshrinkable"Ville Syrjälä1-3/+1
This reverts commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c. Now that we forcefully evict all DPT VMAs during suspend there should be no problem allowing the shrinker to eat the DPT objects. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12965 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-5-ville.syrjala@linux.intel.com Acked-by: Brian Geffon <bgeffon@google.com> Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915/dpt: Evict all DPT VMAs on suspendVille Syrjälä4-9/+21
Currently intel_dpt_resume() tries to blindly rewrite all the PTEs for currently bound DPT VMAs. That is problematic because the CPU mapping for the DPT is only really guaranteed to exist while the DPT object has been pinned. In the past we worked around this issue by making DPT objects unshrinkable, but that is undesirable as it'll waste physical RAM. Let's instead forcefully evict all the DPT VMAs on suspend, thus guaranteeing that intel_dpt_resume() has nothing to do. To guarantee that all the DPT VMAs are evictable by intel_dpt_suspend() we need to flush the cleanup workqueue after the display output has been shut down. And for good measure throw in a few extra WARNs to catch any mistakes. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-4-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915: Intruduce display.wq.cleanupVille Syrjälä3-1/+7
Introduce a dedicated workqueue for the commit cleanup work. In the future we'll need this to guarantee all the cleanup works have finished at a specific point during suspend. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-3-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915: Don't reuse commit_work for the cleanupVille Syrjälä2-3/+5
Currently we reuse the commit_work for a later cleanup step. Let's not do that so that atomic ioctl handler won't accidentally wait for the cleanup work when it really wants to just wait on the commit_tail() part. We'll just add another work struct for the cleanup. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-2-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-27drm/i915/dislay: convert i9xx_display_sr.[ch] to struct intel_displayJani Nikula3-45/+41
Going forward, struct intel_display is the main device data structure for display. Switch to it. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126101222.2671224-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-27drm/i915/display: prefer DISPLAY_VER over GRAPHICS_VER in display s/rJani Nikula1-8/+8
Use display version checks for display scratch registers, not graphics version. And for the older platforms it's the same thing anyway. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126101222.2671224-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-26drm/i915/ddi: clarify intel_ddi_connector_get_hw_state() for DP MSTJani Nikula1-4/+7
encoder->get_hw_state() returns false for DP MST, and currently always interprets 128b/132b as MST. Therefore the DDI MST mode checks in intel_ddi_connector_get_hw_state() are redundant. Prepare for future, and handle 128b/132b SST and warn on 8b/10b MST. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241125120959.2366419-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-25drm/i915: Fixed an typo in i915_gem_gtt.cZhang He1-1/+1
in function `i915_gem_gtt_reserve` @node comment, i915_vma has no `mode` member, `i915_vma.node` is the correct name Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Zhang He <zhanghe9702@163.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120123245.71101-1-zhanghe9702@163.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-22drm/i915/irq: emphasize display_irqs_enabled is only about VLV/CHVJani Nikula3-20/+21
Use display_irqs_enabled only on VLV/CHV where it's relevant. Rename to vlv_display_irqs_enabled, to emphasize it's really only about VLV/CHV. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f60104ea59687cb8c65b18b4f9ddd832a643407d.1732102179.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.