drm/doc: Allow new UAPI to be used once it's in drm-next/drm-misc-next. (3d42fca0) · Commits · 戴 / test

I was trying to figure out if it was permissible to merge the Mesa side of V3D's CSD support yet while it's in drm-misc-next but not drm-next, and developers on #dri-devel IRC had differing opinions of what the requirement was. v2: Restrict to just drm-next or drm-misc-next on airlied's request. Signed-off-by:

Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190424220638.16222-1-eric@anholt.net Reviewed-by:

Daniel Vetter <daniel.vetter@ffwll.ch>

Documentation/gpu/drm-uapi.rst

+3 −3

Original line number	Diff line number	Diff line
		@@ -92,9 +92,9 @@ leads to a few additional requirements:
		requirements by doing a quick fork.

		- The kernel patch can only be merged after all the above requirements are met,
		but it must be merged before the userspace patches land. uAPI always flows
		from the kernel, doing things the other way round risks divergence of the uAPI
		definitions and header files.
		but it must be merged to either drm-next or drm-misc-next before the
		userspace patches land. uAPI always flows from the kernel, doing things the
		other way round risks divergence of the uAPI definitions and header files.

		These are fairly steep requirements, but have grown out from years of shared
		pain and experience with uAPI added hastily, and almost always regretted about

Admin message