Lines Matching +full:required +full:- +full:for +full:- +full:hardware +full:- +full:jobs
9 addition, drivers export device-specific interfaces for use by userspace
10 drivers & device-aware applications through ioctls and sysfs files.
16 Cover generic ioctls and sysfs layout here. We only need high-level
22 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
31 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
34 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
37 .. kernel-doc:: include/drm/drm_auth.h
40 Open-Source Userspace Requirements
44 what the userspace side for new uAPI needs to look like. This section here
48 open-sourced userspace patches, and those patches must be reviewed and ready for
52 hardware, with userspace and kernel by necessity having to work together really
53 closely. The interfaces, for rendering and modesetting, must be extremely wide
55 them for every possible corner case. This in turn makes it really practically
56 infeasible to differentiate between behaviour that's required by userspace, and
66 - The Linux kernel's "no regression" policy holds in practice only for
67 open-source userspace of the DRM subsystem. DRM developers are perfectly fine
68 if closed-source blob drivers in userspace use the same uAPI as the open
73 - Any new userspace interface must have an open-source implementation as
76 The other reason for requiring open-source userspace is uAPI review. Since the
79 both sides. Making sure that the interface indeed covers the use-case fully
82 - The open-source userspace must not be a toy/test application, but the real
87 - The userspace side must be fully reviewed and tested to the standards of that
88 userspace project. For e.g. mesa this means piglit testcases and review on the
90 job done. The userspace-side reviewer should also provide an Acked-by on the
92 sufficiently documented and validated for userspace's consumption.
94 - The userspace patches must be against the canonical upstream, not some vendor
98 - The kernel patch can only be merged after all the above requirements are met,
99 but it **must** be merged to either drm-next or drm-misc-next **before** the
107 Linux kernel's guarantee to keep existing userspace running for 10+ years this
108 is already rather painful for the DRM subsystem, with multiple different uAPIs
109 for the same thing co-existing. If we add a few more complete mistakes into the
117 DRM core provides multiple character-devices for user-space to use.
118 Depending on which device is opened, user-space can perform a different
129 make use of a GPU. But the DRM API required unprivileged clients to
130 authenticate to a DRM-Master prior to getting GPU access. To avoid this
134 Only non-global rendering commands are allowed. If a driver supports
136 capability. If not supported, the primary node must be used for render
141 per device. No ioctls except PRIME-related ioctls will be allowed on
143 nodes are designed to avoid the buffer-leaks, which occur if clients
146 driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
150 With render nodes, user-space can now control access to the render node
151 via basic file-system access-modes. A running graphics server which
153 required. Instead, a client can open the render node and is immediately
159 DRM-Master concept. There is no reason to associate render clients with
160 a DRM-Master as they are independent of any graphics server. Besides,
164 visible to user-space and accessible beyond open-file boundaries, they
167 Device Hot-Unplug
176 user is able to hot-unplug this kind of devices while they are being
178 damage from hot-unplugging a DRM device needs to be limited as much as
193 (or driver-specific ioctls returning driver-specific things), or open()
198 instance for the device that no longer exists. If the same physical
207 The goal raises at least the following requirements for the kernel and
210 Requirements for KMS UAPI
211 -------------------------
213 - KMS connectors must change their status to disconnected.
215 - Legacy modesets and pageflips, and atomic commits, both real and
219 - Pending non-blocking KMS operations deliver the DRM events userspace
222 - open() on a device node whose underlying device has disappeared will
225 - Attempting to create a DRM lease on a disappeared DRM device will
229 Requirements for Render and Cross-Device UAPI
230 ---------------------------------------------
232 - All GPU jobs that can no longer run must have their fences
233 force-signalled to avoid inflicting hangs on userspace.
236 - Some userspace APIs already define what should happen when the device
240 driver-specific ioctls and handling those in userspace drivers, or
243 - dmabuf which point to memory that has disappeared will either fail to
246 below for already imported dmabufs.
248 - Attempting to import a dmabuf to a disappeared device will either fail
252 - open() on a device node whose underlying device has disappeared will
258 Requirements for Memory Maps
259 ----------------------------
266 dmabuf which might be mapped to other devices (cross-device dmabuf
273 for GPU1 and GPU2 from different vendors, and a third handler for
282 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
286 -------------------------------
295 lookup failure, e.g. for unknown GEM buffer object handles, unknown KMS
300 of VRAM". Sometimes also applies to other limited gpu resources used for
308 Returned for an operation that is valid, but needs more privileges.
309 E.g. root-only or much more common, DRM master-only operations return
320 Remote failure, either a hardware transaction (like i2c), but also used
321 when the exporting driver of a shared dma-buf or fence doesn't support a
331 hardware failures are signalled through the "link status" connector
335 Catch-all for anything that is an invalid argument combination which
343 .. kernel-doc:: include/drm/drm_ioctl.h
346 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
349 .. kernel-doc:: drivers/gpu/drm/drm_ioc32.c
355 Testing Requirements for userspace API
356 --------------------------------------
358 New cross-driver userspace interface extensions, like new IOCTL, new KMS
360 should have driver-agnostic testcases in IGT for that feature, if such a test
361 can be reasonably made using IGT for the target hardware.
364 ---------------------------
370 https://gitlab.freedesktop.org/drm/igt-gpu-tools/.
373 --------------------------
375 VKMS is a software-only model of a KMS driver that is useful for testing
376 and for running compositors. VKMS aims to enable a virtual display without
377 the need for a hardware display capability. These characteristics made VKMS
378 a perfect tool for validating the DRM core behavior and also support the
389 It's possible to run the IGT-tests in a VM in two ways:
395 the host machine to run igt-tests. As an example it's used virtme::
397 $ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
399 Run the igt-tests in the guest machine, as example it's ran the 'kms_flip'
402 $ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
405 (-p option); it's created html summary of the tests results and it's saved
406 in the folder "igt-gpu-tools/results"; it's executed only the igt-tests
407 matching the -t option.
410 -------------------
412 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
415 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
419 ---------------
421 .. kernel-doc:: include/drm/drm_debugfs.h
424 .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
430 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
433 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
448 This was only used for user-mode-settind drivers around modesetting
452 call this any more since with kernel mode setting it is a no-op.
457 .. kernel-doc:: include/uapi/drm/drm_mode.h
460 .. kernel-doc:: include/uapi/drm/drm_mode.h