Messages in this thread Patch in this message | | | From | Eric Anholt <> | Subject | [PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next. | Date | Wed, 24 Apr 2019 11:56:16 -0700 |
| |
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. Propose a clarification here to see if Dave Airlie agrees.
Signed-off-by: Eric Anholt <eric@anholt.net> ---
Personally, I thought the rule was "has to be in drm-next", but assuming our review processes aren't totally broken, this should be enough.
Documentation/gpu/drm-uapi.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index c9fd23efd957..8e5545dfbf82 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -92,8 +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 + but it **must** be merged to the driver's -next tree (as documented in + MAINTAINERS) **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 -- 2.20.1
| |