summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/i9xx_plane.c
AgeCommit message (Collapse)Author
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-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-06-24drm/i915: Split pre-skl platforms out from intel_surf_alignment()Ville Syrjälä
Extract the necessary chunks from intel_surf_alignment() into per-platform variants for all pre-skl primary/sprite planes. 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-7-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-07drm/i915: pass dev_priv explicitly to PIPESRCJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPESRC register macro. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ac1959b7038d6fedb4777dcf2b961de901fb8880.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to PRIMCNSTALPHAJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PRIMCNSTALPHA register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/783477b86f4d53849775cbf690bb8b9042792a66.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to PRIMSIZEJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PRIMSIZE register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b672f17b4c3d5ba7ac606798bb3799408c26f075.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to PRIMPOSJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PRIMPOS register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4bbb3218ac25b292bea46dcba3df8ec474d578e2.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPOFFSETJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPOFFSET register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c1d487d2c753221144e8fb8f17e5eb2826dba5f2.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPTILEOFFJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPTILEOFF register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4736b2d65ca3be3e9eb5a835ddac801ba99e1e6b.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPSURFJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPSURF register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fc2d7753aa6e8e25303a111bf4b120da6ce8c458.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPSIZEJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPSIZE register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d24ee614cac29ccc3917f9cba1ce03ce54fb7d8b.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPPOSJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPPOS register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fbe6b94f03926175611b51c5054466dd27656d2a.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPSTRIDEJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPSTRIDE register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4067b3009076492d05e80ae994f9a7bd29b56b2e.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPLINOFFJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPLINOFF register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/922b6b0795787b335bd3d5b0541bd30dc2c19dd5.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPADDRJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPADDR register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/777d4189c18c16392015dd2770f5c56d94bb88a9.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPCNTRJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPCNTR register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d9434a718658d7dc6dba1e8a54f80cd1503d0b33.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-24drm/i915: pass dev_priv explicitly to DSPADDR_VLVJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the DSPADDR_VLV register macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1d9be6b1eedd9240468a89cd3a10e8513caa33b1.1716469091.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-22drm/i915: Extract i9xx_plane_regs.hVille Syrjälä
Relocate all pre-skl primary plane register definitions into their own declutter i915_reg.h. 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/20240516135622.3498-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-10drm/i915: Polish types in fb calculationsVille Syrjälä
Be a bit more consistent in our use of integer types in the fb related calculatiosn. u32 we generally only use for ggtt offsets and such, and everything else can be regular (unsigned) ints. There's also an overabundance of consts for local variables in skl_check_main_surface() which is not something we generally do. So get rid of those while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-10drm/i915: Split gen2 vs. gen3 .max_stride()Ville Syrjälä
Plane .max_stride() is already a vfunc so having one made up of two branches based on the display version is silly. Split i9xx_plane_max_stride() into gen2 vs. gen3 variants so that we get rid of said check. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-05-03drm/i915: s/need_async_flip_disable_wa/need_async_flip_toggle_wa/Ville Syrjälä
Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to better reflect the fact that we need to deal with the bad PLANE_CTL_ASYNC_FLIP double buffering behaviour going both ways. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-6-ville.syrjala@linux.intel.com
2024-05-03drm/i915: Eliminate extra frame from skl-glk sync->async flip changeVille Syrjälä
On bdw-glk the sync->async flip change takes an extra frame due to the double buffering behaviour of the async flip plane control bit. Since on skl+ we are now explicitly converting the first async flip to a sync flip (in order to allow changing the modifier and/or ddb/watermarks) we are now taking two extra frames until async flips are actually active. We can drop that back down to one frame by setting the async flip bit already during the sync flip. Note that on bdw we don't currently do the extra sync flip (see intel_plane_do_async_flip()) so technically we wouldn't have to deal with this in i9xx_plane_update_arm(). But I added the relevant snippet of code there as well, just in case we ever decide to go for the extra sync flip on pre-skl platforms as well (we might, for example, want to change the fb stride). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-5-ville.syrjala@linux.intel.com Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
2024-02-07drm/i915: Try to relocate the BIOS fb to the start of ggttVille Syrjälä
On MTL the GOP (for whatever reason) likes to bind its framebuffer high up in the ggtt address space. This can conflict with whatever ggtt_reserve_guc_top() is trying to do, and the result is that ggtt_reserve_guc_top() fails and then we proceed to explode when trying to tear down the driver. Thus far I haven't analyzed what causes the actual fireworks, but it's not super important as even if it didn't explode we'd still fail the driver load and the user would be left with an unusable GPU. To remedy this (without having to figure out exactly what ggtt_reserve_guc_top() is trying to achieve) we can attempt to relocate the BIOS framebuffer to a lower ggtt address. We can do this at this early point in driver init because nothing else is supposed to be clobbering the ggtt yet. So we simply change where in the ggtt we pin the vma, the original PTEs will be left as is, and the new PTEs will get written with the same dma addresses. The plane will keep on scanning out from the original PTEs until we are done with the whole process, and at that point we rewrite the plane's surface address register to point at the new ggtt address. Since we don't need a specific ggtt address for the plane (apart from needing it to land in the mappable region for normal stolen objects) we'll just try to pin it without a fixed offset first. It should end up at the lowest available address (which really should be 0 at this point in the driver init). If that fails we'll fall back to just pinning it exactly to the origianal address. To make sure we don't accidentlally pin it partially over the original ggtt range (as that would corrupt the original PTEs) we reserve the original range temporarily during this process. v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it even higher (atm we have no PIN_LOW flag to force it low) v3: "fix" xe Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-16-ville.syrjala@linux.intel.com Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
2023-08-31drm/i915: add minimal i915_gem_object_frontbuffer.hJani Nikula
Split out frontbuffer related declarations and static inlines from gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. The main goal is to reduce header interdependencies. With gem/i915_gem_object.h including display/intel_frontbuffer.h, modification of the latter causes a whopping 300+ objects to be rebuilt, while many of the source files actually needing it aren't explicitly including it at all. After the change, only 21 objects depend on display/intel_frontbuffer.h, directly or indirectly. Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230830085127.2416842-1-jani.nikula@intel.com
2023-06-07drm/i915/plane: warn on non-zero plane offsetJani Nikula
We assume the plane offset is 0. Warn if it's not. This also fixes a warn on unused but set variable offset. v2: initialize offset on the gen2/3 path (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526172218.1597394-1-jani.nikula@intel.com
2023-05-16drm/i915/irq: split out display irq handlingJani Nikula
Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-3-jani.nikula@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-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-08-31drm/i915: move fbc to display.fbcJani Nikula
Move display FBC related members under drm_i915_private display sub-struct. Pointers and arrays of pointers to structs that we defined are fine without a sub-struct wrapping. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1151469ec13d392df86b72a375f490fd70a3257a.1661779055.git.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-04-13drm/i915: Remove remaining locks from i9xx plane udpatesVille Syrjälä
Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-02-24drm/i915: Make most pre-skl primary plane registers unlockedVille Syrjälä
Drop the locks around most primary plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The one exception we have to make is DSPADDR/DSPSURF which is (ab)used to also trigger FBC nukes on pre-snb (since the hardware doesn't seem to have any dedicated mechanism to trigger nukes). So we need to keep the lock around it to protect against the rmw performed by the fbc code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-01-26drm/i915: Clean up PIPESRC definesVille Syrjälä
Use REG_GENMASK() & co. when dealing with PIPESRC. Note that i9xx_get_initial_plane_config() will now use the full 16 bit mask whereas previously it used 12 bits only. But intel_get_pipe_src_size() already used the full 16 bits on all platforms anyway, so at least we're consistent now. The high bits beyond the max supported pipe source size should not be set in any case so this seems fine. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-24drm/i915: Clean up pre-skl primary plane registersVille Syrjälä
Use REG_BIT() & co. for the pre-skl primary plane registers. Also give everything a consistent namespace. v2: s/DSP/DISP/ to avoid confusion (José) Use DISP_WIDTH rather than DISP_POS_X for DSPSIZE (José) Deal with gvt Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121113036.23240-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-12-15drm/i915/fbc: Loop through FBC instances in various placesVille Syrjälä
Convert i915->fbc into an array in preparation for multiple FBC instances, and loop through all instances in all places where the caller does not know which instance(s) (if any) are relevant. This is the case for eg. frontbuffer tracking and FIFO underrun hadling. v2: More intel_ namespace (Jani) Leave out debugfs for later 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/20211213134450.3082-3-ville.syrjala@linux.intel.com
2021-12-03drm/i915/fbc: Allocate intel_fbc dynamicallyVille Syrjälä
In the future we may have more than one FBC instance on some platforms. So let's just allocate it dynamically. This also lets us fully hide the implementation from prying eyes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-14-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Introduce intel_fbc_add_plane()Ville Syrjälä
In order to better encapsulate the FBC implementation introduce a small helper to do the plane<->FBC instance association. We'll also try to structure the plane init code such that introducing multiple FBC instances will be easier down the line. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-11-11drm/1915/fbc: Replace plane->has_fbc with a pointer to the fbc instanceVille Syrjälä
With multiple fbc instances we need to find the right one for each plane. Rather than going looking for the right instance every time let's just replace the has_fbc boolean with a pointer that gets us there straight away. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-18-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-11-04drm/i915: Split pre-skl primary plane update into noarm+arm pairVille Syrjälä
Chop i9xx_plane_update() into two halves. Fist half becomes the _noarm() variant, second part the _arm() variant. Fortunately I have already previously grouped the register writes into roughtly the correct order, so the split looks surprisingly clean. One slightly surprising fact was that the CHV pipe B PRIMPOS/SIZE registers are self arming unlike their pre-ctg DSPPOS/SIZE counterparts. In fact all the new CHV pipe B registers are self arming. Also we must remind ourselves that i830/i845 are a bit borked in that all of their plane registers are self-arming. I didn't do any i915_update_info measurements for this one alone. I'll get total numbers with the corrsponding sprite plane changes. v2: Don't break my precious i830/i845 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/20211020212757.13517-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@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
2021-10-29drm/i915/fb: Fold modifier CCS type/tiling attribute to plane capsImre Deak
By using the modifier plane capability flags to encode the modifiers' CCS type and tiling attributes, it becomes simpler to the check for any of these capabilities when providing the list of supported modifiers. This also allows distinguishing modifiers on future platforms where platforms with the same display version support different modifiers. An example is DG2 and ADLP, both being D13, where DG2 supports only F and X tiling, while ADLP supports only Y and X tiling. With the INTEL_PLANE_CAP_TILING_* flags added in this patch we can provide the correct modifiers for each platform. v2: - Define PLANE_HAS_* with macros instead of an enum. (Jani) - Rename PLANE_HAS_*_ANY to PLANE_HAS_*_MASK. (Jani) - Rename PLANE_HAS_* to INTEL_PLANE_CAP_*. - Set the CCS_RC_CC cap only for DISPLAY_VER >= 12. - Set the TILING_Y cap only for DISPLAY_VER < 13 || ADLP. - Simplify the SKL plane cap display version checks and move them to a separate function. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> 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/20211027125150.2891371-1-imre.deak@intel.com
2021-10-21drm/i915: Add a table with a descriptor for all i915 modifiersImre Deak
Add a table describing all the framebuffer modifiers used by i915 at one place. This has the benefit of deduplicating the listing of supported modifiers for each platform and checking the support of these modifiers on a given plane. This also simplifies in a similar way getting some attribute for a modifier, for instance checking if the modifier is a CCS modifier type. While at it drop the cursor plane filtering from skl_plane_has_rc_ccs(), as the cursor plane is registered with DRM core elsewhere. v1: Unchanged. v2: - Keep the plane caps calculation in the plane code and pass an enum with these caps to intel_fb_get_modifiers(). (Ville) - Get the modifiers calling intel_fb_get_modifiers() in i9xx_plane.c as well. v3: - s/.id/.modifier/ (Ville) - Keep modifier_desc vs. plane_cap filter conditions consistent. (Ville) - Drop redundant cursor plane check from skl_plane_has_rc_ccs(). (Ville) - Use from, until display version fields in modifier_desc instead of a mask. (Jani) - Unexport struct intel_modifier_desc, separate its decl and init. (Jani) - Remove enum pipe, plane_id forward decls from intel_fb.h, which are not needed after v2. v4: - Reuse IS_DISPLAY_VER() instead of open-coding it. (Jani) - Preserve the current modifier order exposed to user space. (Ville) v5: Use }, { on one line to seperate the descriptor array elements. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (v3) Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-2-imre.deak@intel.com
2021-07-08drm/i915/plane: add intel_plane_helper_add() helperJani Nikula
Add a small helper to keep intel_plane_helper_funcs static. 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/20210518132426.7567-1-jani.nikula@intel.com
2021-05-05drm/i915: Don't include intel_de.h from intel_display_types.hVille Syrjälä
Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> 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/20210430143945.6776-1-ville.syrjala@linux.intel.com
2021-04-28drm/i915: Remove stray newlinesVille Syrjälä
A bunch of files have a stray newline at the end. Remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-04-14drm/i915/display: rename display version macrosLucas De Marchi
While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 00:01:32 +0000