Hi,
On 3/9/23 06:14, Zack Rusin wrote:
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it star
On 3/8/23 10:10, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved
over
to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
>
> Am 08.03.23 um 06:14 schrieb Zack Rusin:
> > On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
> > > VMWGFX is the only remaining user of this and should probably moved over
> > > to drm_exec when it starts using GEM as well.
>
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks buffer-id relocations on top of ttm
valida
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
> VMWGFX is the only remaining user of this and should probably moved over
> to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks buffer-id relocations on top of ttm
validations or
did you just find it too hard t
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it starts using GEM as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 4 ++--
drivers/gpu/drm/vmwgfx/Makefile| 2 +-
driver
