aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_fbc.h
AgeCommit message (Collapse)AuthorFilesLines
2024-07-12drm/i915/fbc: Convert to intel_display, mostlyVille Syrjälä1-6/+7
Switch the FBC code over to intel_display from i915, as much as possible. This is the future direction so that the display code can be shared between i915 and xe more cleanly. Some of the platform checks and the stolen mem facing stiff still need i915 around though. v2: Drop some redundant to_i915() casts Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2023-09-21drm/i915/xe2lpd: FBC is now supported on all pipesMatt Roper1-0/+2
FBC is no longer limited by pipe: add the defines for pipes B and C that will be used by platforms supporting FBC on such pipes. Bspec: 68881, 68904 Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Vinod Govindapillai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-19drm/i915/mtl: Introduce FBC BVille Syrjälä1-0/+1
MTL introduces a second FBC engine. The two FBC engines can operate entirely independently, FBC A serving pipe A and FBC B serving pipe B. The one place where things might go a bit wrong is the CFB allocation from stolen. We might have to consider some change to the allocation strategy to have a better chance of both engines being able to allocate its CFB. Maybe FBC A should allocate bottom up and FBC B top down, or something? For the moment the allocation strategy is DRM_MM_INSERT_BEST for both. Cc: Mika Kahola <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-13drm/i915/fbc: Introduce intel_fbc_sanitize()Ville Syrjälä1-0/+1
Let's make sure FBC is always disabled when we start to take over the hardware state. I suspect this should never really happen, since the only time when we really should be taking over with the display already active is when the previous state was progammed by the BIOS, which likely shouldn't use FBC. This could be driver init, or S4 resume when the boot kernel doesn't load i915. But I suppose no harm in keeping this code around for exra safety since it's quite trivial. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2022-04-13drm/i915/fbc: Remove intel_fbc_global_disable()Ville Syrjälä1-1/+0
By the time intel_fbc_global_disable() gets called during driver teardown we should have already disabled all the crtcs, so no way FBC should be enabled at this point. And I have no idea what the other user (i915_restore_display()) is even trying to achieve. So let's just throw intel_fbc_global_disable() into the bin. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2021-12-15drm/i915/fbc: Register per-crtc debugfs filesVille Syrjälä1-0/+1
Expose FBC debugfs files for each crtc. These may or may not point to the same FBC instance depending on the platform. We leave the old global debugfs files in place until igt catches up to the new per-crtc approach. v2: Take a trip via intel_crtc_debugfs_add() (Jani) Cc: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2021-12-15drm/i915/fbc: Parametrize FBC register offsetsVille Syrjälä1-0/+6
Parametrize ilk+ FBC register offsets based on the FBC instance. v2: More intel_ namespace (Jani) v3: Don't break gvt (Jani) Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-13drm/i915/fbc: avoid intel_frontbuffer.h include with declarationJani Nikula1-2/+1
Reduce include dependencies using forward declarations. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/fb54050e03f830a1b29eb14cb37466f39c499cc2.1639142167.git.jani.nikula@intel.com
2021-12-03drm/i915/fbc: Introduce intel_fbc_add_plane()Ville Syrjälä1-0/+2
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2021-12-03drm/i915/fbc: Move FBC debugfs stuff into intel_fbc.cVille Syrjälä1-3/+1
In order to encapsulate FBC harder let's just move the debugfs stuff into intel_fbc.c. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2021-12-03drm/i915/fbc: Pass i915 instead of FBC instance to FBC underrun stuffVille Syrjälä1-2/+2
The underrun code doesn't need to know any details about FBC, so just pass in the whole device rather than a specific FBC instance. We could make this a bit more fine grained by also passing in the pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC code figure which FBC instance (if any) is active on said pipe. But that seems a bit overkill for this so don't bother. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2021-12-03drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cacheVille Syrjälä1-2/+1
There's no need to store all this stuff in intel_fbc_state_cache. Just check it all against the plane/crtc states and store only what we need. Probably more should get nuked still, but this is a start. So what we'll do is: - each plane will check its own state and update its local no_fbc_reason - the per-plane no_fbc_reason (if any) then gets propagated to the cache->no_fbc_reason while doing the actual update - fbc->no_fbc_reason gets updated in the end with either the value from the cache or directly from frontbuffer tracking It's still a bit messy, but should hopefuly get cleaned up more in the future. At least now we can observe each plane's reasons for rejecting FBC now more consistently, and we don't have so mcuh redundant state store all over the place. v2: store no_fbc_reason per-plane instead of per-pipe Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2021-11-11drm/i915/fbc: Start passing around intel_fbcVille Syrjälä1-7/+7
In preparation for multiple FBC instances start passing around intel_fbc pointers rather than i915 pointers. And once there are multiple of these we can't rely on container_of() to get back to the i915, so we toss in a fbc->i915 pointer already. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> Reviewed-by: Mika Kahola <[email protected]>
2021-11-11drm/i915/fbc: Introduce intel_fbc_set_false_color()Ville Syrjälä1-0/+2
Pull the direct FBC register frobbing out from the debugfs code into the fbc code. Also add a vfunc for this so we don't need extra platforms checks. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> Reviewed-by: Mika Kahola <[email protected]>
2021-11-11drm/i915/fbc: Introduce intel_fbc_is_compressing()Ville Syrjälä1-0/+1
Move the direct FBC status register reads from the debugfs code behind an abstract api. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> Reviewed-by: Mika Kahola <[email protected]>
2021-08-20drm/i915/fbc: Extract intel_fbc_update()Ville Syrjälä1-1/+1
Pull the fbc enable vs. disable stuff into a small helper so we don't have to have it pollute the higher level modeset code. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-15drm/i915/fbc: Move the plane state check into the fbc functionsVille Syrjälä1-7/+6
Instead of dealing with the presence/absence of the primary plane in the higher level pre/post plane update code let's move all that into the fbc code itself. Now the higher level code doesn't have to think about FBC details anymore. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2019-12-09drm/i915/fbc: Wait for vblank after FBC disable on glk+Ville Syrjälä1-1/+1
On glk+ the hardware gets confused if we disable FBC while it's recompressing and we perform a plane update during the same frame. The result is that top of the screen gets corrupted. We can avoid that by giving the hardware enough time to finish the FBC disable before we touch the plane registers. Ie. we need an extra vblank wait after FBC disable. v2: Don't do the vblank wait if we never activated FBC in hw Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2019-12-09drm/i915/fbc: Nuke bogus single pipe fbc1 restrictionVille Syrjälä1-1/+0
Not sure where the single pipe only restriction came for fbc1. Nothing I can see that would prevent this. v2: Nuke no_fbc_on_multiple_pipes() too Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2019-12-04drm/i915: Clean up intel_{pre,post}_plane_update()Ville Syrjälä1-4/+4
Change the calling convention to just pass the state+crtc and switch to intel_ types throughout. We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/ so that we'll be able to eliminate old_primary_state later. This is fine since we always have either both old and new state or neither. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2019-06-17drm/i915: move modesetting core code under display/Jani Nikula1-0/+42
Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Acked-by: Maarten Lankhorst <[email protected]> Acked-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.