diff options
Diffstat (limited to 'Documentation/gpu')
-rw-r--r-- | Documentation/gpu/drm-uapi.rst | 55 | ||||
-rw-r--r-- | Documentation/gpu/index.rst | 1 | ||||
-rw-r--r-- | Documentation/gpu/todo.rst | 55 | ||||
-rw-r--r-- | Documentation/gpu/tve200.rst | 6 |
4 files changed, 99 insertions, 18 deletions
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 679373b4a03f..a2214cc1f821 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -168,6 +168,61 @@ IOCTL Support on Device Nodes .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c :doc: driver specific ioctls +Recommended IOCTL Return Values +------------------------------- + +In theory a driver's IOCTL callback is only allowed to return very few error +codes. In practice it's good to abuse a few more. This section documents common +practice within the DRM subsystem: + +ENOENT: + Strictly this should only be used when a file doesn't exist e.g. when + calling the open() syscall. We reuse that to signal any kind of object + lookup failure, e.g. for unknown GEM buffer object handles, unknown KMS + object handles and similar cases. + +ENOSPC: + Some drivers use this to differentiate "out of kernel memory" from "out + of VRAM". Sometimes also applies to other limited gpu resources used for + rendering (e.g. when you have a special limited compression buffer). + Sometimes resource allocation/reservation issues in command submission + IOCTLs are also signalled through EDEADLK. + + Simply running out of kernel/system memory is signalled through ENOMEM. + +EPERM/EACCESS: + Returned for an operation that is valid, but needs more privileges. + E.g. root-only or much more common, DRM master-only operations return + this when when called by unpriviledged clients. There's no clear + difference between EACCESS and EPERM. + +ENODEV: + Feature (like PRIME, modesetting, GEM) is not supported by the driver. + +ENXIO: + Remote failure, either a hardware transaction (like i2c), but also used + when the exporting driver of a shared dma-buf or fence doesn't support a + feature needed. + +EINTR: + DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can + return EINTR and in such a case should be restarted with the IOCTL + parameters left unchanged. + +EIO: + The GPU died and couldn't be resurrected through a reset. Modesetting + hardware failures are signalled through the "link status" connector + property. + +EINVAL: + Catch-all for anything that is an invalid argument combination which + cannot work. + +IOCTL also use other error codes like ETIME, EFAULT, EBUSY, ENOTTY but their +usage is in line with the common meanings. The above list tries to just document +DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of +"this IOCTL does not exist", and is used exactly as such in DRM. + .. kernel-doc:: include/drm/drm_ioctl.h :internal: diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 35d673bf9b56..c36586dad29d 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide pl111 tegra tinydrm + tve200 vc4 vga-switcheroo vgaarbiter diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 22af55d06ab8..96f8ec7dbe4e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -75,17 +75,6 @@ helpers. Contact: Ville Syrjälä, Daniel Vetter, driver maintainers -Implement deferred fbdev setup in the helper --------------------------------------------- - -Many (especially embedded drivers) want to delay fbdev setup until there's a -real screen plugged in. This is to avoid the dreaded fallback to the low-res -fbdev default. Many drivers have a hacked-up (and often broken) version of this, -better to do it once in the shared helpers. Thierry has a patch series, but that -one needs to be rebased and final polish applied. - -Contact: Thierry Reding, Daniel Vetter, driver maintainers - Convert early atomic drivers to async commit helpers ---------------------------------------------------- @@ -138,6 +127,8 @@ interfaces to fix these issues: the acquire context explicitly on stack and then also pass it down into drivers explicitly so that the legacy-on-atomic functions can use them. + Except for some driver code this is done. + * A bunch of the vtable hooks are now in the wrong place: DRM has a split between core vfunc tables (named ``drm_foo_funcs``), which are used to implement the userspace ABI. And then there's the optional hooks for the @@ -151,6 +142,8 @@ interfaces to fix these issues: connector at runtime. That's almost all of them, and would allow us to get rid of a lot of ``best_encoder`` boilerplate in drivers. + This was almost done, but new drivers added a few more cases again. + Contact: Daniel Vetter Get rid of dev->struct_mutex from GEM drivers @@ -177,14 +170,19 @@ following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and Contact: Daniel Vetter, respective driver maintainers -Core refactorings -================= +Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent +---------------------------------------------------------------------------- -Use new IDR deletion interface to clean up drm_gem_handle_delete() ------------------------------------------------------------------- +For drivers which could have multiple instances, it is necessary to +differentiate between which is which in the logs. Since DRM_INFO/WARN/ERROR +don't do this, drivers used dev_info/warn/err to make this differentiation. We +now have DRM_DEV_* variants of the drm print macros, so we can start to convert +those drivers back to using drm-formwatted specific log messages. -See the "This is gross" comment -- apparently the IDR system now can return an -error code instead of oopsing. +Contact: Sean Paul, Maintainer of the driver you plan to convert + +Core refactorings +================= Clean up the DRM header mess ---------------------------- @@ -306,6 +304,18 @@ There's a bunch of issues with it: Contact: Daniel Vetter +KMS cleanups +------------ + +Some of these date from the very introduction of KMS in 2008 ... + +- drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should + be renamed to drm_mode_config.object_idr. + +- drm_display_mode doesn't need to be derived from drm_mode_object. That's + leftovers from older (never merged into upstream) KMS designs where modes + where set using their ID, including support to add/remove modes. + Better Testing ============== @@ -353,7 +363,16 @@ those drivers as simple as possible, so lots of room for refactoring: - backlight helpers, probably best to put them into a new drm_backlight.c. This is because drivers/video is de-facto unmaintained. We could also move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. + over within drm-misc, but that's more work. Backlight helpers require a fair + bit of reworking and refactoring. A simple example is the enabling of a backlight. + Tinydrm has helpers for this. It would be good if other drivers can also use the + helper. However, there are various cases we need to consider i.e different + drivers seem to have different ways of enabling/disabling a backlight. + We also need to consider the backlight drivers (like gpio_backlight). The situation + is further complicated by the fact that the backlight is tied to fbdev + via fb_notifier_callback() which has complicated logic. For further details, refer + to the following discussion thread: + https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA - spi helpers, probably best put into spi core/helper code. Thierry said the spi maintainer is fast&reactive, so shouldn't be a big issue. diff --git a/Documentation/gpu/tve200.rst b/Documentation/gpu/tve200.rst new file mode 100644 index 000000000000..69b17b324e12 --- /dev/null +++ b/Documentation/gpu/tve200.rst @@ -0,0 +1,6 @@ +================================== + drm/tve200 Faraday TV Encoder 200 +================================== + +.. kernel-doc:: drivers/gpu/drm/tve200/tve200_drv.c + :doc: Faraday TV Encoder 200 |