Documentation/gpu/todo.rst
Source file repositories/reference/linux-study-clean/Documentation/gpu/todo.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/gpu/todo.rst- Extension
.rst- Size
- 39844 bytes
- Lines
- 982
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
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:
=========
TODO list
=========
This section contains a list of smaller janitorial tasks in the kernel DRM
graphics subsystem useful as newbie projects. Or for slow rainy days.
Difficulty
----------
To make it easier task are categorized into different levels:
Starter: Good tasks to get started with the DRM subsystem.
Intermediate: Tasks which need some experience with working in the DRM
subsystem, or some specific GPU/display graphics knowledge. For debugging issue
it's good to have the relevant hardware (or a virtual driver set up) available
for testing.
Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem
and graphics topics. Generally need the relevant hardware for development and
testing.
Expert: Only attempt these if you've successfully completed some tricky
refactorings already and are an expert in the specific area
Subsystem-wide refactorings
===========================
Open-code drm_simple_encoder_init()
-----------------------------------
The helper drm_simple_encoder_init() was supposed to simplify encoder
initialization. Instead it only added an intermediate layer between atomic
modesetting and the DRM driver.
The task here is to remove drm_simple_encoder_init(). Search for a driver
that calls drm_simple_encoder_init() and inline the helper. The driver will
also need its own instance of drm_encoder_funcs.
Contact: Thomas Zimmermann, respective driver maintainer
Level: Easy
Replace struct drm_simple_display_pipe with regular atomic helpers
------------------------------------------------------------------
The data type struct drm_simple_display_pipe and its helpers were supposed
to simplify driver development. Instead they only added an intermediate layer
between atomic modesetting and the DRM driver.
There are still drivers that use drm_simple_display_pipe. The task here is to
convert them to use regular atomic helpers. Search for a driver that calls
drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c
into the driver, such that no simple-KMS interfaces are required. Please also
rename all inlined fucntions according to driver conventions.
Contact: Thomas Zimmermann, respective driver maintainer
Level: Easy
Remove custom dumb_map_offset implementations
---------------------------------------------
All GEM based drivers should be using drm_gem_create_mmap_offset() instead.
Audit each individual driver, make sure it'll work with the generic
implementation (there's lots of outdated locking leftovers in various
implementations), and then remove it.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.