On Thu, 25 Apr 2019 at 05:35, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Wed, Apr 24, 2019 at 11:56:16AM -0700, Eric Anholt wrote: > > 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@xxxxxxxxxx> > > --- > > > > 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. > > Yeah if you end up with a revert on your hands the process failed much > harder and you get to keep the pieces no matter what. Not sure we should > clarify whether you need a stable sha1 or not (helps with cross > referencing uapi header updates), but imo good as is. And matches what > I've been doing/recommending past few years. > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > > 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. I'd rather restrict this to drm-next and drm-misc-next, I frankly don't trust driver trees here to have the review practices in place. I trust drm-misc-next to have at least had someone unrelated look over the new api. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
