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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 63932C33CA3 for ; Fri, 10 Jan 2020 11:40:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 437252077C for ; Fri, 10 Jan 2020 11:40:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727859AbgAJLkA (ORCPT ); Fri, 10 Jan 2020 06:40:00 -0500 Received: from foss.arm.com ([217.140.110.172]:42862 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727812AbgAJLkA (ORCPT ); Fri, 10 Jan 2020 06:40:00 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75FAF1063; Fri, 10 Jan 2020 03:39:59 -0800 (PST) Received: from [10.1.194.52] (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29DAA3F534; Fri, 10 Jan 2020 03:39:57 -0800 (PST) Subject: Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU To: Rob Herring , Nicolas Boichat Cc: Mark Rutland , Devicetree List , Tomeu Vizoso , David Airlie , lkml , Liam Girdwood , dri-devel , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Daniel Vetter , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-5-drinkcat@chromium.org> <20200108132302.GA3817@sirena.org.uk> From: Steven Price Message-ID: Date: Fri, 10 Jan 2020 11:39:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/01/2020 16:56, Rob Herring wrote: > On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote: >> >> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: >>> >>> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: >>> >>>> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second >>>> regulator for their SRAM, let's add support for that. >>> >>>> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram"); >>>> + if (IS_ERR(pfdev->regulator_sram)) { >>> >>> This supply is required for the devices that need it so I'd therefore >>> expect the driver to request the supply non-optionally based on the >>> compatible string rather than just hoping that a missing regulator isn't >>> important. >> >> That'd be a bit awkward to match, though... Currently all bifrost >> share the same compatible "arm,mali-bifrost", and it'd seem >> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no >> idea if any other Mali implementation will require a second regulator, >> but with the MT8183 we do need it, see below. > > The current number of supported bifrost platforms is 0. It's only a > matter of time until SoC specific compatibles need to be used in the > driver. This is why we require them. > > It could very well be that all bifrost implementations need 2 > supplies. On chip RAMs are very frequently a separate thing which are > synthesized differently from logic. At least within a specific IP > model, I somewhat doubt there's a variable number of supplies. It > could be possible to connect both to the same supply, but the correct > way to handle that is both -supply properties point to the same > regulator. To be honest I've no idea what different SoC designs have done, but one of the intentions of core stacks was that sets of GPU cores would be on different power supplies. (I think this is to avoid issues with inrush current etc, but I'm not a hardware engineer). So I would expect designs with a large number of cores to have more physical supplies than designs with fewer cores. However, from a driver perspective this is all meant to be hidden by the hardware PDC which the GPU talks to. So the actual power up/down of the supplies may be completely automatic and therefore not described in the DT. So the actual number of software-controllable supplies could be 1 or could be more if the individual physical supplies are visible to software. The Hikey960 for instance hides everything behind a mailbox interface, and it's simply a case of requesting a frequency. Steve 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 B5E0FC33CA2 for ; Fri, 10 Jan 2020 11:40:23 +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 8901D2077C for ; Fri, 10 Jan 2020 11:40:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EKZtfbwz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8901D2077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=h7n+l4/hNztKX5dWO+q9oRRTTDcqufZVp0vCLh6dEIw=; b=EKZtfbwzazwr0W 0GwDtkFVGxPsG7q0U7e1Gp2PWGYt3MQm4ouYA3qSXsP7TyF36Qrg4iLE50pBpCX1Jtk3w2MfarlG/ OPjNV0phLySzL7Xkuu6lsJrhoIH1CCFAz2Re6vNSTHsIZKp/QMeBTiJuQYkWA8xRcKY4UpLfo+Xe5 CWRECnKlBfwHIVfceEkrY/i7boYERHf8RQOlS3BmE8aR4u9Q6TLKY5KizAEStLFqvrWLWzcN3gPF7 G7cyDuc1o8YoeUrO318kRRRYslScfy7uRuBfaebSz3dCAMVlv5i9nY9Hiqps0HQl0jA438NMRrq0C Kr9nLhYvZD7yh95OuWmg==; 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 1ipseF-0001J4-Oq; Fri, 10 Jan 2020 11:40:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipse0-0008Nr-Hj; Fri, 10 Jan 2020 11:40:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75FAF1063; Fri, 10 Jan 2020 03:39:59 -0800 (PST) Received: from [10.1.194.52] (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29DAA3F534; Fri, 10 Jan 2020 03:39:57 -0800 (PST) Subject: Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU To: Rob Herring , Nicolas Boichat References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-5-drinkcat@chromium.org> <20200108132302.GA3817@sirena.org.uk> From: Steven Price Message-ID: Date: Fri, 10 Jan 2020 11:39:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200110_034000_673587_41A30A8F X-CRM114-Status: GOOD ( 19.16 ) X-BeenThere: linux-mediatek@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 , Devicetree List , Tomeu Vizoso , David Airlie , lkml , dri-devel , Liam Girdwood , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Daniel Vetter , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On 09/01/2020 16:56, Rob Herring wrote: > On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote: >> >> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: >>> >>> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: >>> >>>> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second >>>> regulator for their SRAM, let's add support for that. >>> >>>> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram"); >>>> + if (IS_ERR(pfdev->regulator_sram)) { >>> >>> This supply is required for the devices that need it so I'd therefore >>> expect the driver to request the supply non-optionally based on the >>> compatible string rather than just hoping that a missing regulator isn't >>> important. >> >> That'd be a bit awkward to match, though... Currently all bifrost >> share the same compatible "arm,mali-bifrost", and it'd seem >> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no >> idea if any other Mali implementation will require a second regulator, >> but with the MT8183 we do need it, see below. > > The current number of supported bifrost platforms is 0. It's only a > matter of time until SoC specific compatibles need to be used in the > driver. This is why we require them. > > It could very well be that all bifrost implementations need 2 > supplies. On chip RAMs are very frequently a separate thing which are > synthesized differently from logic. At least within a specific IP > model, I somewhat doubt there's a variable number of supplies. It > could be possible to connect both to the same supply, but the correct > way to handle that is both -supply properties point to the same > regulator. To be honest I've no idea what different SoC designs have done, but one of the intentions of core stacks was that sets of GPU cores would be on different power supplies. (I think this is to avoid issues with inrush current etc, but I'm not a hardware engineer). So I would expect designs with a large number of cores to have more physical supplies than designs with fewer cores. However, from a driver perspective this is all meant to be hidden by the hardware PDC which the GPU talks to. So the actual power up/down of the supplies may be completely automatic and therefore not described in the DT. So the actual number of software-controllable supplies could be 1 or could be more if the individual physical supplies are visible to software. The Hikey960 for instance hides everything behind a mailbox interface, and it's simply a case of requesting a frequency. Steve _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 91B84C33CA2 for ; Fri, 10 Jan 2020 11:40: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 525952077C for ; Fri, 10 Jan 2020 11:40: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="rRSddNM0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 525952077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZbC9Qx2ySAU1ZJWTefHAZH1FhYWpJnLsr4b72L6fWFw=; b=rRSddNM0+j61DL COiqIHQvSfq217x+7O/seClswetwet2hnWgIe1N7M8G8Y3RlNLDI0RTh8qz8pRDAiHeh7OoX7D32h OgTSoaDSTu3Qb5lrkZaUhv/DXcI5obUmmLo24a8TRE18YfQjHDC8Dved+6SUs77cqE0odD/MONZJj plvs7NgWhxj3TIfv/0bgAtHmH2G21KExh8bU8nxt49+a9p0dTe+F+ZXpZATBNzOBfvOoIU2MhnI7q CF0Y3Wue7tOwioV/CvjeiUGeYi8bc0FDwgUEmA7mfbHfvzsg0z1mNKMNSu+I8/aR57id1WaLR5lEI mj9N97AEqSWilcli+LeA==; 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 1ipse3-0008UB-Ct; Fri, 10 Jan 2020 11:40:03 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipse0-0008Nr-Hj; Fri, 10 Jan 2020 11:40:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75FAF1063; Fri, 10 Jan 2020 03:39:59 -0800 (PST) Received: from [10.1.194.52] (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29DAA3F534; Fri, 10 Jan 2020 03:39:57 -0800 (PST) Subject: Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU To: Rob Herring , Nicolas Boichat References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-5-drinkcat@chromium.org> <20200108132302.GA3817@sirena.org.uk> From: Steven Price Message-ID: Date: Fri, 10 Jan 2020 11:39:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200110_034000_673587_41A30A8F X-CRM114-Status: GOOD ( 19.16 ) 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 , Devicetree List , Tomeu Vizoso , David Airlie , lkml , dri-devel , Liam Girdwood , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Daniel Vetter , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List 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 On 09/01/2020 16:56, Rob Herring wrote: > On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote: >> >> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: >>> >>> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: >>> >>>> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second >>>> regulator for their SRAM, let's add support for that. >>> >>>> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram"); >>>> + if (IS_ERR(pfdev->regulator_sram)) { >>> >>> This supply is required for the devices that need it so I'd therefore >>> expect the driver to request the supply non-optionally based on the >>> compatible string rather than just hoping that a missing regulator isn't >>> important. >> >> That'd be a bit awkward to match, though... Currently all bifrost >> share the same compatible "arm,mali-bifrost", and it'd seem >> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no >> idea if any other Mali implementation will require a second regulator, >> but with the MT8183 we do need it, see below. > > The current number of supported bifrost platforms is 0. It's only a > matter of time until SoC specific compatibles need to be used in the > driver. This is why we require them. > > It could very well be that all bifrost implementations need 2 > supplies. On chip RAMs are very frequently a separate thing which are > synthesized differently from logic. At least within a specific IP > model, I somewhat doubt there's a variable number of supplies. It > could be possible to connect both to the same supply, but the correct > way to handle that is both -supply properties point to the same > regulator. To be honest I've no idea what different SoC designs have done, but one of the intentions of core stacks was that sets of GPU cores would be on different power supplies. (I think this is to avoid issues with inrush current etc, but I'm not a hardware engineer). So I would expect designs with a large number of cores to have more physical supplies than designs with fewer cores. However, from a driver perspective this is all meant to be hidden by the hardware PDC which the GPU talks to. So the actual power up/down of the supplies may be completely automatic and therefore not described in the DT. So the actual number of software-controllable supplies could be 1 or could be more if the individual physical supplies are visible to software. The Hikey960 for instance hides everything behind a mailbox interface, and it's simply a case of requesting a frequency. Steve _______________________________________________ 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 8E3BFC33CA4 for ; Fri, 10 Jan 2020 11:40:02 +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 6A6FE2077C for ; Fri, 10 Jan 2020 11:40:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A6FE2077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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 A42BF6E9D0; Fri, 10 Jan 2020 11:40:01 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id E2BAE6E9D0 for ; Fri, 10 Jan 2020 11:39:59 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75FAF1063; Fri, 10 Jan 2020 03:39:59 -0800 (PST) Received: from [10.1.194.52] (e112269-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 29DAA3F534; Fri, 10 Jan 2020 03:39:57 -0800 (PST) Subject: Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU To: Rob Herring , Nicolas Boichat References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-5-drinkcat@chromium.org> <20200108132302.GA3817@sirena.org.uk> From: Steven Price Message-ID: Date: Fri, 10 Jan 2020 11:39:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US 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 , Devicetree List , Tomeu Vizoso , David Airlie , lkml , dri-devel , Liam Girdwood , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 09/01/2020 16:56, Rob Herring wrote: > On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote: >> >> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote: >>> >>> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote: >>> >>>> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second >>>> regulator for their SRAM, let's add support for that. >>> >>>> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram"); >>>> + if (IS_ERR(pfdev->regulator_sram)) { >>> >>> This supply is required for the devices that need it so I'd therefore >>> expect the driver to request the supply non-optionally based on the >>> compatible string rather than just hoping that a missing regulator isn't >>> important. >> >> That'd be a bit awkward to match, though... Currently all bifrost >> share the same compatible "arm,mali-bifrost", and it'd seem >> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no >> idea if any other Mali implementation will require a second regulator, >> but with the MT8183 we do need it, see below. > > The current number of supported bifrost platforms is 0. It's only a > matter of time until SoC specific compatibles need to be used in the > driver. This is why we require them. > > It could very well be that all bifrost implementations need 2 > supplies. On chip RAMs are very frequently a separate thing which are > synthesized differently from logic. At least within a specific IP > model, I somewhat doubt there's a variable number of supplies. It > could be possible to connect both to the same supply, but the correct > way to handle that is both -supply properties point to the same > regulator. To be honest I've no idea what different SoC designs have done, but one of the intentions of core stacks was that sets of GPU cores would be on different power supplies. (I think this is to avoid issues with inrush current etc, but I'm not a hardware engineer). So I would expect designs with a large number of cores to have more physical supplies than designs with fewer cores. However, from a driver perspective this is all meant to be hidden by the hardware PDC which the GPU talks to. So the actual power up/down of the supplies may be completely automatic and therefore not described in the DT. So the actual number of software-controllable supplies could be 1 or could be more if the individual physical supplies are visible to software. The Hikey960 for instance hides everything behind a mailbox interface, and it's simply a case of requesting a frequency. Steve _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel