| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Make sure we properly release the forcewake ref on all error paths.
v2(Lucas):
- Make it less verbose and just fold the unimplemented options into
the default. The exact return value doesn't seem to matter for the
corresponding IGT.
- Replace the user triggerable WARN() with drm_dbg().
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
(!(gt->info.engine_mask & BIT(i))) cases are already
handled in the init function. And these masks are not
modified between the init and the prune.
Suggested-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
|
|
The list of GTs got splitted a while back between GT1
and GT2 on TGL.
References: https://patchwork.freedesktop.org/patch/388414/
CC: Rodrigo Vivi <[email protected]>
Signed-off-by: Carlos Santa <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
ret is not initialized in mcr_lock() when running in platforms with
graphics IP version < 1270, this could cause drm_WARN_ON_ONCE()
to hit eventually(what just happened to me).
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Just like there is support for multiple rules per entry in an rtp table,
also support multiple actions. This makes it easier to add support for
workarounds that need to change multiple registers. It also makes it
slightly more readable as now the action part resembles the rule part.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Entry flags is meant for the whole entry, including the rule
evaluation. Action flags are for flags applied to the register or
action being taken. Since there's only one action per entry, the
distinction was not important and a u8 was spared. However more and more
workarounds are needing multiple actions. This prepares for multiple
action support.
Right now there are these action flags:
- XE_RTP_ACTION_FLAG_MASKED_REG: register in the action is a masked
register
- XE_RTP_ACTION_FLAG_ENGINE_BASE: the engine base should be added to
the register in order to form the real address
And this entry flag:
- XE_RTP_ENTRY_FLAG_FOREACH_ENGINE: the rules should be evaluated for
each engine on the gt. It also automatically implies
XE_RTP_ACTION_FLAG_ENGINE_BASE.
Since there are likely not that many rules, reduce n_rules to u8 so the
overall entry size doesn't increase more than needed.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
It's true that the struct records the register and the value (in form of
2 masks) to restore, but it also records more fields important to
the application of workarounds/tuning, etc. One important part is what
is the macro used to record these fields: SET/CLR/WR/FIELD_SET/etc.
Thinking of the table as a set of rules + actions is more intuitive than
rules + regval.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Like detailed in commit 927dfdd09d8c ("drm/i915/dg2: Add SQIDI
steering"), some registers are expected to have the selector
initialized just once and never set to anything else. For xe, the
registers with SQIDI replication type (SF and MCFG) were missing,
resulting in warnings like:
[ 410.685565] xe 0000:03:00.0: Did not find MCR register 0x8724 in any MCR steering table
While adding these registers, abstract the handling for
"dg2_gam_ranges", moving them together with SF/MCFG to a dedicated
table. This also avoids that range to be checked for platforms other
than DG2. For DG2, this is the new steering output:
# cat /sys/kernel/debug/dri/0/gt0/steering
...
IMPLICIT steering: group=0x0, instance=0x0
0x000b00 - 0x000bff
0x001000 - 0x001fff
0x004000 - 0x004aff
0x008700 - 0x0087ff
0x00c800 - 0x00cfff
0x00f000 - 0x00ffff
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
There is already a BUILD_BUG_ON() check to make sure the size follow the
number of steering types. Also make sure the right index is being used
for each steering type.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
LRC workarounds are already implemented: remove leftover TODO.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The function pointer is already present as match_func, inside
struct xe_rtp_rule and handled as so instead of inside rtp_regval as
originally thought out when this was written.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
xe_tuning.c should include xe_tuning.h, not xe_wa.h
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Add missing "multicast" word and adapt/wrap the rest of the sentence.
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Adding a debugfs dump of GGTT was useful for some debugging I did,
and easy to add. Might be useful for others too.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Now that we issue TLB invalidations on unbinds and rebind from execs we
no longer need to issue TLB invalidations from the ring operations.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
If we add an TLB invalidation fence for rebinds issued from execs we
should be able to drop the TLB invalidation from the ring operations.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
Rather than alias supports_usm to ASIS support, add an explicit
variable to indicate ASID support.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
This means we are in the middle of a GT reset and no need to do TLB
invalidation so just signal invalidation fence immediately.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
If a VM unbind hits an error, do not issue a TLB invalidation and
propagate the error the invalidation fence.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
Make lockdep happy as we required to hold the GGTT when calling
xe_ggtt_map_bo.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
Only the GuC should be issuing TLB invalidations if it is enabled. Part
of this patch is sanitize the device on driver unload to ensure we do
not send GuC based TLB invalidations during driver unload.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
If an bind operation fails we need to report it via the async fence.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
If the platform supports range based TLB invalidations use them. Hide
these details in the xe_gt_tlb_invalidation layer.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
This will help implementing range based TLB invalidations.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
Not used, let's remove this.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
This will help with TLB invalidation as the ASID in TLB invalidate
should be zero for platforms that do not support a ASID.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
Endless fences are not good, add a TDR to cleanup any invalidation
fences which have not received an invalidation message within a timeout
period.
Signed-off-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
|
|
This will help debug issues with TLB invalidation fences.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Document all exported functions.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This gets tricky as we can't do the TLB invalidation until the unbind
operation is done on the hardware and we can't signal the unbind as
complete until the TLB invalidation is done. To work around this we
create an unbind fence which does a TLB invalidation after unbind is
done on the hardware, signals on TLB invalidation completion, and this
fence is installed in the BO dma-resv slot and installed in out-syncs
for the unbind operation.
Signed-off-by: Matthew Brost <[email protected]>
Suggested-by: Niranjana Vishwanathapura <[email protected]
Suggested-by: Thomas Hellström <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Fence will be signaled when TLB invalidation completion.
Signed-off-by: Matthew Brost <[email protected]>
Suggested-by: Thomas Hellström <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
TLB invalidations no longer just restricted to USM, move the variables
to own sub-structure.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
TLB invalidation is used by more than USM (page faults) so break this
code out into its own file.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
We can't currently do this due to TLB invalidation done handler
expecting the seqno being received in-order, with the fast-path a TLB
invalidation done could pass one being processed in the slow-path in an
extreme corner case. Remove TLB invalidation done from the fast-path for
now and in a follow up reenable this once the TLB invalidation done
handler can deal with out of order seqno.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Niranjana Vishwanathapura <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
emit_pte assumes the size argument is 4k aligned, this may not be true
for the PTEs emitted for CSS as seen by below call stack:
[ 56.734228] xe_migrate_copy:585: size=327680, ccs_start=327680, css_size=1280,4096
[ 56.734250] xe_migrate_copy:643: size=262144
[ 56.734252] emit_pte:404: ptes=64
[ 56.734255] emit_pte:418: chunk=64
[ 56.734257] xe_migrate_copy:650: size=1024 @ CCS emit PTE
[ 56.734259] emit_pte:404: ptes=1
[ 56.734261] emit_pte:418: chunk=1
[ 56.734339] xe_migrate_copy:643: size=65536
[ 56.734342] emit_pte:404: ptes=16
[ 56.734344] emit_pte:418: chunk=16
[ 56.734346] xe_migrate_copy:650: size=256 # CCS emit PTE
[ 56.734348] emit_pte:404: ptes=1
[ 56.734350] emit_pte:418: chunk=1
[ 56.734352] xe_res_next:174: size=4096, remaining=0
Update emit_pte to handle sizes less than 4k.
Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Scratch page is in VRAM, and therefore requires 64K GTT layout. In GGTT
world this just means having 16 consecutive entries, with 64K GTT
alignment for the GTT address of the first entry (also matching physical
alignment). However to keep things simple just dump it into system
memory, like we already do for ppGTT. While we are here, also give it
known default value.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Spec says we need to use 64K VRAM pages for GGTT on platforms like DG2.
In GGTT this just means aligning the GTT address to 64K and ensuring
that we have 16 consecutive entries each pointing to the respective 4K
entry. We already ensure we have 64K pages underneath, so it's just a
case of forcing the GTT alignment.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
On DG2 when running the xe_vm IGT, the kernel generates loads of CAT
errors and GT resets (sometimes at least). On small-bar systems seems
to trigger a lot more easily (maybe due to difference in allocation
strategy). Appears to be related to scratch, since we seem to use the
64K TLB hint on scratch entries, even though the scratch page is a 4K
vram page. Bumping the scratch page size and physical alignment seems
to fix it. Or at least we no longer hit:
[ 148.872683] xe 0000:03:00.0: [drm] Engine memory cat error: guc_id=0
[ 148.872701] xe 0000:03:00.0: [drm] Engine memory cat error: guc_id=0
[ 148.875108] WARNING: CPU: 0 PID: 953 at drivers/gpu/drm/xe/xe_guc_submit.c:797
However to keep things simple, so we don't have to deal with 64K TLB
hints, just move the scratch page into system memory on platforms that
require 64K VRAM pages.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
We need to ensure we don't leak the contents to userspace.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
On DGFX this blows up if can call this with a system memory object:
XE_BUG_ON(!mem_type_is_vram(place->mem_type) && place->mem_type != XE_PL_STOLEN);
If we consider dpt it looks like we can already in theory hit this, if
we run out of vram and stolen vram. It at least seems reasonable to
allow calling this on any object which supports CPU access.
Note this also changes the behaviour with stolen VRAM and suspend, such
that we no longer attempt to migrate stolen objects into system memory.
However nothing in stolen should ever need to be restored (same on
integrated), so should be fine. Also on small-bar systems the stolen
portion is pretty much always non-CPU accessible, and currently pinned
objects use plain memcpy when being moved, which doesn't play nicely.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Cc: Thomas Hellström <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
I saw a flicker when booting xe, and it's very likely that the original
FB was not mapped at the same place when inheriting, fix it.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The comparison with < 0 suggests that the memory device access
should be signed to handle underflow. This makes it work more reliably.
As a result, the max refcount is now S32_MAX instead.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This is intended to get some properties that are of interest of UMDs
like the ban state.
Cc: Matthew Brost <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Engine property get uAPI will be added, so to avoid ambiguity here
renaming XE_ENGINE_PROPERTY_X to XE_ENGINE_SET_PROPERTY_X.
No changes in behavior.
Cc: Matthew Brost <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This aligns with other drivers and fixes build failure when
CONFIG_PM_SLEEP is not set, such as on RISC-V.
Signed-off-by: Francois Dugast <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
Some tests are meant to run only on real hardware. Skip those,
if no device was found.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
When adding the frequency management, Meteor Lake platform
was left behind. Handling it properly now.
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Cc: Francois Dugast <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
[ 117.901473] xe 0000:00:02.0: [drm] GuC load failed: status = 0x400000A0
[ 117.901506] xe 0000:00:02.0: [drm] GuC load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01
Signed-off-by: Philippe Lecluse <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
At present the interrupts are enabled while initializing the last GT.
But this is incorrect for a Multi-GT platform, as root GT initialization
will fail with interrupt disabled. Interrupts are required for
the GuC submission triggered during initialization.
Enable the interrupt during the root GT initialization.
Signed-off-by: Balasubramani Vivekanandan <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
ERROR:root:../drivers/gpu/drm/xe/display/intel_fbdev.c:585:5: error: redefinition of ‘intel_fbdev_init’
585 | int intel_fbdev_init(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~
In file included from ../drivers/gpu/drm/xe/display/intel_fbdev.c:55:
../drivers/gpu/drm/xe/display/intel_fbdev.h:26:19: note: previous definition of ‘intel_fbdev_init’ with type ‘int(struct drm_device *)’
26 | static inline int intel_fbdev_init(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:626:6: error: redefinition of ‘intel_fbdev_initial_config_async’
626 | void intel_fbdev_initial_config_async(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:31:20: note: previous definition of ‘intel_fbdev_initial_config_async’ with type ‘void(struct drm_device *)’
31 | static inline void intel_fbdev_initial_config_async(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:646:6: error: redefinition of ‘intel_fbdev_unregister’
646 | void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
| ^~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:35:20: note: previous definition of ‘intel_fbdev_unregister’ with type ‘void(struct xe_device *)’
35 | static inline void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
| ^~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:661:6: error: redefinition of ‘intel_fbdev_fini’
661 | void intel_fbdev_fini(struct drm_i915_private *dev_priv)
| ^~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:39:20: note: previous definition of ‘intel_fbdev_fini’ with type ‘void(struct xe_device *)’
39 | static inline void intel_fbdev_fini(struct drm_i915_private *dev_priv)
| ^~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:692:6: error: redefinition of ‘intel_fbdev_set_suspend’
692 | void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous)
| ^~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:43:20: note: previous definition of ‘intel_fbdev_set_suspend’ with type ‘void(struct drm_device *, int, bool)’ {aka ‘void(struct drm_device *, int, _Bool)’}
43 | static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous)
| ^~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:751:6: error: redefinition of ‘intel_fbdev_output_poll_changed’
751 | void intel_fbdev_output_poll_changed(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:47:20: note: previous definition of ‘intel_fbdev_output_poll_changed’ with type ‘void(struct drm_device *)’
47 | static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:770:6: error: redefinition of ‘intel_fbdev_restore_mode’
770 | void intel_fbdev_restore_mode(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:51:20: note: previous definition of ‘intel_fbdev_restore_mode’ with type ‘void(struct drm_device *)’
51 | static inline void intel_fbdev_restore_mode(struct drm_device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.c:785:27: error: redefinition of ‘intel_fbdev_framebuffer’
785 | struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev)
| ^~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/xe/display/intel_fbdev.h:54:41: note: previous definition of ‘intel_fbdev_framebuffer’ with type ‘struct intel_framebuffer *(struct intel_fbdev *)’
54 | static inline struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev)
| ^~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Cc: Thomas Hellström <[email protected]>
Reviewed-by: Matthew Brost <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
|