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 C9CF4C55193 for ; Thu, 23 Apr 2020 15:46:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A74352098B for ; Thu, 23 Apr 2020 15:46:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="DrKJ9fNz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729360AbgDWPqp (ORCPT ); Thu, 23 Apr 2020 11:46:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729176AbgDWPqo (ORCPT ); Thu, 23 Apr 2020 11:46:44 -0400 Received: from mo6-p02-ob.smtp.rzone.de (mo6-p02-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5302::9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F720C09B040; Thu, 23 Apr 2020 08:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587656801; 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=ybxxfVp12h/EJrmfUJdRJSGTmKH3W7lZYEApLFlERWY=; b=DrKJ9fNz8WxLH/lxvzqH+AMSam9tu2FhRn1b+DxbazOFoXyS93+afrGgpwefT4t6QC /4k7b51LsSANcN/xVgHDnGc9MzXErXxCPQeHuiElt1upkXq+nvKp9tSqjV5+k1mBfxS3 gAkvjEQjZJNlc0Yw5yj/hGkMx2dR3nhn+e4WqxPIVEcRt6S9melWvYcV+2h+8m47DJTF K+utEk2anK6Ms4Lb8UzV2Zj3a1+UkWzb9yq/ZlLTRil6UF5EXzHTWRMjAccLpfo3BT1D qJ7BmeYa+eOlmSQs2uTl6iNBaTpywNCpLK63P2AacOcUu0H5TmLKFwDnMPpJpV6cP8ls aO1A== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBp5hRw/qOxWRk4dCysOfl5tOw33QtdTbGcCRJGxnkq3ByzlXOnoXby" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:16b8:2692:1500:61a3:e550:2224:7950] by smtp.strato.de (RZmta 46.6.2 AUTH) with ESMTPSA id R0acebw3NFjv7lw (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); Thu, 23 Apr 2020 17:45:57 +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\)) Content-Type: text/plain; charset=us-ascii From: "H. Nikolaus Schaller" In-Reply-To: <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> Date: Thu, 23 Apr 2020 17:45:55 +0200 Cc: Maxime Ripard , 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" , Daniel Vetter , 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-Transfer-Encoding: quoted-printable Message-Id: <71F2F964-32C7-41E6-8F1A-A73161EA1BB3@goldelico.com> 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> <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> <07923B6C-4CCD-4B81-A98F-E19C43412A89@goldelico.com> <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> To: Neil Armstrong X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Neil, > Am 23.04.2020 um 17:00 schrieb Neil Armstrong = : >> One thing we can learn is that "core" seems to be a de facto standard=20= >> for the core clock-name. An alternative "gpu" is used by = nvidia,gk20a.txt. >=20 > Usually IPs needs a few clocks: > - pclk or apb or reg: the clock clocking the "slave" bus to serve the = registers > - axi or bus or ahb: the bus clocking the the "master" bus to get data = from system memory > - core: the actual clock feeding the GPU logic And the sgx544 seems to have two such clocks. > Sometimes you have a single clock for slave and master bus. >=20 > But you can also have separate clocks for shader cores, .. this = depends on the IP and it's architecture. > The IP can also have memories with separate clocks, etc... Indeed. > But all these clocks can be source by an unique clock on a SoC, but = different on another > SoC, this is why it's important to list them all, even optional. >=20 > You'll certainly have at least a reset signal, and a power domain, = these should exist and be optional. Well, they exist only as hints in block diagrams of some SoC data sheets (so we do not know if they represent the imagination definitions) and = the current driver code doesn't make use of it. Still the gpu core works. So I do not see any urgent need to add a complete list to the bindings = now. Unless some special SoC integration makes use of them. Then it is IMHO = easier to extend the bindings by a follow-up patch than now thinking about all potential options and bloating the bindings with things we (the open = source community) doesn't and can't know. My goal is to keep the bindings as minimalistic as possible. And reset = lines and power domains are (at least for those we have in the works) not = needed to make working systems. Therefore, for clocks I also would start with a minimalistic approach = for a single optional GPU core clock and leave out reset and power = completely. BR and thanks, Nikolaus 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 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 21191C54FCB for ; Thu, 23 Apr 2020 15:46:34 +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 DCE6420781 for ; Thu, 23 Apr 2020 15:46:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KrxJreHN"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="OuYyp3nQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCE6420781 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=XRuZno9gPblbYqiqQPbFu3H+KfdcHRycvHxQ2BtvK64=; b=KrxJreHNnd6caS WAf9qhnefuY2yVZMxuWmAO8TRm7OO+g7YKa2iGbQZhziZUpOm+JtlEqtF22bFm/UdHBxmhAqdiFrC +E7K0yqLs9suAv6ZGhrV0R98KFa6fS+7wNR7w43941r0eLaVHHNyGm0yiRQH1jBTJkKr+J7KPkyvd efzeY3Au1Zm8gAIQw3QQ+8zg3zttrsNi0p5FLvazB8RFIxc9PMIJQuMxldfd5AOka0nyyGOuhjvuO LhgTBFJrbKPmyE1V+NTW6/5Bm67Zb/C6fxSBu8z3pV6u+gPatLnEIzfKDzWvWsMUqvAtHn/4P3Gmy 5/EHScHfu2Rsz7dO2VHw==; 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 1jRe3a-0004Sj-6y; Thu, 23 Apr 2020 15:46:30 +0000 Received: from mo6-p02-ob.smtp.rzone.de ([2a01:238:20a:202:5302::12]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRe3W-0004O3-TF for linux-arm-kernel@lists.infradead.org; Thu, 23 Apr 2020 15:46:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587656775; 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=ybxxfVp12h/EJrmfUJdRJSGTmKH3W7lZYEApLFlERWY=; b=OuYyp3nQxnljd3w+hO5kVajE9K+f4fLEJyCh/FWLDvxPHZHbwhPhS2HJmhnt9Evsb5 JB71HZNSHYW0lVqUyId3X4zcDucDdX/6JEsTB/XXdU94pa1gejJSAq8WiDmvgKkj1itF qS7gu2/xqgcop5COHG/eWwFLXmMi+T5hAadj8UVlH7g6MCYg3plIA3OJvtaZtMDGArij HQKVogBhhXGcUc4ciCivo0W01AnCAoeIGfgJnrtAZfbjx9IwtlNq6s/m2Atfg0UDDAU8 oEP3Cttz5mRuScdlMorSxZEIwzA2nfBjcJolRJpqGMLwPyRqhe24t1XPiPS1NMGVnTsG aZig== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBp5hRw/qOxWRk4dCysOfl5tOw33QtdTbGcCRJGxnkq3ByzlXOnoXby" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:16b8:2692:1500:61a3:e550:2224:7950] by smtp.strato.de (RZmta 46.6.2 AUTH) with ESMTPSA id R0acebw3NFjv7lw (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); Thu, 23 Apr 2020 17:45:57 +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: <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> Date: Thu, 23 Apr 2020 17:45:55 +0200 Message-Id: <71F2F964-32C7-41E6-8F1A-A73161EA1BB3@goldelico.com> 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> <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> <07923B6C-4CCD-4B81-A98F-E19C43412A89@goldelico.com> <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> To: Neil Armstrong X-Mailer: Apple Mail (2.3124) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200423_084627_543433_5A073082 X-CRM114-Status: GOOD ( 13.15 ) 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 , Tony Lindgren , James Hogan , Jonathan Bakker , "open list:DRM PANEL DRIVERS" , Linux Kernel Mailing List , Paul Cercueil , linux-samsung-soc@vger.kernel.org, Paul Burton , Krzysztof Kozlowski , David Airlie , Chen-Yu Tsai , Kukjin Kim , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , Maxime Ripard , linux-omap , arm-soc , Thomas Bogendoerfer , Philipp Rossak , OpenPVRSGX Linux Driver Group , linux-mips@vger.kernel.org, Ralf Baechle , Daniel Vetter , kernel@pyra-handheld.com, Discussions about the Letux Kernel 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 Hi Neil, > Am 23.04.2020 um 17:00 schrieb Neil Armstrong : >> One thing we can learn is that "core" seems to be a de facto standard >> for the core clock-name. An alternative "gpu" is used by nvidia,gk20a.txt. > > Usually IPs needs a few clocks: > - pclk or apb or reg: the clock clocking the "slave" bus to serve the registers > - axi or bus or ahb: the bus clocking the the "master" bus to get data from system memory > - core: the actual clock feeding the GPU logic And the sgx544 seems to have two such clocks. > Sometimes you have a single clock for slave and master bus. > > But you can also have separate clocks for shader cores, .. this depends on the IP and it's architecture. > The IP can also have memories with separate clocks, etc... Indeed. > But all these clocks can be source by an unique clock on a SoC, but different on another > SoC, this is why it's important to list them all, even optional. > > You'll certainly have at least a reset signal, and a power domain, these should exist and be optional. Well, they exist only as hints in block diagrams of some SoC data sheets (so we do not know if they represent the imagination definitions) and the current driver code doesn't make use of it. Still the gpu core works. So I do not see any urgent need to add a complete list to the bindings now. Unless some special SoC integration makes use of them. Then it is IMHO easier to extend the bindings by a follow-up patch than now thinking about all potential options and bloating the bindings with things we (the open source community) doesn't and can't know. My goal is to keep the bindings as minimalistic as possible. And reset lines and power domains are (at least for those we have in the works) not needed to make working systems. Therefore, for clocks I also would start with a minimalistic approach for a single optional GPU core clock and leave out reset and power completely. BR and thanks, Nikolaus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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, 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 5501AC54FCB for ; Thu, 23 Apr 2020 22:52:38 +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 7347E20736 for ; Thu, 23 Apr 2020 22:52:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="X6FvU/DB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7347E20736 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goldelico.com 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 AB1366EA56; Thu, 23 Apr 2020 22:52:14 +0000 (UTC) Received: from mo6-p02-ob.smtp.rzone.de (mo6-p02-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5302::5]) by gabe.freedesktop.org (Postfix) with ESMTPS id D0D146E8F1 for ; Thu, 23 Apr 2020 15:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587656804; 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=ybxxfVp12h/EJrmfUJdRJSGTmKH3W7lZYEApLFlERWY=; b=X6FvU/DBtmsYsWLS0vmyaEkxyhP9m+VEIVCCHmi+QH1En22qd1T7bYRtQezoBZ6QAa 2S0rKR6nfCFeq6Lu5kQBTuL1RotC7ZaD8iLxWNfqqJ+J902bRxsdcnnMngHEpAP4WKtb fZxrgDlPWWEMbrcuVE+H2SKrRABfmMo3v0TR/b4WvEdq22Dtmx2SfJuG/L2KupTm7nZk SKRM2vanuq3GPQ7x5ZfUFJ9jKlrGz6vkBOAHKvoUBWSIA2fN9b81DUsdohEwVdlA65pd FU7q+61m9pDG1zZE1o3wXWgnC+ifr3/I8NwcobgpDjnxA5xDTYozRAqVLGnYc4SEUoqN Qhgw== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBp5hRw/qOxWRk4dCysOfl5tOw33QtdTbGcCRJGxnkq3ByzlXOnoXby" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:16b8:2692:1500:61a3:e550:2224:7950] by smtp.strato.de (RZmta 46.6.2 AUTH) with ESMTPSA id R0acebw3NFjv7lw (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); Thu, 23 Apr 2020 17:45:57 +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: <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> Date: Thu, 23 Apr 2020 17:45:55 +0200 Message-Id: <71F2F964-32C7-41E6-8F1A-A73161EA1BB3@goldelico.com> 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> <20200422151328.2oyqz7gqkbunmd6o@gilmour.lan> <07923B6C-4CCD-4B81-A98F-E19C43412A89@goldelico.com> <43688597-4b99-8f4d-9ad5-548ddff07f52@baylibre.com> To: Neil Armstrong X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Thu, 23 Apr 2020 22:50:35 +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 Kernel Mailing List , Paul Cercueil , linux-samsung-soc@vger.kernel.org, Paul Burton , Krzysztof Kozlowski , David Airlie , Chen-Yu Tsai , Kukjin Kim , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , Maxime Ripard , linux-omap , arm-soc , Thomas Bogendoerfer , Philipp Rossak , OpenPVRSGX Linux Driver Group , linux-mips@vger.kernel.org, Ralf Baechle , kernel@pyra-handheld.com, Discussions about the Letux Kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Neil, > Am 23.04.2020 um 17:00 schrieb Neil Armstrong : >> One thing we can learn is that "core" seems to be a de facto standard >> for the core clock-name. An alternative "gpu" is used by nvidia,gk20a.txt. > > Usually IPs needs a few clocks: > - pclk or apb or reg: the clock clocking the "slave" bus to serve the registers > - axi or bus or ahb: the bus clocking the the "master" bus to get data from system memory > - core: the actual clock feeding the GPU logic And the sgx544 seems to have two such clocks. > Sometimes you have a single clock for slave and master bus. > > But you can also have separate clocks for shader cores, .. this depends on the IP and it's architecture. > The IP can also have memories with separate clocks, etc... Indeed. > But all these clocks can be source by an unique clock on a SoC, but different on another > SoC, this is why it's important to list them all, even optional. > > You'll certainly have at least a reset signal, and a power domain, these should exist and be optional. Well, they exist only as hints in block diagrams of some SoC data sheets (so we do not know if they represent the imagination definitions) and the current driver code doesn't make use of it. Still the gpu core works. So I do not see any urgent need to add a complete list to the bindings now. Unless some special SoC integration makes use of them. Then it is IMHO easier to extend the bindings by a follow-up patch than now thinking about all potential options and bloating the bindings with things we (the open source community) doesn't and can't know. My goal is to keep the bindings as minimalistic as possible. And reset lines and power domains are (at least for those we have in the works) not needed to make working systems. Therefore, for clocks I also would start with a minimalistic approach for a single optional GPU core clock and leave out reset and power completely. BR and thanks, Nikolaus _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel