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 DRMsubsystem, or some specific GPU/display graphics knowledge. For debugging issueit’s good to have the relevant hardware (or a virtual driver set up) availablefor testing.

Advanced: Tricky tasks that need fairly good understanding of the DRM subsystemand graphics topics. Generally need the relevant hardware for development andtesting.

Expert: Only attempt these if you’ve successfully completed some trickyrefactorings already and are an expert in the specific area

Remove custom dumb_map_offset implementations¶

All GEM based drivers should be usingdrm_gem_create_mmap_offset() instead.Audit each individual driver, make sure it’ll work with the genericimplementation (there’s lots of outdated locking leftovers in variousimplementations), and then remove it.

Contact: Simona Vetter, respective driver maintainers

Level: Intermediate

Convert existing KMS drivers to atomic modesetting¶

3.19 has the atomic modeset interfaces and helpers, so drivers can now beconverted over. Modern compositors like Wayland or Surfaceflinger on Androidreally want an atomic modeset interface, so this is all about the brightfuture.

There is a conversion guide for atomic[1] and all you need is a GPU for anon-converted driver. The “Atomic mode setting design overview” series[2][3] at LWN.net can also be helpful.

As part of this drivers also need to convert to universal plane (which meansexposing primary & cursor as proper plane objects). But that’s much easier todo by directly using the new atomic helper driver callbacks.

[1]

https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html

[2]

https://lwn.net/Articles/653071/

[3]

https://lwn.net/Articles/653466/

Contact: Simona Vetter, respective driver maintainers

Level: Advanced

Clean up the clipped coordination confusion around planes¶

We have a helper to get this right withdrm_plane_helper_check_update(), butit’s not consistently used. This should be fixed, preferably in the atomichelpers (and drivers then moved over to clipped coordinates). Probably thehelper should also be moved from drm_plane_helper.c to the atomic helpers, toavoid confusion - the other helpers in that file are all deprecated legacyhelpers.

Contact: Ville Syrjälä, Simona Vetter, driver maintainers

Level: Advanced

Improve plane atomic_check helpers¶

Aside from the clipped coordinates right above there’s a few suboptimal thingswith the current helpers:

• drm_plane_helper_funcs->atomic_check gets called for enabled or disabledplanes. At best this seems to confuse drivers, worst it means they blow upwhen the plane is disabled without the CRTC. The only special handling isresetting values in the plane state structures, which instead should be movedinto the drm_plane_funcs->atomic_duplicate_state functions.

• Once that’s done, helpers could stop calling ->atomic_check for disabledplanes.

• Then we could go through all the drivers and remove the more-or-less confusedchecks for plane_state->fb and plane_state->crtc.

Contact: Simona Vetter

Level: Advanced

Convert early atomic drivers to async commit helpers¶

For the first year the atomic modeset helpers didn’t support asynchronous /nonblocking commits, and every driver had to hand-roll them. This is fixednow, but there’s still a pile of existing drivers that easily could beconverted over to the new infrastructure.

One issue with the helpers is that they require that drivers handle completionevents for atomic commits correctly. But fixing these bugs is good anyway.

Somewhat related is the legacy_cursor_update hack, which should be replaced withthe new atomic_async_check/commit functionality in the helpers in drivers thatstill look at that flag.

Contact: Simona Vetter, respective driver maintainers

Level: Advanced

Rename drm_atomic_state¶

The KMS framework uses two slightly different definitions for thestateconcept. For a given object (plane, CRTC, encoder, etc., sodrm_$OBJECT_state), the state is the entire state of that object. However,at the device level,drm_atomic_state refers to a state update for alimited number of objects.

The state isn’t the entire device state, but only the full state of someobjects in that device. This is confusing to newcomers, anddrm_atomic_state should be renamed to something clearer likedrm_atomic_commit.

In addition to renaming the structure itself, it would also imply renaming somerelated functions (drm_atomic_state_alloc,drm_atomic_state_get,drm_atomic_state_put,drm_atomic_state_init,__drm_atomic_state_free, etc.).

Contact: Maxime Ripard <mripard@kernel.org>

Level: Advanced

Fallout from atomic KMS¶

drm_atomic_helper.c provides a batch of functions which implement legacyIOCTLs on top of the new atomic driver interface. Which is really nice forgradual conversion of drivers, but unfortunately the semantic mismatches area bit too severe. So there’s some follow-up work to adjust the functioninterfaces to fix these issues:

• atomic needs the lock acquire context. At the moment that’s passed aroundimplicitly with some horrible hacks, and it’s also allocate withGFP_NOFAIL behind the scenes. All legacy paths need to start allocatingthe acquire context explicitly on stack and then also pass it down intodrivers explicitly so that the legacy-on-atomic functions can use them.

  Except for some driver code this is done. This task should be finished byadding WARN_ON(!drm_drv_uses_atomic_modeset) indrm_modeset_lock_all().

• A bunch of the vtable hooks are now in the wrong place: DRM has a splitbetween core vfunc tables (nameddrm_foo_funcs), which are used toimplement the userspace ABI. And then there’s the optional hooks for thehelper libraries (namedrm_foo_helper_funcs), which are purely forinternal use. Some of these hooks should be move from_funcs to_helper_funcs since they are not part of the core ABI. There’s aFIXME comment in the kerneldoc for each such case indrm_crtc.h.

Contact: Simona Vetter

Level: Intermediate

Move Buffer Object Locking to dma_resv_lock()¶

Many drivers have their own per-object locking scheme, usually usingmutex_lock(). This causes all kinds of trouble for buffer sharing, sincedepending which driver is the exporter and importer, the locking hierarchy isreversed.

To solve this we need one standard per-object locking mechanism, which isdma_resv_lock(). This lock needs to be called as the outermost lock, with allother driver specific per-object locks removed. The problem is that rolling outthe actual change to the locking contract is a flag day, due tostructdma_bufbuffer sharing.

Level: Expert

Convert logging to drm_* functions with drm_device parameter¶

For drivers which could have multiple instances, it is necessary todifferentiate between which is which in the logs. Since DRM_INFO/WARN/ERRORdon’t do this, drivers used dev_info/warn/err to make this differentiation. Wenow have drm_* variants of the drm print functions, so we can start to convertthose drivers back to using drm-formatted specific log messages.

Before you start this conversion please contact the relevant maintainers to makesure your work will be merged - not everyone agrees that the DRM dmesg macrosare better.

Contact: Sean Paul, Maintainer of the driver you plan to convert

Level: Starter

Convert drivers to use simple modeset suspend/resume¶

Most drivers (except i915 and nouveau) that usedrm_atomic_helper_suspend/resume() can probably be converted to usedrm_mode_config_helper_suspend/resume(). Also there’s still open-coded versionof the atomic suspend/resume code in older atomic modeset drivers.

Contact: Maintainer of the driver you plan to convert

Level: Intermediate

Reimplement functions in drm_fbdev_fb_ops without fbdev¶

A number of callback functions in drm_fbdev_fb_ops could benefit frombeing rewritten without dependencies on the fbdev module. Some of thehelpers could further benefit from usingstructiosys_map instead ofraw pointers.

Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter

Level: Advanced

Benchmark and optimize blitting and format-conversion function¶

Drawing to display memory quickly is crucial for many applications’performance.

On at least x86-64,sys_imageblit() is significantly slower thancfb_imageblit(), even though both use the same blitting algorithm andthe latter is written for I/O memory. It turns out thatcfb_imageblit()uses movl instructions, while sys_imageblit apparently does not. Thisseems to be a problem with gcc’s optimizer. DRM’s format-conversionhelpers might be subject to similar issues.

Benchmark and optimize fbdev’ssys_() helpers and DRM’s format-conversionhelpers. In cases that can be further optimized, maybe implement a differentalgorithm. For micro-optimizations, use movl/movq instructions explicitly.That might possibly require architecture-specific helpers (e.g.,storel()storeq()).

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Intermediate

drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup¶

A lot more drivers could be switched over to the drm_gem_framebuffer helpers.Various hold-ups:

• Need to switch over to the generic dirty tracking code usingdrm_atomic_helper_dirtyfb first (e.g. qxl).

• Need to switch todrm_fbdev_generic_setup(), otherwise a lot of the custom fbsetup code can’t be deleted.

• Need to switch todrm_gem_fb_create(), as nowdrm_gem_fb_create() checks forvalid formats for atomic drivers.

• Many drivers subclass drm_framebuffer, we’d need a embedding compatibleversion of the varios drm_gem_fb_create functions. Maybe calleddrm_gem_fb_create/_with_dirty/_with_funcs as needed.

Contact: Simona Vetter

Level: Intermediate

Generic fbdev defio support¶

The defio support code in the fbdev core has some very specific requirements,which means drivers need to have a special framebuffer for fbdev. The mainissue is that it uses some fields instructpage itself, which breaks shmemgem objects (and other things). To support defio, affected drivers requirethe use of a shadow buffer, which may add CPU and memory overhead.

Possible solution would be to write our own defio mmap code in the drm fbdevemulation. It would need to fully wrap the existing mmap ops, forwardingeverything after it has done the write-protect/mkwrite trickery:

• In the drm_fbdev_fb_mmap helper, if we need defio, change thedefault page prots to write-protected with something like this:

  vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);

• Set the mkwrite and fsync callbacks with similar implementions to the corefbdev defio stuff. These should all work on plain ptes, they don’t actuallyrequire astructpage. uff. These should all work on plain ptes, they don’tactually require astructpage.

• Track the dirty pages in a separate structure (bitfield with one bit per pageshould work) to avoid clobberingstructpage.

Might be good to also have some igt testcases for this.

Contact: Simona Vetter, Noralf Tronnes

Level: Advanced

connector register/unregister fixes¶

• For most connectors it’s a no-op to call drm_connector_register/unregisterdirectly from driver code, drm_dev_register/unregister take care of thisalready. We can remove all of them.

• For dp drivers it’s a bit more a mess, since we need the connector to beregistered when calling drm_dp_aux_register. Fix this by instead callingdrm_dp_aux_init, and moving the actual registering into a late_registercallback as recommended in the kerneldoc.

Level: Intermediate

Remove load/unload callbacks¶

The load/unload callbacks in struct &drm_driver are very much midlayers, plusfor historical reasons they get the ordering wrong (and we can’t fix that)between setting up the &drm_driver structure and callingdrm_dev_register().

• Rework drivers to no longer use the load/unload callbacks, directly coding theload/unload sequence into the driver’s probe function.

• Once all drivers are converted, remove the load/unload callbacks.

Contact: Simona Vetter

Level: Intermediate

Replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi¶

Once EDID is parsed, the monitor HDMI support information is available throughdrm_display_info.is_hdmi. Many drivers still calldrm_detect_hdmi_monitor() toretrieve the same information, which is less efficient.

Audit each individual driver callingdrm_detect_hdmi_monitor() and switch todrm_display_info.is_hdmi if applicable.

Contact: Laurent Pinchart, respective driver maintainers

Level: Intermediate

Consolidate custom driver modeset properties¶

Before atomic modeset took place, many drivers where creating their ownproperties. Among other things, atomic brought the requirement that custom,driver specific properties should not be used.

For this task, we aim to introduce core helpers or reuse the existing onesif available:

A quick, unconfirmed, examples list.

Introduce core helpers:- audio (amdgpu, intel, gma500, radeon)- brightness, contrast, etc (armada, nouveau) - overlay only (?)- broadcast rgb (gma500, intel)- colorkey (armada, nouveau, rcar) - overlay only (?)- dither (amdgpu, nouveau, radeon) - varies across drivers- underscan family (amdgpu, radeon, nouveau)

Already in core:- colorspace (sti)- tv format names, enhancements (gma500, intel)- tv overscan, margins, etc. (gma500, intel)- zorder (omapdrm) - same as zpos (?)

Contact: Emil Velikov, respective driver maintainers

Level: Intermediate

Use struct iosys_map throughout codebase¶

Pointers to shared device memory are stored instructiosys_map. Eachinstance knows whether it refers to system or I/O memory. Most of the DRM-wideinterface have been converted to usestructiosys_map, but implementationsoften still use raw pointers.

The task is to usestructiosys_map where it makes sense.

• Memory managers should usestructiosys_map for dma-buf-imported buffers.

• TTM might benefit from usingstructiosys_map internally.

• Framebuffer copying and blitting helpers should operate onstructiosys_map.

Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter

Level: Intermediate

Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly¶

The values instructdrm_mode_config.{max_width,max_height} describe themaximum supported framebuffer size. It’s the virtual screen size, but manydrivers treat it like limitations of the physical resolution.

The maximum width depends on the hardware’s maximum scanline pitch. Themaximum height depends on the amount of addressable video memory. Review alldrivers to initialize the fields to the correct values.

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Intermediate

Request memory regions in all fbdev drivers¶

Old/ancient fbdev drivers do not request their memory properly.Go through these drivers and add code to request the memory regionsthat the driver uses. This requires adding calls torequest_mem_region(),pci_request_region() or similar functions. Use helpers for managed cleanupwhere possible. Problematic areas include hardware that has exclusive rangeslike VGA. VGA16fb does not request the range as it is expected.Drivers are pretty bad at doing this and there used to be conflicts amongDRM and fbdev drivers. Still, it’s the correct thing to do.

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Starter

Remove driver dependencies on FB_DEVICE¶

A number of fbdev drivers provide attributes via sysfs and therefore dependon CONFIG_FB_DEVICE to be selected. Review each driver and attempt to makeany dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respectivecode in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Notall drivers might be able to drop CONFIG_FB_DEVICE.

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Starter

Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp¶

As ofcommit d2aacaf07395 (“drm/panel: Check for already prepared/enabled indrm_panel”), we have a check in the drm_panel core to make sure nobodydouble-calls prepare/enable/disable/unprepare. Eventually that should probablybe turned into aWARN_ON() or somehow made louder.

At the moment, we expect that we may still encounter the warnings in thedrm_panel core when using panel-simple and panel-edp. Since those paneldrivers are used with a lot of different DRM modeset drivers they stillmake an extra effort to disable/unprepare the panel themsevles at shutdowntime. Specifically we could still encounter those warnings if the paneldriver getsshutdown() _before_ the DRM modeset driver and the DRM modesetdriver properly callsdrm_atomic_helper_shutdown() in its ownshutdown()callback. Warnings could be avoided in such a case by using something likedevice links to ensure that the panel getsshutdown() after the DRM modesetdriver.

Once all DRM modeset drivers are known to shutdown properly, the extracalls to disable/unprepare in remove/shutdown in panel-simple and panel-edpshould be removed and this TODO item marked complete.

Contact: Douglas Anderson <dianders@chromium.org>

Level: Intermediate

Transition away from using deprecated MIPI DSI functions¶

There are many functions defined indrm_mipi_dsi.c which have beendeprecated. Each deprecated function was deprecated in favor of itsmultivariant (e.g.mipi_dsi_generic_write() andmipi_dsi_generic_write_multi()).Themulti variant of a function includes improved error handling and logicwhich makes it more convenient to make several calls in a row, as most MIPIdrivers do.

Drivers should be updated to use undeprecated functions. Once all usages of thedeprecated MIPI DSI functions have been removed, their definitions may beremoved fromdrm_mipi_dsi.c.

Contact: Douglas Anderson <dianders@chromium.org>

Level: Starter

Remove devm_drm_put_bridge()¶

Due to how the panel bridge handles the drm_bridge object lifetime, specialcare must be taken to dispose of the drm_bridge object when thepanel_bridge is removed. This is currently managed usingdevm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fixthat, the DRM panel lifetime needs to be reworked. After the rework isdone, removedevm_drm_put_bridge() and the TODO indrm_panel_bridge_remove().

Contact: Maxime Ripard <mripard@kernel.org>,

Luca Ceresoli <luca.ceresoli@bootlin.com>

Level: Intermediate

Convert users of of_drm_find_bridge() to of_drm_find_and_get_bridge()¶

Taking astructdrm_bridge pointer requires getting a reference and puttingit after disposing of the pointer. Most functions returning astructdrm_bridge pointer already calldrm_bridge_get() to increment the refcountand their users have been updated to calldrm_bridge_put() whenappropriate.of_drm_find_bridge() does not get a reference and it has beendeprecated in favor ofof_drm_find_and_get_bridge() which does, but someusers still need to be converted.

Contact: Maxime Ripard <mripard@kernel.org>,

Luca Ceresoli <luca.ceresoli@bootlin.com>

Level: Intermediate

Make panic handling work¶

This is a really varied tasks with lots of little bits and pieces:

• The panic path can’t be tested currently, leading to constant breaking. Themain issue here is that panics can be triggered from hardirq contexts andhence all panic related callback can run in hardirq context. It would beawesome if we could test at least the fbdev helper code and driver code bye.g. trigger calls through drm debugfs files. hardirq context could beachieved by using an IPI to the local processor.

• There’s a massive confusion of different panic handlers. DRM fbdev emulationhelpers had their own (long removed), but on top of that the fbcon code itselfalso has one. We need to make sure that they stop fighting over each other.This is worked around by checkingoops_in_progress at various entry pointsinto the DRM fbdev emulation helpers. A much cleaner approach here would be toswitch fbcon to thethreaded printk support.

• drm_can_sleep() is a mess. It hides real bugs in normal operations andisn’t a full solution for panic paths. We need to make sure that it onlyreturns true if there’s a panic going on for real, and fix up all thefallout.

• The panic handler must never sleep, which also means it can’t evermutex_lock(). Also it can’t grab any other lock unconditionally, noteven spinlocks (because NMI and hardirq can panic too). We need to eithermake sure to not call such paths, or trylock everything. Really tricky.

• A clean solution would be an entirely separate panic output support in KMS,bypassing the current fbcon support. See[PATCH v2 0/3] drm: Add panic handling.

• Encoding the actual oops and preceding dmesg in a QR might help with thedread “important stuff scrolled away” problem. See[RFC][PATCH] Oops messagestransfer using QR codesfor some example code that could be reused.

Contact: Simona Vetter

Level: Advanced

Clean up the debugfs support¶

There’s a bunch of issues with it:

• Convert drivers to support thedrm_debugfs_add_files() function instead ofthedrm_debugfs_create_files() function.

• Improve late-register debugfs by rolling out the same debugfs pre-registerinfrastructure for connector and crtc too. That way, the drivers won’t need tosplit their setup code into init and register anymore.

• We probably want to have some support for debugfs files on crtc/connectors andmaybe other kms objects directly in core. There’s even drm_print support inthe funcs for these objects to dump kms state, so it’s all there. And then the->show() functions should obviously give you a pointer to the right object.

• The drm_driver->debugfs_init hooks we have is just an artifact of the oldmidlayered load sequence. DRM debugfs should work more like sysfs, where youcan create properties/files for an object anytime you want, and the coretakes care of publishing/unpuplishing all the files at register/unregistertime. Drivers shouldn’t need to worry about these technicalities, and fixingthis (together with the drm_minor->drm_device move) would allow us to removedebugfs_init.

Contact: Simona Vetter

Level: Intermediate

Object lifetime fixes¶

There’s two related issues here

• Cleanup up the various ->destroy callbacks, which often are all the samesimple code.

• Lots of drivers erroneously allocate DRM modeset objects using devm_kzalloc,which results in use-after free issues on driver unload. This can be serioustrouble even for drivers for hardware integrated on the SoC due toEPROBE_DEFERRED backoff.

Both these problems can be solved by switching over todrmm_kzalloc(), and thevarious convenience wrappers provided, e.g.drmm_crtc_alloc_with_planes(),drmm_universal_plane_alloc(), ... and so on.

Contact: Simona Vetter

Level: Intermediate

Remove automatic page mapping from dma-buf importing¶

When importing dma-bufs, the dma-buf and PRIME frameworks automatically mapimported pages into the importer’s DMA area.drm_gem_prime_fd_to_handle() anddrm_gem_prime_handle_to_fd() require that importers calldma_buf_attach()even if they never do actual device DMA, but only CPU access throughdma_buf_vmap(). This is a problem for USB devices, which do not support DMAoperations.

To fix the issue, automatic page mappings should be removed from thebuffer-sharing code. Fixing this is a bit more involved, since the import/exportcache is also tied to &drm_gem_object.import_attach. Meanwhile we paper overthis problem for USB devices by fishing out the USB host controller device, aslong as that supports DMA. Otherwise importing can still needlessly fail.

Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter

Level: Advanced

Implement a new DUMB_CREATE2 ioctl¶

The current DUMB_CREATE ioctl is not well defined. Instead of a pixel andframebuffer format, it only accepts a color mode of vague semantics. Assuminga linear framebuffer, the color mode gives an idea of the supported pixelformat. But userspace effectively has to guess the correct values. It reallyonly works reliably with framebuffers in XRGB8888. Userspace has begun toworkaround these limitations by computing arbitrary format’s buffer sizes andcalculating their sizes in terms of XRGB8888 pixels.

One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRMformat and a format modifier to resolve the color mode’s ambiguity. Asframebuffers can be multi-planar, the new ioctl has to return the buffer size,pitch and GEM handle for each individual color plane.

In the first step, the new ioctl can be limited to the current features ofthe existing DUMB_CREATE. Individual drivers can then be extended to supportmulti-planar formats. Rockchip might require this and would be a good candidate.

It might also be helpful to userspace to query information about the size ofa potential buffer, if allocated. Userspace would supply geometry and format;the kernel would return minimal allocation sizes and scanline pitch. There isinterest to allocate that memory from another device and provide it to theDRM driver (say via dma-buf).

Another requested feature is the ability to allocate a buffer by size, withoutformat. Accelators use this for their buffer allocation and it could likely begeneralized.

In addition to the kernel implementation, there must be user-space supportfor the new ioctl. There’s code in Mesa that might be able to use the newcall.

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Advanced

Add unit tests using the Kernel Unit Testing (KUnit) framework¶

TheKUnitprovides a common framework for unit tests within the Linux kernel. Having atest suite would allow to identify regressions earlier.

A good candidate for the first unit tests are the format-conversion helpers indrm_format_helper.c.

Contact: Javier Martinez Canillas <javierm@redhat.com>

Level: Intermediate

Clean up and document former selftests suites¶

Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper,drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper anddrm_rect) are former selftests suites that have been converted over when KUnitwas first introduced.

These suites were fairly undocumented, and with different goals than what unittests can be. Trying to identify what each test in these suites actually testfor, whether that makes sense for a unit test, and either remove it if itdoesn’t or document it if it does would be of great help.

Contact: Maxime Ripard <mripard@kernel.org>

Level: Intermediate

Enable trinity for DRM¶

And fix up the fallout. Should be really interesting ...

Level: Advanced

Make KMS tests in i-g-t generic¶

The i915 driver team maintains an extensive testsuite for the i915 DRM driver,including tons of testcases for corner-cases in the modesetting API. It wouldbe awesome if those tests (at least the ones not relying on Intel-specific GEMfeatures) could be made to run on any KMS driver.

Basic work to run i-g-t tests on non-i915 is done, what’s now missing is mass-converting things over. For modeset tests we also first need a bit ofinfrastructure to use dumb buffers for untiled buffers, to be able to run allthe non-i915 specific modeset tests.

Level: Advanced

Extend virtual test driver (VKMS)¶

See the documentation ofVKMS for more details. This is an idealinternship task, since it only requires a virtual machine and can be sized tofit the available time.

Level: See details

Backlight Refactoring¶

Backlight drivers have a triple enable/disable state, which is a bit overkill.Plan to fix this:

1. Roll outbacklight_enable() andbacklight_disable() helpers everywhere. Thishas started already.

2. In all, only look at one of the three status bits set by the above helpers.

3. Remove the other two status bits.

Contact: Simona Vetter

Level: Intermediate

AMD DC Display Driver¶

AMD DC is the display driver for AMD devices starting with Vega. There has beena bunch of progress cleaning it up but there’s still plenty of work to be done.

See drivers/gpu/drm/amd/display/TODO for tasks.

Contact: Harry Wentland, Alex Deucher

Provide a universal successor for drm_sched_resubmit_jobs()¶

drm_sched_resubmit_jobs() is deprecated. Main reason being that it leads toreinitializing dma_fences. See that function’s docu for details. The betterapproach for valid resubmissions by amdgpu and Xe is (apparently) to figure outwhich job (and, through association: which entity) caused the hang. Then, thejob’s buffer data, together with all other jobs’ buffer data currently in thesame hardware ring, must be invalidated. This can for example be done byoverwriting it. amdgpu currently determines which jobs are in the ring and needto be overwritten by keeping copies of the job. Xe obtains that information bydirectly accessing drm_sched’s pending_list.

Tasks:

1. implement scheduler functionality through which the driver can obtain theinformation whichbroken jobs are currently in the hardware ring.

2. Such infrastructure would then typically be used indrm_sched_backend_ops.timedout_job(). Document that.

3. Port a driver as first user.

4. Document the new alternative in the docu of deprecateddrm_sched_resubmit_jobs().

Contact: Christian König <christian.koenig@amd.com>

Philipp Stanner <phasta@kernel.org>

Level: Advanced

Add locking for runqueues¶

There is an old FIXME by Sima in include/drm/gpu_scheduler.h. It details thatstructdrm_sched_rq is read at many places without any locks, not even with aREAD_ONCE. At XDC 2025 no one could really tell why that is the case, whetherlocks are needed and whether they could be added. (But for real, that shouldprobably be locked!). Check whether it’s possible to add locks everywhere, anddo so if yes.

Contact: Philipp Stanner <phasta@kernel.org>

Level: Intermediate

Convert fbdev drivers to DRM¶

There are plenty of fbdev drivers for older hardware. Some hardware hasbecome obsolete, but some still provides good(-enough) framebuffers. Thedrivers that are still useful should be converted to DRM and afterwardsremoved from fbdev.

Very simple fbdev drivers can best be converted by starting with a newDRM driver. Simple KMS helpers and SHMEM should be able to handle anyexisting hardware. The new driver’s call-back functions are filled fromexisting fbdev code.

More complex fbdev drivers can be refactored step-by-step into a DRMdriver with the help of the DRM fbconv helpers[4]. These helpers providethe transition layer between the DRM core infrastructure and the fbdevdriver interface. Create a new DRM driver on top of the fbconv helpers,copy over the fbdev driver, and hook it up to the DRM code. Examples forseveral fbdev drivers are available in Thomas Zimmermann’s fbconv tree[4], as well as a tutorial of this process[5]. The result is a primitiveDRM driver that can run X11 and Weston.

[4](1,2)

https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv

[5]

https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c

Contact: Thomas Zimmermann <tzimmermann@suse.de>

Level: Advanced