xref: /openbmc/linux/drivers/gpu/drm/i915/TODO.txt (revision 4f2c0a4acffbec01079c28f839422e64ddeff004)
16ab61ad5SDaniel Vettergem/gt TODO items
26ab61ad5SDaniel Vetter-----------------
36ab61ad5SDaniel Vetter
46ab61ad5SDaniel Vetter- For discrete memory manager, merge enough dg1 to be able to refactor it to
56ab61ad5SDaniel Vetter  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
66ab61ad5SDaniel Vetter  improved a lot the past 2 years, there's no reason anymore not to use it.
76ab61ad5SDaniel Vetter
86ab61ad5SDaniel Vetter- Come up with a plan what to do with drm/scheduler and how to get there.
96ab61ad5SDaniel Vetter
106ab61ad5SDaniel Vetter- Roll out dma_fence critical section annotations.
116ab61ad5SDaniel Vetter
126ab61ad5SDaniel Vetter- There's a lot of complexity added past few years to make relocations faster.
136ab61ad5SDaniel Vetter  That doesn't make sense given hw and gpu apis moved away from this model years
146ab61ad5SDaniel Vetter  ago:
156ab61ad5SDaniel Vetter  1. Land a modern pre-bound uapi like VM_BIND
166ab61ad5SDaniel Vetter  2. Any complexity added in this area past few years which can't be justified
176ab61ad5SDaniel Vetter  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
186ab61ad5SDaniel Vetter  the bo and vm, plus some lru locks is all that needed. No complex rcu,
196ab61ad5SDaniel Vetter  refcounts, caching, ... on everything.
206ab61ad5SDaniel Vetter  This is the matching task on the vm side compared to ttm/dma_resv on the
216ab61ad5SDaniel Vetter  backing storage side.
226ab61ad5SDaniel Vetter
236ab61ad5SDaniel Vetter- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
246ab61ad5SDaniel Vetter  How-to-dma_fence is core and drivers really shouldn't build their own world
256ab61ad5SDaniel Vetter  here, treating everything else as a fixed platform. i915_sw_fence concepts
266ab61ad5SDaniel Vetter  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
276ab61ad5SDaniel Vetter  removed if dri-devel consensus is that it's not a good idea. Once that's done
286ab61ad5SDaniel Vetter  maybe even remove it if there's nothing left.
296ab61ad5SDaniel Vetter
306ab61ad5SDaniel VetterSmaller things:
316ab61ad5SDaniel Vetter- i915_utils.h needs to be moved to the right places.
326ab61ad5SDaniel Vetter
336ab61ad5SDaniel Vetter- dma_fence_work should be in drivers/dma-buf
346ab61ad5SDaniel Vetter
356ab61ad5SDaniel Vetter- i915_mm.c should be moved to the right places. Some of the helpers also look a
366ab61ad5SDaniel Vetter  bit fishy:
376ab61ad5SDaniel Vetter
386ab61ad5SDaniel Vetter  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
396ab61ad5SDaniel Vetter
40*330c1b31SJani Nikula- tasklet helpers in i915_tasklet.h also look a bit misplaced and should
416ab61ad5SDaniel Vetter  probably be moved to tasklet headers.
42