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=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 581E5C28CBC for ; Sun, 3 May 2020 15:01:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 31DDC207DD for ; Sun, 3 May 2020 15:01:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728696AbgECPBs (ORCPT ); Sun, 3 May 2020 11:01:48 -0400 Received: from muru.com ([72.249.23.125]:52668 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728002AbgECPBs (ORCPT ); Sun, 3 May 2020 11:01:48 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 5955480BF; Sun, 3 May 2020 15:02:34 +0000 (UTC) Date: Sun, 3 May 2020 08:01:43 -0700 From: Tony Lindgren To: Paul Cercueil Cc: "H. Nikolaus Schaller" , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , =?utf-8?Q?Beno=C3=AEt?= Cousson , Ralf Baechle , Paul Burton , James Hogan , Kukjin Kim , Krzysztof Kozlowski , Maxime Ripard , Chen-Yu Tsai , Thomas Bogendoerfer , Jonathan Bakker , Philipp Rossak , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, openpvrsgx-devgroup@letux.org, letux-kernel@openphoenux.org, kernel@pyra-handheld.com, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs Message-ID: <20200503150143.GG37466@atomide.com> References: <3a451e360fed84bc40287678b4d6be13821cfbc0.1587760454.git.hns@goldelico.com> <28138EC0-0FA5-4F97-B528-3442BF087C7A@goldelico.com> <3D8B59D6-83E3-4FE6-9C99-E2E5616A8139@goldelico.com> <8EER9Q.C206SXNSICP7@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EER9Q.C206SXNSICP7@crapouillou.net> Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org * Paul Cercueil [200503 14:19]: > You have a new SoC with a SGX, and you only need to enable one clock to get > it to work. So you create a devicetree node which receives only one clock. > > Turns out, that the bootloader was enabling the other 3 clocks, and since > the last release, it doesn't anymore. You're left with having to support a > broken devicetree. > > That's the kind of problem that can be easily avoided by enforcing the > number of clocks that have to be provided. The number of clocks depends on how it's wired for the SoC. On omaps, there's are no controls for additinoal SGX clocks. Sure some of the clocks may be routed to multple places internally by the wrapper module. But we have no control over that. If we wanted to specify just the "fck" clock on omaps, then we can do it with something like this: allOf: - if: properites: compatible: enum: - "ti,omap4-sgx544-112" - "ti,omap5-sgx544-116" - "ti,dra7-sgx544-116" then: properties: clocks: minItems: 1 maxItems: 1 clock-names: const: fck required: - clocks - clock-names There's no need for the SGX driver to toggle the "fck" here, it's all done by PM runtime alreaedy so we would be just tweaking the usage count for it. But hey, showing the clock rate might be nice. Or maybe we want to at some point scale it, so no problem specifying it. For omap3, we should then specify "fck" and "ick". On omap4 and later, there's no separate control over the "ick". Then for the other SoCs, you can specify whatever clocks you need there. Regards, Tony 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 1ADC2C28CBC for ; Sun, 3 May 2020 15:01:59 +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 DF030207DD for ; Sun, 3 May 2020 15:01:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IuTiO9kg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF030207DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MMa6ApGF9Xvc7wpNCfY68REdP927uNQiHHPu2QzAN/c=; b=IuTiO9kgCxOv1D TUxMY8u2XInsYPfPQDiQGD7O2tBQzEn3TVF3erYZVy2izhhAzRXu5Qmk6qtjoXlzRSL01Vc69f0Kh avgm4SmNRTfqDol6tuMw4juIXEE2VMpyBXebUn/eULtIblErJKVnsjHd6jkxOE+ITC2U46LyrGKky U5HBs51mE28/Ah0KAllnaLx8Dy53OX71blGNrIMi6MkM4W0XiTOw6Kq7TpgKyDQP9kSWJ98Gr1kRP dQ6+RwsCTDTfEx2DbiXwB/TvsdCVbzyaxZxxz0iGQUP/zGHSvCTV4kUmg5Z/5LcXD/zLKHOSXAhZK FSmuM/Sfj2+OTXAmWIRA==; 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 1jVG7v-00025a-6c; Sun, 03 May 2020 15:01:55 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVG7r-000244-Hn for linux-arm-kernel@lists.infradead.org; Sun, 03 May 2020 15:01:53 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 5955480BF; Sun, 3 May 2020 15:02:34 +0000 (UTC) Date: Sun, 3 May 2020 08:01:43 -0700 From: Tony Lindgren To: Paul Cercueil Subject: Re: [PATCH v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs Message-ID: <20200503150143.GG37466@atomide.com> References: <3a451e360fed84bc40287678b4d6be13821cfbc0.1587760454.git.hns@goldelico.com> <28138EC0-0FA5-4F97-B528-3442BF087C7A@goldelico.com> <3D8B59D6-83E3-4FE6-9C99-E2E5616A8139@goldelico.com> <8EER9Q.C206SXNSICP7@crapouillou.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8EER9Q.C206SXNSICP7@crapouillou.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200503_080151_626894_448BABD8 X-CRM114-Status: GOOD ( 14.78 ) 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 , "H. Nikolaus Schaller" , Jonathan Bakker , dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org, letux-kernel@openphoenux.org, Paul Burton , Krzysztof Kozlowski , linux-samsung-soc@vger.kernel.org, Chen-Yu Tsai , Kukjin Kim , James Hogan , devicetree@vger.kernel.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , Maxime Ripard , Rob Herring , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , Philipp Rossak , openpvrsgx-devgroup@letux.org, linux-kernel@vger.kernel.org, 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 * Paul Cercueil [200503 14:19]: > You have a new SoC with a SGX, and you only need to enable one clock to get > it to work. So you create a devicetree node which receives only one clock. > > Turns out, that the bootloader was enabling the other 3 clocks, and since > the last release, it doesn't anymore. You're left with having to support a > broken devicetree. > > That's the kind of problem that can be easily avoided by enforcing the > number of clocks that have to be provided. The number of clocks depends on how it's wired for the SoC. On omaps, there's are no controls for additinoal SGX clocks. Sure some of the clocks may be routed to multple places internally by the wrapper module. But we have no control over that. If we wanted to specify just the "fck" clock on omaps, then we can do it with something like this: allOf: - if: properites: compatible: enum: - "ti,omap4-sgx544-112" - "ti,omap5-sgx544-116" - "ti,dra7-sgx544-116" then: properties: clocks: minItems: 1 maxItems: 1 clock-names: const: fck required: - clocks - clock-names There's no need for the SGX driver to toggle the "fck" here, it's all done by PM runtime alreaedy so we would be just tweaking the usage count for it. But hey, showing the clock rate might be nice. Or maybe we want to at some point scale it, so no problem specifying it. For omap3, we should then specify "fck" and "ick". On omap4 and later, there's no separate control over the "ick". Then for the other SoCs, you can specify whatever clocks you need there. Regards, Tony _______________________________________________ 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.8 required=3.0 tests=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 4E4CDC47257 for ; Mon, 4 May 2020 07:17:34 +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 0683620721 for ; Mon, 4 May 2020 07:17:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0683620721 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.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 C7A9C6E32B; Mon, 4 May 2020 07:17:20 +0000 (UTC) Received: from muru.com (muru.com [72.249.23.125]) by gabe.freedesktop.org (Postfix) with ESMTP id 607316E255 for ; Sun, 3 May 2020 15:01:49 +0000 (UTC) Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 5955480BF; Sun, 3 May 2020 15:02:34 +0000 (UTC) Date: Sun, 3 May 2020 08:01:43 -0700 From: Tony Lindgren To: Paul Cercueil Subject: Re: [PATCH v7 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs Message-ID: <20200503150143.GG37466@atomide.com> References: <3a451e360fed84bc40287678b4d6be13821cfbc0.1587760454.git.hns@goldelico.com> <28138EC0-0FA5-4F97-B528-3442BF087C7A@goldelico.com> <3D8B59D6-83E3-4FE6-9C99-E2E5616A8139@goldelico.com> <8EER9Q.C206SXNSICP7@crapouillou.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8EER9Q.C206SXNSICP7@crapouillou.net> X-Mailman-Approved-At: Mon, 04 May 2020 07:17:19 +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 , David Airlie , "H. Nikolaus Schaller" , Jonathan Bakker , dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org, letux-kernel@openphoenux.org, Paul Burton , Krzysztof Kozlowski , linux-samsung-soc@vger.kernel.org, Chen-Yu Tsai , Kukjin Kim , James Hogan , devicetree@vger.kernel.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , Rob Herring , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , Philipp Rossak , openpvrsgx-devgroup@letux.org, linux-kernel@vger.kernel.org, Ralf Baechle , kernel@pyra-handheld.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" * Paul Cercueil [200503 14:19]: > You have a new SoC with a SGX, and you only need to enable one clock to get > it to work. So you create a devicetree node which receives only one clock. > > Turns out, that the bootloader was enabling the other 3 clocks, and since > the last release, it doesn't anymore. You're left with having to support a > broken devicetree. > > That's the kind of problem that can be easily avoided by enforcing the > number of clocks that have to be provided. The number of clocks depends on how it's wired for the SoC. On omaps, there's are no controls for additinoal SGX clocks. Sure some of the clocks may be routed to multple places internally by the wrapper module. But we have no control over that. If we wanted to specify just the "fck" clock on omaps, then we can do it with something like this: allOf: - if: properites: compatible: enum: - "ti,omap4-sgx544-112" - "ti,omap5-sgx544-116" - "ti,dra7-sgx544-116" then: properties: clocks: minItems: 1 maxItems: 1 clock-names: const: fck required: - clocks - clock-names There's no need for the SGX driver to toggle the "fck" here, it's all done by PM runtime alreaedy so we would be just tweaking the usage count for it. But hey, showing the clock rate might be nice. Or maybe we want to at some point scale it, so no problem specifying it. For omap3, we should then specify "fck" and "ick". On omap4 and later, there's no separate control over the "ick". Then for the other SoCs, you can specify whatever clocks you need there. Regards, Tony _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel