drivers/gpu/drm/omapdrm/TODO

Source file repositories/reference/linux-study-clean/drivers/gpu/drm/omapdrm/TODO

File Facts

System: Linux kernel
Corpus path: drivers/gpu/drm/omapdrm/TODO
Extension: [no extension]
Size: 930 bytes
Lines: 24
Domain: Driver Families
Bucket: drivers/gpu
Inferred role: Driver Families: drivers/gpu
Status: atlas-only

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

No C-style include directives detected by the generator.

Detected Declarations

No top-level syscall, struct, function, initcall, or export declaration detected by the generator.

Annotated Snippet

TODO
. Where should we do eviction (detatch_pages())?  We aren't necessarily
  accessing the pages via a GART, so maybe we need some other threshold
  to put a cap on the # of pages that can be pin'd.
  . Use mm_shrinker to trigger unpinning pages.
  . This is mainly theoretical since most of these devices don't actually
    have swap or harddrive.
. GEM/shmem backed pages can have existing mappings (kernel linear map,
  etc..), which isn't really ideal.
. Revisit GEM sync object infrastructure.. TTM has some framework for this
  already.  Possibly this could be refactored out and made more common?
  There should be some way to do this with less wheel-reinvention.
  . This can be handled by the dma-buf fence/reservation stuff when it
    lands

Userspace:
. git://anongit.freedesktop.org/xorg/driver/xf86-video-omap

Currently tested on
. OMAP3530 beagleboard
. OMAP4430 pandaboard
. OMAP4460 pandaboard
. OMAP5432 uEVM

Annotation

Atlas domain: Driver Families / drivers/gpu.
Implementation status: atlas-only.

Implementation Notes

This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.