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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 E1FC9C54FCC for ; Tue, 21 Apr 2020 17:30:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 90DE02070B for ; Tue, 21 Apr 2020 17:30:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LC7wkUrl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="Pg9YwJFO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90DE02070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goldelico.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:References:Message-Id:Date: In-Reply-To:From:Mime-Version:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VMHEfIQpDeuCq7/OoN9HN3ckytkkGbGyN5ra/bF1ga4=; b=LC7wkUrlhCrRX4 imUnbmE0TVtilMWryC1D0xyUNknjF8XfBz3HFIEM7I6es+ztpTdOT6yvxkaI6e1ywQ9PwqwxQtoDb 6e7xhG9w39/qjzDIXHNXbCTa+ODbqBJEdg9rcXJ8Mrf1zJR8Ixc/DHDKayi+gsatAEix1BuT+VKX/ Nd3lB6qS9SetjlJtStKfLWG1A3MBjbexGFNwwYuU4q14h/uEsG8+cF9Ga1a0ua/94UGweze/n8Rdb HgqZNsjwVyxp15ZTqGxmBuPOgURkELsLatcMf9p4njji/a0T6nculGToDvUJwk8QpoxOJgNDKVkB5 HqLP0wgh6GkSFqg+Vorw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jQwif-0007Pp-AX; Tue, 21 Apr 2020 17:30:01 +0000 Received: from mo6-p02-ob.smtp.rzone.de ([2a01:238:20a:202:5302::9]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jQwia-0007JL-UI for linux-arm-kernel@lists.infradead.org; Tue, 21 Apr 2020 17:29:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587490184; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=HikqoAbRox/lVm/oJtuVUkcBJdcoi2Fs9oSIyzhVSWA=; b=Pg9YwJFO1TrZc1HoKVLp+KisvfFo3jvR2aZIA2gTrwed5yjlQidnWz22+30HKd7TjZ 3KQi+EJArNdoyYx5JQQpKjZArFZaZNt6xZuMU2PFGnKO2j0eLZUfGSN/P4Ilolqa1u9z y6TvyVljTmg1SFLBUlBFiDN5ADVus0GGfH8fnhOfhJJ3ZDnwY9Wz5GmTAiA5ldxnf3Tm xFYjzEOhQMSlMgYcJgMgTPFLjrxZOvKTqZYjywYkalTKzh1k3IyGx0V/lrHY4tftVNjx 572uwXcSC3hDkutWjYeoyLqCcBKp5Yw5HuuKT1F6xDtpPNPRiPbo+Tstaczz1LXqxhgi vsuw== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw9iZeHmAiw43oXkQ=" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 46.5.0 DYNA|AUTH) with ESMTPSA id g06d2dw3LHTXJfm (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Tue, 21 Apr 2020 19:29:33 +0200 (CEST) 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) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "H. Nikolaus Schaller" In-Reply-To: <20200421141543.GU37466@atomide.com> Date: Tue, 21 Apr 2020 19:29:32 +0200 Message-Id: References: <20200415101008.zxzxca2vlfsefpdv@gilmour.lan> <2E3401F1-A106-4396-8FE6-51CAB72926A4@goldelico.com> <20200415130233.rgn7xrtwqicptke2@gilmour.lan> <10969e64-fe1f-d692-4984-4ba916bd2161@gmail.com> <20200420073842.nx4xb3zqvu23arkc@gilmour.lan> <20200421112129.zjmkmzo3aftksgka@gilmour.lan> <20200421141543.GU37466@atomide.com> To: Tony Lindgren , Maxime Ripard , Philipp Rossak , Jonathan Bakker X-Mailer: Apple Mail (2.3124) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200421_102957_574566_7D6A48A2 X-CRM114-Status: GOOD ( 15.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Airlie , James Hogan , "open list:DRM PANEL DRIVERS" , linux-mips@vger.kernel.org, Paul Cercueil , Discussions about the Letux Kernel , Paul Burton , Krzysztof Kozlowski , linux-samsung-soc@vger.kernel.org, Chen-Yu Tsai , Kukjin Kim , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , linux-omap , arm-soc , Thomas Bogendoerfer , OpenPVRSGX Linux Driver Group , Linux Kernel Mailing List , Ralf Baechle , Daniel Vetter , kernel@pyra-handheld.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org > Am 21.04.2020 um 16:15 schrieb Tony Lindgren : > > * 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. >>> >>> It is basically some bit that verify that the clocks should be enabled or >>> disabled. >> >> No, it can do much more than that. It's a framework to control the SoCs 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. > > Note that on omaps there are actually SoC module specific registers. 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. This indeed seems to be unique with omap. > And there can be multiple devices within a single target module on > omaps. So the extra dts node and device is justified there. > > 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. That is why we need to evaluate what the better strategy is. So we have a) omap which has a custom wrapper around the sgx b) others without, i.e. an empty (or pass-through) wrapper Which one do we make the "standard" and which one the "exception"? What are good reasons for either one? 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). This will likely avoid problems if we find more SoC with yet another scheme how the SGX clocks are wrapped. 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. So instead of an img+omap.yaml and an img+a81.yaml and an img+a31.yaml etc. we have a single img,pvrsgx.yaml and individual wrappers (the omap one already exists as bindings/bus/ti-sysc.txt). The only drawback is that we need this "pass-through" wrapper in DTS and driver code to handle clocks, power etc. The second best solution in my view is to make b) the standard and allow the clock(s) to be optional to cover the omap case. And conditionals are added to properly describe the variance of how the sgx is wrapped/integrated. IMHO this is a decision which can not be easily revised later. It is an architectural decision. So we should base it on strategic goals. > > > Regards, > > Tony > BR and thanks for clarification, Nikolaus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel