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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 A05F7C07E96 for ; Tue, 6 Jul 2021 16:42:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 855FA61C4B for ; Tue, 6 Jul 2021 16:42:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229730AbhGFQpb (ORCPT ); Tue, 6 Jul 2021 12:45:31 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:53549 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229770AbhGFQpb (ORCPT ); Tue, 6 Jul 2021 12:45:31 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id ED38358067B; Tue, 6 Jul 2021 12:42:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 06 Jul 2021 12:42:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=W6MiHashvxzD/kAAuIZVKo84DZ9 qBLQd+rtHQpbZp+k=; b=WSiVy/c9f09jEvWIJfqbqBgsWevGwvK9n2/rTMHB+vE JpHiqjtrBRvzPD1hT/djwShgO3S8n3ETfRxJMJnH4Ezn/vnuLLkZmixLZOiWOe50 UsZfDmbDnjOiWV/JGEDOpj1idsuG9rp7XyzyawWnZCmv1Fes1wjCutLqze5IABej BGySBCMNVSFsEH2TzuhhHmUvk5abdWS7LjmWqdzAGkWPLuvTeI/Nams/ip9gGmQD 1uNh7A+xok91QJKn10j+vyb9UwgyNPyR/1hS3AOM0KBV15aKTYeWopFcQbzAczGw MkDDSSKR4aOusL9d+yn4cb5qAfymx+ceaepIm5P8STg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=W6MiHa shvxzD/kAAuIZVKo84DZ9qBLQd+rtHQpbZp+k=; b=g/Flbq0X6XVSy4U3baetcW Az1gWDb13P3UX3yuHGec9m/IMVQTu041WErhz5XoApUwwvQPL3i1unCWoYQqgYKa HOnsSZ7e35fTbeXyK8/rs+ZKShIe38EpzawhU7xE2MtYsBIv+Aprt5arcuW8qnpa ++mEwRNM5fCuTWIWp6bNnR0MQ5objpoO7xOC+XRIWvaSALNYBPAkkPF1jXtgpoLL gRrQeypbi0dkWxxsITPg+SURmzFC4ekq7sRw9ngK7JeI1IMz20cV0unmwV+UAzVI esK8Qd+4ZVxJNR70OB0zfp4iJSHEcfD5IAAwnxUu/LUZu48y1vOLaI+3OAZ641Cg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddtgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeelkeeghefhuddtleejgfeljeffheffgfeijefhgfeufefhtdevteegheeiheeg udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg igihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jul 2021 12:42:44 -0400 (EDT) Date: Tue, 6 Jul 2021 18:42:41 +0200 From: Maxime Ripard To: Pekka Paalanen Cc: 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 =?utf-8?Q?Tr=C3=B8nnes?= , 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 , Joel Stanley , Alyssa Rosenzweig , Chun-Kuang Hu , Jonas Karlman , Chen Feng , Alison Wang , Rodrigo Vivi , Tomeu Vizoso , Tomi Valkeinen , Kieran Bingham , Tian Tao , Shawn Guo , Christian =?utf-8?B?S8O2bmln?= , 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 , Pekka Paalanen , Yannick Fertre , Nicolas Ferre , Robert Foss , Rob Clark , Qiang Yu , Jyri Sarha Subject: Re: [PATCH v4] Documentation: gpu: Mention the requirements for new properties Message-ID: <20210706164241.ghd56546murmwnit@gilmour> References: <20210616143842.632829-1-maxime@cerno.tech> <20210617112036.7373fdab@eldfell> <20210706085202.6o4fapfmq7osj5wf@gilmour> <20210706123723.6194abc5@eldfell> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6mnf4r7jxmdwlw7k" Content-Disposition: inline In-Reply-To: <20210706123723.6194abc5@eldfell> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org --6mnf4r7jxmdwlw7k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2021 at 12:37:23PM +0300, Pekka Paalanen wrote: > > > > +- It must provide a generic helper in the core code to register th= at > > > > + property on the object it attaches to. > > > > + > > > > +- Its content must be decoded by the core and provided in the obje= ct's > > > > + associated state structure. That includes anything drivers might= want to > > > > + precompute, like :c:type:`struct drm_clip_rect ` = for planes. > > > > + > > > > +- An IGT test must be submitted where reasonable. =20 > > >=20 > > > Would it be too much to replace "where reasonable" with "if it is at > > > all possible to write a test."? > > > =20 > > > > + =20 > > >=20 > > > How about adding the following somewhere? > > >=20 > > > - The initial state of the property (set during driver initialization) > > > must match how the driver+hardware behaved before introducing this > > > property. It may be some fixed value or it may be inherited from e.= g. > > > the firmware that booted the system. How the initial state is > > > determined must also be documented, that is, where does it come fro= m. > > >=20 > > > The initial state must not be called "default", because I want to > > > reserve the term default for something else if possible: the phrase > > > "reset everything to defaults", which is a whole another discussion. = =20 > >=20 > > I've taken into account your previous comments, thanks > >=20 > > > How about also saying that fbcon/fbdev must set this property when > > > taking over? That sounds to be like a common omission leading to funky > > > KMS state in fbcon. The value fbdev sets it to only needs to make > > > sense to fbdev, and it does not need to be ~~the initial value~~ nor = the > > > default value. Or are we hoping to kill fbcon in favor of a userspace > > > kmscon soon? ;-) > > >=20 > > > Ooh, maybe the KMS property documentation should also say what value > > > fbdev will set the property to. That's kind of UABI, because userspace > > > probably implicitly relies on it in many cases. ...which means fbdev > > > should set the property to its initial value, otherwise userspace will > > > break. =20 > >=20 > > I'm not sure about this one: fbdev and fbcon are still optional features > > of the kernel and can be disabled at the user discretion. Having any > > part of the user-space rely on the fbdev behavior seems a bit broken, > > especially when we have a mechanism to retrieve the state when the > > application starts. >=20 > yes, exactly that is why fbdev/fbcon should reset the properties to > their initial values. You would not want userspace inheriting a > different KMS state with vs. without fbcon when it starts. I'm not sure I'm following you when fbdev/fbcon should reset these properties. When a master takes over? If we consider fbdev as any KMS client, isn't it a fundamental change with how it's currently done? I haven't seen anywhere that a compositor (or any client for that matter) should put the KMS device in the same state that it started it with. In case of a crash it would be fairly difficult to achieve. > Retrieving the current KMS state is useless if the current KMS state is > somehow wonky and the application does not understand that specific KMS > property that is wonky. It cannot set the property to any value other > than it already had without user intervention. Yeah, that's true. But the same could be said if you switch from one client to the other for example, at the moment there's no guarantee that the first one didn't change a property to a value you don't expect in the second. Unless we manage to tie that somehow to a first open of the device? > I'd say fbcon causing all KMS state to be reset is a quality of life > thing. It's possible to live without by rebooting, but it would > certainly make at least developers' and testers' life easier until we > get the real "reset KMS" knob (which fbcon could then use too). >=20 > Besides, even if it is broken for userspace to rely on the KMS state > set by fbcon/fbdev, userspace is already doing that and not on purpose > because new KMS properties get added in the kernel. I would bet that > there is not a single userspace program that would actually set all KMS > properties that drivers might expose. So they are depending on > inherited KMS state, which could be left by driver initialization, by > fbdev/fbcon, or by any other userspace. >=20 > But yeah, this idea is something new, so don't let this discussion > delay landing the docs. Ack, I've sent a new version Thanks! Maxime --6mnf4r7jxmdwlw7k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYOSIAQAKCRDj7w1vZxhR xeGIAQDQjE0uYmon9Dox/R5r6J52+sVxI4/gu/mKcrS9FvJK+AEA4LtY+76pkQ6H mgjpDIZUwacg76LQhv7Lzl+/nCA0/ww= =XDM3 -----END PGP SIGNATURE----- --6mnf4r7jxmdwlw7k--