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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 49802C55191 for ; Thu, 23 Apr 2020 07:37:03 +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 16DED208E4 for ; Thu, 23 Apr 2020 07:37:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="tbwhr2e9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="bse4Moqz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 16DED208E4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech 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 BD4F96E25D; Thu, 23 Apr 2020 07:36:41 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43EA26EA14 for ; Wed, 22 Apr 2020 15:13:39 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 91DD65800DD; Wed, 22 Apr 2020 11:13:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Apr 2020 11:13:36 -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=fm2; bh=/ftWw9tHlitciumaaug4a1Czrh7 36GE3jEJuWgmD3SY=; b=tbwhr2e9IectRyCHdVrQk9XLSpGKO6zc9jdte3x5eKI sy8rt00KrKw5fVcnWrZz6/Vg/BfNuEhQyZwrlAXZNp/4BLSPEhyHMJrev0eiWq9T PGDheS8Aj9EaKjnj2Rj8abBAktYTjqE3jI+E+JPO0Ef3HjnK+qarV8do007cCviK AqBIbW/exkVD7DfQbAmUZAeH+dHfZgRYLkLddFp+1tNhexzgvILBhSpzgQYUxJMp i0Pk5VGK42WWdThariqK+N3mhnRLknIwjhTWzGNdmp+onIo4tAD/2B0i6IE4tW17 r4eTEIpARnksJO0lhIrwzomO8Zq/VLJ8MGTkYFE7DGw== 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=fm2; bh=/ftWw9 tHlitciumaaug4a1Czrh736GE3jEJuWgmD3SY=; b=bse4Moqzfl9bRZmpeMKwID +adLbBq6TvV7yZkdrsx4H5E6vrYt6vRuT4wmbdHsIwgoZJ2/49MLuCpgJNu7OegP JF6KaANRzn80w0ye3onNFi2jElrQmMu14F3UcUdoBI8XMWWup4zdqsqLAKYLDOGr 34YnDDLkzz6s6/rmKzgk1NbXHNjCiQwN8CJa0zZW30Vixn7wiV31o7eH4AbM5mQi 3RI1mPho3FdOAqAE2JCqcLcX41rPEbvQrYAX68V9w2kdHmZI2Fy0xC3gvWip6DjT 27HC/zTnnYCvHO7L4XCH+Pc0IqmRdinX3cFmc9K1UZUCxEZiE2cmbP5E9hsXjf6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucfkphepledtrd ekledrieekrdejieenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhl fhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id E8B423280068; Wed, 22 Apr 2020 11:13:29 -0400 (EDT) Date: Wed, 22 Apr 2020 17:13:28 +0200 From: Maxime Ripard To: "H. Nikolaus Schaller" Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more) Message-ID: <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> References: <20200415130233.rgn7xrtwqicptke2@gilmour.lan> <10969e64-fe1f-d692-4984-4ba916bd2161@gmail.com> <20200420073842.nx4xb3zqvu23arkc@gilmour.lan> <20200421112129.zjmkmzo3aftksgka@gilmour.lan> <20200421141543.GU37466@atomide.com> <20200422065859.quy6ane5v7vsy5tf@gilmour.lan> <1AA57A0C-48E6-49BB-BB9A-2AAFFB371BCD@goldelico.com> MIME-Version: 1.0 In-Reply-To: <1AA57A0C-48E6-49BB-BB9A-2AAFFB371BCD@goldelico.com> X-Mailman-Approved-At: Thu, 23 Apr 2020 07:36:39 +0000 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: Mark Rutland , Tony Lindgren , James Hogan , Jonathan Bakker , "open list:DRM PANEL DRIVERS" , linux-mips@vger.kernel.org, Paul Cercueil , linux-samsung-soc@vger.kernel.org, Discussions about the Letux Kernel , Paul Burton , Krzysztof Kozlowski , David Airlie , Chen-Yu Tsai , Kukjin Kim , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Rob Herring , linux-omap , arm-soc , Thomas Bogendoerfer , Philipp Rossak , OpenPVRSGX Linux Driver Group , Linux Kernel Mailing List , Ralf Baechle , =?utf-8?Q?Beno=C3=AEt?= Cousson , kernel@pyra-handheld.com Content-Type: multipart/mixed; boundary="===============0924787551==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============0924787551== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rleqzgonq2kd6jcq" Content-Disposition: inline --rleqzgonq2kd6jcq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 22, 2020 at 09:10:57AM +0200, H. Nikolaus Schaller wrote: > > Am 22.04.2020 um 08:58 schrieb Maxime Ripard : > >=20 > > On Tue, Apr 21, 2020 at 07:29:32PM +0200, H. Nikolaus Schaller wrote: > >>=20 > >>> Am 21.04.2020 um 16:15 schrieb Tony Lindgren : > >>>=20 > >>> * Maxime Ripard [200421 11:22]: > >>>> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote: > >>>>> I had a look on genpd and I'm not really sure if that fits. > >>>>>=20 > >>>>> It is basically some bit that verify that the clocks should be enab= led or > >>>>> disabled. > >>>>=20 > >>>> No, it can do much more than that. It's a framework to control the S= oCs power > >>>> domains, so clocks might be a part of it, but most of the time it's = going to be > >>>> about powering up a particular device. > >>>=20 > >>> Note that on omaps there are actually SoC module specific registers. > >>=20 > >> Ah, I see. This is of course a difference that the TI glue logic has > >> its own registers in the same address range as the sgx and this can't > >> be easily handled by a common sgx driver. > >>=20 > >> This indeed seems to be unique with omap. > >>=20 > >>> And there can be multiple devices within a single target module on > >>> omaps. So the extra dts node and device is justified there. > >>>=20 > >>> For other SoCs, the SGX clocks are probably best handled directly > >>> in pvr-drv.c PM runtime functions unless a custom hardware wrapper > >>> with SoC specific registers exists. > >>=20 > >> That is why we need to evaluate what the better strategy is. > >>=20 > >> So we have > >> a) omap which has a custom wrapper around the sgx > >> b) others without, i.e. an empty (or pass-through) wrapper > >>=20 > >> Which one do we make the "standard" and which one the "exception"? > >> What are good reasons for either one? > >>=20 > >>=20 > >> I am currently in strong favour of a) being standard because it > >> makes the pvr-drv.c simpler and really generic (independent of > >> wrapping into any SoC). > >>=20 > >> This will likely avoid problems if we find more SoC with yet another > >> scheme how the SGX clocks are wrapped. > >>=20 > >> It also allows to handle different number of clocks (A31 seems to > >> need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings > >> or making big lists of conditionals. This variance would be handled > >> outside the sgx core bindings and driver. > >=20 > > I disagree. Every other GPU binding and driver is handling that just fi= ne, and > > the SGX is not special in any case here. >=20 > Can you please better explain this? With example or a description > or a proposal? I can't, I don't have any knowledge about this GPU. > I simply do not have your experience with "every other GPU" as you have. > And I admit that I can't read from your statement what we should do > to bring this topic forward. >=20 > So please make a proposal how it should be in your view. If you need some inspiration, I guess you could look at the mali and vivante bindings once you have an idea of what the GPU needs across the SoCs it's integrated in. Maxime --rleqzgonq2kd6jcq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHQEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXqBfGAAKCRDj7w1vZxhR xVRsAPYpkPvaPx/Gv4bZtD3Q7LlR8I4ICX5CAiGURBKX85mvAQCaSeZMVEC2ANUR ZQ5hvxKQcP4oYw7VwmIsM46WtpHQDg== =lYBS -----END PGP SIGNATURE----- --rleqzgonq2kd6jcq-- --===============0924787551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0924787551==--