lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next.
Date
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
\
 
 \ /
  Last update: 2019-04-24 20:57    [W:0.115 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site