From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B5F7C07E9C for ; Mon, 12 Jul 2021 14:07:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D824B6108B for ; Mon, 12 Jul 2021 14:07:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230297AbhGLOKD (ORCPT ); Mon, 12 Jul 2021 10:10:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229644AbhGLOKC (ORCPT ); Mon, 12 Jul 2021 10:10:02 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 137D4C0613DD for ; Mon, 12 Jul 2021 07:07:14 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id l18-20020a1ced120000b029014c1adff1edso14543606wmh.4 for ; Mon, 12 Jul 2021 07:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=p7O4W5ky1oF7WdmqJH+sNkwA4ZCHs3/ZBm2AUZnthH8=; b=bKzUAQ6xjNseA7AUiDYdS+w5UuiI11E4CeNvb2HJ9Pc/hfPFm/JUB/FjdwhBc8nm4S 45OH9TOmRE8tI1R8nxEhMnt4mekfggAeX7EltWSurlpYmCl7Y46INFsx5E38MJVPpVWF l2YfzMuoZrcwWEWijxDErR65YllGV0b+w14fY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p7O4W5ky1oF7WdmqJH+sNkwA4ZCHs3/ZBm2AUZnthH8=; b=gwwIRZIVEfEpb7JVdTrp7eWlzOvqZOVKXmpQTsMFD5eaQo3REjzbqiQ++fzs5aryE2 GSpcOQyB4PVEmL7qEhlACl9B5JIWzfiVMOeJbGp4aPCY1kZPDydISb+1jVhffgSzo/Hr efMCN8WAzxM9kgZqSi+PkPGzNpqTuCKF9CDb1yFzP8pqn9KbaaVJlFd33z1MQZoQ7yhp n3aVIhfOeEvVzco/tCXGpCiWeLizIn861IgOeN2Hyw7WCUIspMtMYv5246DYxFcHFOZ5 C8WzQg7z4IRmlaM2hSzVEto7ON6nU+JTJ0t+2TIcrSMbn6buNXQtnCbZYF9wG4RglETX B4Aw== X-Gm-Message-State: AOAM530DcSZPV2OjWSpPIqomZQ4yktXL2D/PxrqAau4BRuuABHPFBMUi ZllLY297FUCDYKlLR9w8Xce6Cw== X-Google-Smtp-Source: ABdhPJxsIIrVDoTSmPw1PCAUwck5pZdw90XD3rtLgMAMsu1UL3vl+6tligSn0f4n3yfVZMnbpQldLg== X-Received: by 2002:a05:600c:cf:: with SMTP id u15mr14628294wmm.92.1626098832590; Mon, 12 Jul 2021 07:07:12 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id u2sm12288273wmc.42.2021.07.12.07.07.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 07:07:11 -0700 (PDT) Date: Mon, 12 Jul 2021 16:07:07 +0200 From: Daniel Vetter To: Pekka Paalanen Cc: Daniel Vetter , Maxime Ripard , dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Maarten Lankhorst , Thomas Zimmermann , Xinliang Liu , Anitha Chrisanthus , Jonathan Hunter , Jerome Brunet , Kevin Hilman , Ludovic Desroches , NXP Linux Team , Sascha Hauer , Roland Scheidegger , Sean Paul , Hyun Kwon , Andrew Jeffery , Seung-Woo Kim , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Pengutronix Kernel Team , Alex Deucher , Laurent Pinchart , Alexandre Belloni , linux-doc@vger.kernel.org, Edmund Dea , Eric Anholt , Thierry Reding , Krzysztof Kozlowski , Steven Price , VMware Graphics , Ben Skeggs , Martin Blumenstingl , Rodrigo Siqueira , Boris Brezillon , Sandy Huang , Kyungmin Park , Maxime Coquelin , Haneen Mohammed , Neil Armstrong , Melissa Wen , Gerd Hoffmann , Benjamin Gaignard , Sam Ravnborg , Jonathan Corbet , Xinwei Kong , Chen-Yu Tsai , Alyssa Rosenzweig , Chun-Kuang Hu , Jonas Karlman , Chen Feng , Alison Wang , Rodrigo Vivi , Tomeu Vizoso , Tomi Valkeinen , Kieran Bingham , Tian Tao , Shawn Guo , Christian =?iso-8859-1?Q?K=F6nig?= , Daniel Vetter , Liviu Dudau , Alexandre Torgue , Paul Cercueil , Andrzej Hajda , Huang Rui , Marek Vasut , Joonyoung Shim , Oleksandr Andrushchenko , Russell King , Philippe Cornu , Hans de Goede , Matthias Brugger , Jernej Skrabec , Yannick Fertre , Nicolas Ferre , Robert Foss , Qiang Yu , Jyri Sarha Subject: Re: [PATCH v5] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210706161244.1038592-1-maxime@cerno.tech> <20210709102444.7a72a029@eldfell> <20210709120814.48a90aa1@eldfell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210709120814.48a90aa1@eldfell> X-Operating-System: Linux phenom 5.10.0-7-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Jul 09, 2021 at 12:08:14PM +0300, Pekka Paalanen wrote: > On Fri, 9 Jul 2021 10:02:28 +0200 > Daniel Vetter wrote: > > > On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote: > > > On Tue, 6 Jul 2021 18:12:44 +0200 > > > Maxime Ripard wrote: > > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > > driver from running their own, inconsistent, set of properties, > > > > eventually leading to issues like property conflicts, inconsistencies > > > > between drivers and semantics, etc. > > > > > > > > Let's document what we expect. > > > > > > ... > > > > > > > Changes from v4: > > > > - Changes suggested by Pekka > > > > > > > > Changes from v3: > > > > - Roll back to the v2 > > > > - Add Simon and Pekka in Cc > > > > > > > > Changes from v2: > > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > > force generic properties, but prefix vendor-specific properties with > > > > the vendor name > > > > > > > > Changes from v1: > > > > - Typos and wording reported by Daniel and Alex > > > > --- > > > > Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ > > > > 1 file changed, 30 insertions(+) > > > > > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > > > index 87e5023e3f55..47994890fd1e 100644 > > > > --- a/Documentation/gpu/drm-kms.rst > > > > +++ b/Documentation/gpu/drm-kms.rst > > > > @@ -463,6 +463,36 @@ KMS Properties > > > > This section of the documentation is primarily aimed at user-space developers. > > > > For the driver APIs, see the other sections. > > > > > > > > +Requirements > > > > +------------ > > > > + > > > > +KMS drivers might need to add extra properties to support new features. > > > > +Each new property introduced in a driver need to meet a few > > > > +requirements, in addition to the one mentioned above: > > > > + > > > > +* It must be standardized, documenting: > > > > + > > > > + * The full, exact, name string; > > > > + * If the property is an enum, all the valid variants name; > > > > > > Hi, > > > > > > "variant" feels a little off to me, I would have used "value name > > > strings". > > > > > > > + * What values are accepted, and what these values mean; > > > > + * What the property does and how it can be used; > > > > + * How the property might interact with other, existing properties. > > > > + > > > > +* It must provide a generic helper in the core code to register that > > > > + property on the object it attaches to. > > > > + > > > > +* Its content must be decoded by the core and provided in the object's > > > > + associated state structure. That includes anything drivers might want > > > > + to precompute, like :c:type:`struct drm_clip_rect ` for > > > > + planes. > > > > + > > > > +* Its initial state must match the behavior prior to the property > > > > + introduction. This might be a fixed value matching what the hardware > > > > + does, or it may be inherited from the state the firmware left the > > > > + system in during boot. > > > > > > I'd like to point out that this rule should apply also to > > > properties that already exist in general, but are newly exposed in a > > > driver for hardware that didn't expose the property before. > > > > I think we should just make this a very strong recommendation, and in > > general encourage people to use the tests against their driver? > > > > Otherwise a small "I'll just enable this" thing can become a huge project. > > And in general I think grandfathering existing things in is the pragmatic > > choice. > > > > But maybe that could be a follow-up patch? > > Sure, I don't mind. Just saying now that it came to mind. Drivers do > not arbitrarily change behaviour without exposing more properties > either, right? Yup. Both are covered under the "no regressions" rule, but better to make this explicit. Maybe we should replicate some of the key bits in the property docs for drivers? Also anytime we spot an issue we need to improve the internal helpers to make sure things stay consistent. -Daniel > > > Thanks, > pq > > > > -Daniel > > > > > > > > > + > > > > +* An IGT test must be submitted where reasonable. > > > > + > > > > Property Types and Blob Property Support > > > > ---------------------------------------- > > > > > > > > > > Regardless of my comments above: > > > > > > Reviewed-by: Pekka Paalanen > > > > > > > > > Thanks, > > > pq > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF622C07E99 for ; Mon, 12 Jul 2021 14:07:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6DDA56101D for ; Mon, 12 Jul 2021 14:07:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6DDA56101D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D675C89C03; Mon, 12 Jul 2021 14:07:14 +0000 (UTC) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0850689C03 for ; Mon, 12 Jul 2021 14:07:13 +0000 (UTC) Received: by mail-wm1-x32c.google.com with SMTP id a5-20020a7bc1c50000b02901e3bbe0939bso106283wmj.0 for ; Mon, 12 Jul 2021 07:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=p7O4W5ky1oF7WdmqJH+sNkwA4ZCHs3/ZBm2AUZnthH8=; b=bKzUAQ6xjNseA7AUiDYdS+w5UuiI11E4CeNvb2HJ9Pc/hfPFm/JUB/FjdwhBc8nm4S 45OH9TOmRE8tI1R8nxEhMnt4mekfggAeX7EltWSurlpYmCl7Y46INFsx5E38MJVPpVWF l2YfzMuoZrcwWEWijxDErR65YllGV0b+w14fY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p7O4W5ky1oF7WdmqJH+sNkwA4ZCHs3/ZBm2AUZnthH8=; b=PHAhro2iyU+ma7Jjfp/zmPMv+xqPqOAZmKS4RBChRIIHCXm+RcczLWiFeQXxa1eKtD 9Y692lTtW6lPgMgnt8TaPni//2/1vopY0uC18fJkIHlI3K1ACOa3t3OlbohPQP8eZYSX j/IxQ0WGe9xcUrY5QjWoJuOEkaNUA0eJ/JV10YKyPmF7dvtXDbziyTAv/jredcSoGfPM e2fmKKO0x349uufl3uNA7Thdgpf5+vbQU1qHXTXNaZEa6cYtuhMW8+AC4alZNodfMDLZ ArB0LmgiIquCbV6fIH4e1G0nJlzyGriDbOba7R0D1sVvvWM90oCFNZEGQyHNWyjnfsMU Rw0w== X-Gm-Message-State: AOAM533adxAuUKvXSENb2es45SC8AoaSE1xP+83lMj1M/KMTazTAH2LA 5ivjYZOhlp6IsfGZtNMdd6h9vQ== X-Google-Smtp-Source: ABdhPJxsIIrVDoTSmPw1PCAUwck5pZdw90XD3rtLgMAMsu1UL3vl+6tligSn0f4n3yfVZMnbpQldLg== X-Received: by 2002:a05:600c:cf:: with SMTP id u15mr14628294wmm.92.1626098832590; Mon, 12 Jul 2021 07:07:12 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id u2sm12288273wmc.42.2021.07.12.07.07.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 07:07:11 -0700 (PDT) Date: Mon, 12 Jul 2021 16:07:07 +0200 From: Daniel Vetter To: Pekka Paalanen Subject: Re: [PATCH v5] Documentation: gpu: Mention the requirements for new properties Message-ID: References: <20210706161244.1038592-1-maxime@cerno.tech> <20210709102444.7a72a029@eldfell> <20210709120814.48a90aa1@eldfell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210709120814.48a90aa1@eldfell> X-Operating-System: Linux phenom 5.10.0-7-amd64 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Haneen Mohammed , Alexandre Belloni , linux-doc@vger.kernel.org, David Airlie , Daniel Vetter , Edmund Dea , Alexandre Torgue , dri-devel@lists.freedesktop.org, Russell King , Melissa Wen , Eric Anholt , Thierry Reding , Laurent Pinchart , Benjamin Gaignard , Anitha Chrisanthus , Daniel Vetter , Steven Price , Sam Ravnborg , Jyri Sarha , Jerome Brunet , Paul Cercueil , Marek Vasut , Joonyoung Shim , Qiang Yu , Krzysztof Kozlowski , Kevin Hilman , Tomi Valkeinen , Neil Armstrong , Alyssa Rosenzweig , Xinwei Kong , Jonathan Hunter , Xinliang Liu , Ludovic Desroches , Kieran Bingham , VMware Graphics , NXP Linux Team , Chen Feng , Liviu Dudau , Ben Skeggs , Chun-Kuang Hu , Jonas Karlman , Martin Blumenstingl , Roland Scheidegger , Sascha Hauer , Alison Wang , Andrzej Hajda , Hans de Goede , Maxime Ripard , Rodrigo Vivi , Matthias Brugger , Nicolas Ferre , Chen-Yu Tsai , Sean Paul , Pengutronix Kernel Team , Maxime Coquelin , Jernej Skrabec , Rodrigo Siqueira , Hyun Kwon , Boris Brezillon , Andrew Jeffery , Huang Rui , Yannick Fertre , Jonathan Corbet , Seung-Woo Kim , Sandy Huang , Robert Foss , Tomeu Vizoso , Kyungmin Park , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Philippe Cornu , Thomas Zimmermann , Alex Deucher , Tian Tao , Oleksandr Andrushchenko , Shawn Guo , Christian =?iso-8859-1?Q?K=F6nig?= , Gerd Hoffmann Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jul 09, 2021 at 12:08:14PM +0300, Pekka Paalanen wrote: > On Fri, 9 Jul 2021 10:02:28 +0200 > Daniel Vetter wrote: > > > On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote: > > > On Tue, 6 Jul 2021 18:12:44 +0200 > > > Maxime Ripard wrote: > > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > > driver from running their own, inconsistent, set of properties, > > > > eventually leading to issues like property conflicts, inconsistencies > > > > between drivers and semantics, etc. > > > > > > > > Let's document what we expect. > > > > > > ... > > > > > > > Changes from v4: > > > > - Changes suggested by Pekka > > > > > > > > Changes from v3: > > > > - Roll back to the v2 > > > > - Add Simon and Pekka in Cc > > > > > > > > Changes from v2: > > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > > force generic properties, but prefix vendor-specific properties with > > > > the vendor name > > > > > > > > Changes from v1: > > > > - Typos and wording reported by Daniel and Alex > > > > --- > > > > Documentation/gpu/drm-kms.rst | 30 ++++++++++++++++++++++++++++++ > > > > 1 file changed, 30 insertions(+) > > > > > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > > > index 87e5023e3f55..47994890fd1e 100644 > > > > --- a/Documentation/gpu/drm-kms.rst > > > > +++ b/Documentation/gpu/drm-kms.rst > > > > @@ -463,6 +463,36 @@ KMS Properties > > > > This section of the documentation is primarily aimed at user-space developers. > > > > For the driver APIs, see the other sections. > > > > > > > > +Requirements > > > > +------------ > > > > + > > > > +KMS drivers might need to add extra properties to support new features. > > > > +Each new property introduced in a driver need to meet a few > > > > +requirements, in addition to the one mentioned above: > > > > + > > > > +* It must be standardized, documenting: > > > > + > > > > + * The full, exact, name string; > > > > + * If the property is an enum, all the valid variants name; > > > > > > Hi, > > > > > > "variant" feels a little off to me, I would have used "value name > > > strings". > > > > > > > + * What values are accepted, and what these values mean; > > > > + * What the property does and how it can be used; > > > > + * How the property might interact with other, existing properties. > > > > + > > > > +* It must provide a generic helper in the core code to register that > > > > + property on the object it attaches to. > > > > + > > > > +* Its content must be decoded by the core and provided in the object's > > > > + associated state structure. That includes anything drivers might want > > > > + to precompute, like :c:type:`struct drm_clip_rect ` for > > > > + planes. > > > > + > > > > +* Its initial state must match the behavior prior to the property > > > > + introduction. This might be a fixed value matching what the hardware > > > > + does, or it may be inherited from the state the firmware left the > > > > + system in during boot. > > > > > > I'd like to point out that this rule should apply also to > > > properties that already exist in general, but are newly exposed in a > > > driver for hardware that didn't expose the property before. > > > > I think we should just make this a very strong recommendation, and in > > general encourage people to use the tests against their driver? > > > > Otherwise a small "I'll just enable this" thing can become a huge project. > > And in general I think grandfathering existing things in is the pragmatic > > choice. > > > > But maybe that could be a follow-up patch? > > Sure, I don't mind. Just saying now that it came to mind. Drivers do > not arbitrarily change behaviour without exposing more properties > either, right? Yup. Both are covered under the "no regressions" rule, but better to make this explicit. Maybe we should replicate some of the key bits in the property docs for drivers? Also anytime we spot an issue we need to improve the internal helpers to make sure things stay consistent. -Daniel > > > Thanks, > pq > > > > -Daniel > > > > > > > > > + > > > > +* An IGT test must be submitted where reasonable. > > > > + > > > > Property Types and Blob Property Support > > > > ---------------------------------------- > > > > > > > > > > Regardless of my comments above: > > > > > > Reviewed-by: Pekka Paalanen > > > > > > > > > Thanks, > > > pq > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch