summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_cursor.c
AgeCommit message (Collapse)Author
2024-10-04drm/i915: Plumb 'dsb' all way to the plane hooksVille Syrjälä
We need to be able to do both MMIO and DSB based pipe/plane programming. To that end plumb the 'dsb' all way from the top into the plane commit hooks. The compiler appears smart enough to combine the branches from all the back-to-back register writes into a single branch. So the generated asm ends up looking more or less like this: plane_hook() { if (dsb) { intel_dsb_reg_write(); intel_dsb_reg_write(); ... } else { intel_de_write_fw(); intel_de_write_fw(); ... } } which seems like a reasonably efficient way to do this. An alternative I was also considering is some kind of closure (register write function + display vs. dsb pointer passed to it). That does result is smaller code as there are no branches anymore, but having each register access go via function pointer sounds less efficient. Not that I actually measured the overhead of either approach yet. Also the reg_rw tracepoint seems to be making a huge mess of the generated code for the mmio path. And additionally there's some kind of IS_GSI_REG() hack in __raw_uncore_read() which ends up generating a pointless branch for every mmio register access. So looks like there might be quite a bit of room for improvement in the mmio path still. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-12-ville.syrjala@linux.intel.com
2024-09-19drm/i915/display: clean up some gem/ includesJani Nikula
Drop some unnecessary gem/ includes. We seem to include xe_device.h through some compat gem headers, so we need to include it directly in compat i915_drv.h to get xe_device_has_flat_ccs(). Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/afd2917cc0a943660886937bb5f45c277132e147.1726589119.git.jani.nikula@intel.com
2024-09-05drm/i915/display: include drm/drm_vblank.h where neededJani Nikula
Stop including drm/drm_vblank.h in intel_display_types.h and only include it where needed. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0cdb855398ff21e520ef8839b9d00ded40b85fd0.1724689818.git.jani.nikula@intel.com
2024-06-24drm/i915: Use the same vblank worker for atomic unpinMaarten Lankhorst
In case of legacy cursor update, the cursor VMA needs to be unpinned only after vblank. This exceeds the lifetime of the whole atomic commit. Any trick I attempted to keep the atomic commit alive didn't work, as drm_atomic_helper_setup_commit() force throttles on any old commit that wasn't cleaned up. The only option remaining is to remove the plane from the atomic commit, and use the same path as the legacy cursor update to clean the state after vblank. Changes since previous version: - Call the memset for plane state immediately when scheduling vblank, this prevents a use-after-free in cursor cleanup. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240522053341.137592-4-maarten.lankhorst@linux.intel.com
2024-06-24drm/i915: Use vblank worker to unpin old legacy cursor fb safelyVille Syrjälä
The cursor hardware only does sync updates, and thus the hardware will be scanning out from the old fb until the next start of vblank. So in order to make the legacy cursor fastpath actually safe we should not unpin the old fb until we're sure the hardware has ceased accessing it. The simplest approach is to just use a vblank work here to do the delayed unpin. Not 100% sure it's a good idea to put this onto the same high priority vblank worker as eg. our timing critical gamma updates. But let's keep it simple for now, and it we later discover that this is causing problems we can think about adding a lower priority worker for such things. This patch is slightly reworked by Maarten Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240522053341.137592-3-maarten.lankhorst@linux.intel.com
2024-06-24drm/i915: Split cursor alignment to per-platform vfuncsVille Syrjälä
Split intel_cursor_alignment() into per-platform variants. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240612204712.31404-6-ville.syrjala@linux.intel.com
2024-06-24drm/i915: Introduce the plane->min_alignment() vfuncVille Syrjälä
Different hardware generations have different scanout alignment requirements. Introduce a new vfunc that will allow us to make that distinction without horrible if-ladders. For now we directly plug in the existing intel_surf_alignment() and intel_cursor_alignment() functions. For fbdev we (temporarily) introduce intel_fbdev_min_alignment() that simply queries the alignment from the primary plane of the first crtc. TODO: someone will need to fix xe's alignment handling Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240612204712.31404-4-ville.syrjala@linux.intel.com Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-06-19drm/i915/display: Wa 16021440873 is writing wrong registerJouni Högander
Wa 16021440873 is writing wrong register. Instead of PIPE_SRCSZ_ERLY_TPT write CURPOS_ERLY_TPT. v2: use right offset as well Fixes: 29cdef8539c3 ("drm/i915/display: Implement Wa_16021440873") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240618053026.3268759-3-jouni.hogander@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-22drm/i915: Add separate defines for cursor WM/DDB register bitsVille Syrjälä
Make a more thorough split between universal planes vs. cursors by defining the contents of the cursor WM/DDB registers separately. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240516135622.3498-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-22drm/i915: Simplify PIPESRC_ERLY_TPT definitionVille Syrjälä
PIPESRC_ERLY_TPT is a pipe register, and it lives in the 0x70000 range. so using _MMIO_TRANS2() for it is not really correct. Also since this is a pipe register, and not present on CHV, the registers will be equally spaced out, so we can use the simpler _MMIO_PIPE() instead of _MMIO_PIPE2(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240516135622.3498-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-22drm/i915: Add separate define for SEL_FETCH_CUR_CTL()Ville Syrjälä
Split the cursor stuff from the rest of the selective fetch plane registers so that we can collect all cursor registers in intel_cursor_regs.h. Also take the opportunity to rename the registers to match the spec. v2: Pass the correct register offset fpr pipe B (Jani) s/mtl+/tgl+/ as that's where this was introduced Drop the bogus SEL_FETCH_CUR_CTL_ENABLE bit, the contents actually match the normal CUR_CTL register 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/20240520171459.9661-1-ville.syrjala@linux.intel.com
2024-05-16drm/i915: pass dev_priv explicitly to CUR_FBC_CTLJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CUR_FBC_CTL register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f5e76f916ccf02aaf6016ffd476e9544817ac179.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-16drm/i915: pass dev_priv explicitly to CURSIZEJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CURSIZE register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/521ca44416eb95dcfcf4bfbc32ac7f9371aeaf5d.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-16drm/i915: pass dev_priv explicitly to CURPOS_ERLY_TPTJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CURPOS_ERLY_TPT register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2263b6412e983026990f7f6730b0b1141be4fd0f.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-16drm/i915: pass dev_priv explicitly to CURPOSJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CURPOS register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ca229a123cb8a5d6a2970649a47236b3da1b02ad.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-16drm/i915: pass dev_priv explicitly to CURBASEJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CURBASE register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e552df69a4e6a3dbd562ba8c442d0219cda3bfd0.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-16drm/i915: pass dev_priv explicitly to CURCNTRJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the CURCNTR register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/06bc681558c86f351ae596e9600133bb10ae4bdd.1715774156.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-15drm/i915: Handle SKL+ WM/DDB registers next to all other plane registersVille Syrjälä
Having the plane WM/DDB regitster write functions in skl_watermarks.c is rather annoying when trying to implement DSB based plane updates. Move them into the respective files that handle all other plane register writes. Less places where I need to worry about the DSB vs. MMIO decisions. The downside is that we spread the wm struct details a bit further afield. But if that becomes too annoying we can probably abstract things a bit more with a few extra functions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-17-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-15drm/i915: Extract intel_cursor_regs.hVille Syrjälä
Move most cursor register definitions into their own file. Declutters i915_reg.h a bit more. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> CC: Zhi Wang <zhi.wang.linux@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-06drm/i915: pass dev_priv explicitly to PIPE_SRCSZ_ERLY_TPTJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_SRCSZ_ERLY_TPT register macro. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b37217f55702fc10190c2c5aded7d845a36766f6.1714471597.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-22Merge tag 'drm-misc-next-2024-04-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.10-rc1: UAPI Changes: - Add SIZE_HINTS property for cursor planes. Cross-subsystem Changes: Core Changes: - Document the requirements and expectations of adding new driver-specific properties. - Assorted small fixes to ttm. - More Kconfig fixes. - Add struct drm_edid_product_id and helpers. - Use drm device based logging in more drm functions. - Fixes for drm-panic, and option to test it. - Assorted small fixes and updates to edid. - Add drm_crtc_vblank_crtc and use it in vkms, nouveau. Driver Changes: - Assorted small fixes and improvements to bridge/imx8mp-hdmi-tx, nouveau, ast, qaic, lima, vc4, bridge/anx7625, mipi-dsi. - Add drm panic to simpledrm, mgag200, imx, ast. - Use dev_err_probe in bridge/panel drivers. - Add Innolux G121X1-L03, LG sw43408 panels. - Use struct drm_edid in i915 bios parsing. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2dc1b7c6-1743-4ddd-ad42-36f700234fbe@linux.intel.com
2024-04-11drm/i915: Add SIZE_HINTS property for cursorsVille Syrjälä
Advertize more suitable cursor sizes via the new SIZE_HINTS plane property. We can't really enumerate all supported cursor sizes on the platforms where the cursor height can vary freely, so for simplicity we'll just expose all square+POT sizes between each platform's min and max cursor limits. Depending on the platform this will give us one of three results: - 64x64,128x128,256x256,512x512 - 64x64,128x128,256x256 - 64x64 Cc: Simon Ser <contact@emersion.fr> Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240318204408.9687-3-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-03-28drm/i915: Pre-populate the cursor physical dma addressVille Syrjälä
Calling i915_gem_object_get_dma_address() from the vblank evade critical section triggers might_sleep(). While we know that we've already pinned the framebuffer and thus i915_gem_object_get_dma_address() will in fact not sleep in this case, it seems reasonable to keep the unconditional might_sleep() for maximum coverage. So let's instead pre-populate the dma address during fb pinning, which all happens before we enter the vblank evade critical section. We can use u32 for the dma address as this class of hardware doesn't support >32bit addresses. Cc: stable@vger.kernel.org Fixes: 0225a90981c8 ("drm/i915: Make cursor plane registers unlocked") Reported-by: Borislav Petkov <bp@alien8.de> Closes: https://lore.kernel.org/intel-gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_crate.local/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240325175738.3440-1-ville.syrjala@linux.intel.com Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> (cherry picked from commit c1289a5c3594cf04caa94ebf0edeb50c62009f1f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-03-28drm/i915/display: Implement Wa_16021440873Jouni Högander
This patch is implementing Wa_16021440873. Bspec: 74151 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240319123327.1661097-6-jouni.hogander@intel.com
2024-03-26drm/i915: Pre-populate the cursor physical dma addressVille Syrjälä
Calling i915_gem_object_get_dma_address() from the vblank evade critical section triggers might_sleep(). While we know that we've already pinned the framebuffer and thus i915_gem_object_get_dma_address() will in fact not sleep in this case, it seems reasonable to keep the unconditional might_sleep() for maximum coverage. So let's instead pre-populate the dma address during fb pinning, which all happens before we enter the vblank evade critical section. We can use u32 for the dma address as this class of hardware doesn't support >32bit addresses. Cc: stable@vger.kernel.org Fixes: 0225a90981c8 ("drm/i915: Make cursor plane registers unlocked") Reported-by: Borislav Petkov <bp@alien8.de> Closes: https://lore.kernel.org/intel-gfx/20240227100342.GAZd2zfmYcPS_SndtO@fat_crate.local/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240325175738.3440-1-ville.syrjala@linux.intel.com Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
2024-01-22drm/i915: Perform vblank evasion around legacy cursor updatesVille Syrjälä
Our legacy cursor updates are actually mailbox updates. Ie. the hardware latches things once per frame on start of vblank, but we issue an number of updates per frame, withough any attempt to synchronize against the vblank in software. So in theory only the last update issued during the frame will latch, and the previous ones are discarded. However this can lead to problems with maintaining the ggtt/iommu mappings as we have no idea which updates will actually latch. The problem is exacerbated by the hardware's annoying disarming behaviour; any non-arming register write will disarm an already armed update, only to be rearmed later by the arming register (CURBASE in case of cursors). If a disarming write happens just before the start of vblank, and the arming write happens after start of vblank we have effectively prevented the hardware from latching anything. And if we manage to straddle multiple sequential vblank starts in this manner we effectively prevent the hardware from latching any new registers for an arbitrary amount of time. This provides more time for the (potentially still in use by the hardware) gtt/iommu mappings to be torn down. A partial solution, of course, is to use vblank evasion to avoid the register writes from spreading on both sides of the start of vblank. I've previously highlighted this problem as a general issue affecting mailbox updates. I even added some notes to the {i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm and arm phases both need to pulled into the vblank evasion critical section if we actually decided to implement mailbox updates in general. But as I never impelemented the noarm+arm split for cursors we don't have to worry about that for the moment. We've been lucky enough so far that this hasn't really caused problems. One thing that does help is that Xorg generally sticks to the same cursor BO. But igt seems pretty good at hitting this on MTL now, so apparently we have to start thinking about this. v2: Wait for PSR exit to avoid the vblank evasion timeout (1ms) tripping due to PSR exit latency (~5ms typically) 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/20240116204927.23499-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-01-09drm/i915/psr: Calculate and configure CUR_POS_ERLY_TPTJouni Högander
New register CUR_POS_ERLY_TPT related to early transport is supposed to be configured when early transport is in use. This register is used to configure cursor vertical postion from beginning of selective update area. Bspec: 68927 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-5-jouni.hogander@intel.com
2023-12-07drm/i915/display: Use i915_gem_object_get_dma_address to get dma addressMaarten Lankhorst
Works better for xe like that. obj is no longer const. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204134946.16219-1-maarten.lankhorst@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-11-27drm/i915/psr: Add proper handling for disabling sel fetch for planesJouni Högander
Currently we are enabling selective fetch for all planes that are visible. This is suboptimal as we might be fetching for memory for planes that are not part of selective update. Fix this by adding proper handling for disabling plane selective fetch: If plane previously part of selective update is now not part of update: Add it into updated planes and let the plane configuration to disable selective fetch for it. v3: Checkpatch warnings fixed v2: - Add setting sel_fetch_area->y1/y2 to -1 - Remove setting again local sel_fetch_area variable Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231120082606.3156488-3-jouni.hogander@intel.com
2023-11-27drm/i915/psr: Move plane sel fetch configuration into plane source filesJouni Högander
Currently selective fetch configuration for planes is implemented in psr code. More suitable place for this code is where everything else is configured for planes -> move it into skl_universal_plane.c and intel_cursor.c. This also allows us to drop hooks for cursor handling. v3: Checkpatch warnings fixed v2: Removed setting sel_fetch_area->y1/y2 as -1 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231120082606.3156488-2-jouni.hogander@intel.com
2023-05-24drm/i915/display: Move display runtime info to display structureMatt Roper
Move the runtime info specific to display into display-specific structures as has already been done with the constant display info. v2: - Rename __runtime to __runtime_defaults for more clarity on the purpose. (Andrzej) - Move introduction of DISPLAY_INFO() to previous patch. (Andrzej) - Drop NO_DISPLAY macro. (Andrzej) v3: - Use "{}" instead of "{ 0 }" for empty struct init. (Jani) Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com
2023-05-24drm/i915: Convert INTEL_INFO()->display to a pointerMatt Roper
Rather than embeddeding the display's device info within the main device info structure, just provide a pointer to the display-specific structure. This is in preparation for moving the display device info definitions into the display code itself and for eventually allowing the pointer to be assigned at runtime on platforms that use GMD_ID for device identification. In the future, this will also eventually allow the same display device info structures to be used outside the current i915 code (e.g., from the Xe driver). v2: - Move introduction of DISPLAY_INFO() to this patch. (Andrzej) v3: - Also use DISPLAY_INFO() in intel_display_reg_defs.h. (Andrzej) - Use "{}" instead of "{ 0 }" for empty struct init. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-3-matthew.d.roper@intel.com
2023-03-17drm/i915: Relocate intel_plane_check_src_coordinates()Ville Syrjälä
Move intel_plane_check_src_coordinates() from the pre-skl sprite plane specific code to a more suitable place for common plane code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-9-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-01-30drm/i915/psr: Split sel fetch plane configuration into arm and noarmJouni Högander
SEL_FETCH_CTL registers are armed immediately when plane is disabled. SEL_FETCH_* instances of plane configuration are used when doing selective update and normal plane register instances for full updates. Currently all SEL_FETCH_* registers are written as a part of noarm plane configuration. If noarm and arm plane configuration are not happening within same vblank we may end up having plane as a part of selective update before it's PLANE_SURF register is written. Fix this by splitting plane selective fetch configuration into arm and noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm version. v3: - add arm suffix into intel_psr2_disable_plane_sel_fetch v2: - drop color_plane parameter from arm part - dev_priv -> i915 in arm part Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130080651.3796929-1-jouni.hogander@intel.com
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
2022-10-22drm/i915: Introduce intel_crtc_needs_fastset()Ville Syrjälä
Replace the somewhat obscure crtc_state.update_pipe checks with a more descriptive thing. Also nicely matches the intel_crtc_needs_modeset() counterpart for full modesets. v2: Handle one more case in the fbc code Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221021162442.27283-2-ville.syrjala@linux.intel.com
2022-09-12Merge drm/drm-next into drm-intel-nextJani Nikula
Backmerge to sync the DP MST atomic changes to drm-intel-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-09drm/i915: Extract skl_watermark.cVille Syrjälä
Pull all the skl+ watermark code (and the dbuf/sagv/ipc code since it's all sort of intertwined and I'm too lazy to think of a finer grained split right now) into its own file from the catch-all intel_pm.c. Also sneak in the s/dev_priv/i915/ rename while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908191646.20239-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-07-26drm/atomic-helper: Remove _HELPER_ infix from DRM_PLANE_HELPER_NO_SCALINGThomas Zimmermann
Rename DRM_PLANE_HELPER_NO_SCALING to DRM_PLANE_NO_SCALING. The constant is not really a helper, but rather a characteristic of the plane itself. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-4-tzimmermann@suse.de
2022-07-26drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpersThomas Zimmermann
The macro DRM_PLANE_HELPER_NO_SCALING is only useful with the interfaces in drm_atomic_helper.h, but defined in drm_plane_helper.h. So half of DRM includes the latter header file for using this macro. Move the macro and remove the include statements. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-3-tzimmermann@suse.de
2022-06-20drm: Drop drm_blend.h from drm_crtc.hVille Syrjälä
drm_crtc.h has no need for drm_blend.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_blend.h. Quite a few placs do currently depend on drm_blend.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-4-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-03-10drm/i915: Make the PIPESRC rect relative to the entire bigjoiner areaVille Syrjälä
When using bigjoiner it's useful to know the offset of each individual pipe in the whole set of joined pipes. Let's include that information in our PIPESRC rectangle. With this we can make the plane clipping code blissfully unaware of bigjoiner usage, as all we have to do is remove the pipe's offset from the final plane destination coordinates. v2: Use intel_bigjoiner_num_pipes() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-14-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-03-04drm/i915: Eliminate bigjoiner booleanVille Syrjälä
Since we now have the bigjoiner_pipes bitmask the boolean is redundant. Get rid of it. Also, populating bigjoiner_pipes already during encoder->compute_config() allows us to use it much earlier during the state calculation as well. The initial aim is to use it in intel_crtc_compute_config(). v2: Move the hweight(bigjoiner_pipes) stuff to a later patch Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1 Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-12-ville.syrjala@linux.intel.com
2022-03-04drm/i915: Start tracking PIPESRC as a drm_rectVille Syrjälä
Instead of just having the pipe_src_{w,h} let's use a full drm_rect for it. This will be particularly useful to astract away some bigjoiner details. v2: No hweight() stuff yet Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-11-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2022-02-25drm/i915: Fix cursor coordinates on bigjoiner slaveVille Syrjälä
Adjust the cursor dst coordinates appripriately when it's on the bigjoiner slave pipe. intel_atomic_plane_check_clipping() already did this but with the cursor we discard those results (apart from uapi.visible and error checks) since the hardware will be doing the clipping for us. v2: Rebase due to bigjoiner bitmask usage Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-3-ville.syrjala@linux.intel.com
2022-02-24drm/i915: Make cursor plane registers unlockedVille Syrjälä
Drop the locks around cursor plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The locking did have a secondary effect of disabling interrupts around the cursor registers writes though. If we drop that then we open outselves up for sceduling delays and whatnot while on the middle of the register writes. That increases the chance of not all the register writes land during the same frame. For normal atomic commits this is not a concern as the vblank evade mechanism anyway disables interrupts around the update, but the legacy cursor codepath does not. Technically we should do a vblank evade there as well, but so far no one has bothered to hook that up. So in the meantime let's put an explicit local irq disable/enable around the legacy cursor update to keep the race window minimal. v2: local_irq_{disable,enable}() for legacy cursor ioctl Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211092604.393-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-01-18drm/i915: Clean up cursor registersVille Syrjälä
Use REG_BIT() & co. to polish the cursor plane registers. v2: deal with gvt Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-12-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-11-04drm/i915: Split update_plane() into update_noarm() + update_arm()Ville Syrjälä
The amount of plane registers we have to write has been steadily increasing, putting more pressure on the vblank evasion mechanism and forcing us to increase its time budget. Let's try to take some of the pressure off by splitting plane updates into two parts: 1) write all non-self arming plane registers, ie. the registers where the write actually does nothing until a separate arming register is also written which will cause the hardware to latch the new register values at the next start of vblank 2) write all self arming plane registers, ie. registers which always just latch at the next start of vblank, and registers which also arm other registers to do so Here we just provide the mechanism, but don't actually implement the split on any platform yet. so everything stays now in the _arm() hooks. Subsequently we can move a whole bunch of stuff into the _noarm() part, especially in more modern platforms where the number of registers we have to write is also the greatest. On older platforms this is less beneficial probably, but no real reason to deviate from a common behaviour. And let's sprinkle some TODOs around the areas that will need adapting. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-11-02drm/i915/fb: Rename i915_color_plane_view::stride to mapping_strideImre Deak
The next patch needs to distinguish between a view's mapping and scanout stride. Rename the current stride parameter to mapping_stride with the script below. mapping_stride will keep the same meaning as stride had on all platforms so far, while the meaning of it will change on ADLP. No functional changes. @@ identifier intel_fb_view; identifier i915_color_plane_view; identifier color_plane; expression e; type T; @@ struct intel_fb_view { ... struct i915_color_plane_view { ... - T stride; + T mapping_stride; ... } color_plane[e]; ... }; @@ struct i915_color_plane_view pv; @@ pv. - stride + mapping_stride @@ struct i915_color_plane_view *pvp; @@ pvp-> - stride + mapping_stride Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-6-imre.deak@intel.com
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-21 12:22:01 +0000