From patchwork Wed Apr 24 18:56:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Anholt X-Patchwork-Id: 10915481 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BBD7A1575 for ; Wed, 24 Apr 2019 18:56:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AB5D62899C for ; Wed, 24 Apr 2019 18:56:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9FEA728A18; Wed, 24 Apr 2019 18:56:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 4CABE2899C for ; Wed, 24 Apr 2019 18:56:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4890B89151; Wed, 24 Apr 2019 18:56:24 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id DAAAC8913B for ; Wed, 24 Apr 2019 18:56:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by anholt.net (Postfix) with ESMTP id 9736910A3399; Wed, 24 Apr 2019 11:56:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at anholt.net Received: from anholt.net ([127.0.0.1]) by localhost (kingsolver.anholt.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QLcSsQefhvOA; Wed, 24 Apr 2019 11:56:18 -0700 (PDT) Received: from eliezer.anholt.net (localhost [127.0.0.1]) by anholt.net (Postfix) with ESMTP id EA1BF10A33B6; Wed, 24 Apr 2019 11:56:17 -0700 (PDT) Received: by eliezer.anholt.net (Postfix, from userid 1000) id 3C77A2FE3AA9; Wed, 24 Apr 2019 11:56:17 -0700 (PDT) From: Eric Anholt To: dri-devel@lists.freedesktop.org, Dave Airlie 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 Message-Id: <20190424185617.16865-1-eric@anholt.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-kernel@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Daniel Vetter --- 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