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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF515C433F5 for ; Thu, 21 Apr 2022 08:50:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386966AbiDUIw7 (ORCPT ); Thu, 21 Apr 2022 04:52:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1386980AbiDUIwy (ORCPT ); Thu, 21 Apr 2022 04:52:54 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0832BF70 for ; Thu, 21 Apr 2022 01:50:05 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id r189so7519771ybr.6 for ; Thu, 21 Apr 2022 01:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=X7X1O9iZdMtSeshylJiakmEOV4UCGYmtQG5/k2PnUtQR35LhOowY9T0zT0TZ7chMfw PfGEjARNnp5i4aK9OW15d4E4lmkPv0Vfa2+oFSvEzlbOUzewFHAWSTPyjUYccbN26eKB YEtp4B+p7iKbdk4d2wq3m84k/DDtbU/vgWpSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=gYV0CGNPPgjCnmDxo2amZrOulyOkWZUbvpd+TXjsmIxKXUmkURK5FJ7hdmQjXfHYW/ xJF5eu5al3/iDsXf49Q4lmBa8J1qxOzi5X5UIjWANmuKTjN1igCdjM7swSt/pxPUrHlr k1uNkPCYZPZ+l27QFF7RjkqnG+2FgOzLBbkN8dR0x1TmqQQ7C0gxMZufclP/OsJCgXA6 AC8EMQ1b7O0wt6pYYTbv0zKd7hrdJKoeRnfhMqHSgOGX/LUnWX0fYRNJ8wxpV3uGO7bP ejYzTqwN4qAggdiVC7WtbGYnvRWiyujWTjIIRU6BdSKI1dpyTFFjXn7gvEEkdnGoMCJn 53Ww== X-Gm-Message-State: AOAM530rlFL1xF9p2NEn29OhL3aCJGd/Ty5KL0qQ966VP6wn9CXBGl9X 1/9ry40h0jIA8jWVDVLDzfjH75tyG32fJooDX7HanA== X-Google-Smtp-Source: ABdhPJyp/x2iHg2u/UbKD2umcDkFiw3TdbXVeOp6mmt8vzeFktbi6PtrjNtBzfFq1Myl4QMjaHUyxzECRA36CLqzFgs= X-Received: by 2002:a25:2ac3:0:b0:645:36f4:2db3 with SMTP id q186-20020a252ac3000000b0064536f42db3mr12076194ybq.189.1650531004985; Thu, 21 Apr 2022 01:50:04 -0700 (PDT) MIME-Version: 1.0 References: <20220414025023.11516-1-Nick.Fan@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Thu, 21 Apr 2022 16:49:54 +0800 Message-ID: Subject: Re: [PATCH v6 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU To: Steven Price , AngeloGioacchino Del Regno , Nick Fan Cc: Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, srv_heupstream@mediatek.com, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Project_Global_Chrome_Upstream_Group@mediatek.com, linux-mediatek@lists.infradead.org, alyssa.rosenzweig@collabora.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2022 at 8:47 PM Steven Price wrote: > > On 14/04/2022 12:51, AngeloGioacchino Del Regno wrote: > > Il 14/04/22 04:50, Nick Fan ha scritto: > >> Add devicetree schema for Arm Mali Valhall GPU > >> > >> Define a compatible string for the Mali Valhall GPU > >> for MediaTek's SoC platform. > >> > >> Signed-off-by: Nick Fan > > > > Hello Nick, > > Unfortunately, this binding is completely wrong. > > I think that's unfair, although there is room for improvement. > > > First of all, there's no arm,mali-valhall driver upstream - this will be > > managed > > by panfrost later, yes, but right now there's no support. > > We need a binding agreed upon before support can be added. +1. I asked them to send an updated binding for their hardware so that we could have a discussion about it and converge on something. > > Then, you're also setting opp-microvolt in a way that will never (or, at > > least, > > not anytime soon) be supported by the upstream driver, as it manages > > only one > > supply for devfreq scaling. > > The mt8183 binding (already in tree) is very similar. The binding also > should be describing the hardware not what the driver supports. There > are indeed limitations in Panfrost for supporting multiple supplies, but > that's something that needs improving in the driver not a reason to > block a (presumably correct) description of the hardware. I can't > comments on whether the specifics of the mt8192 are correct. Having an agreed upon binding also means that we can bring our downstream driver into alignment, instead of having to maintain a device tree fork. And +1 to being able to handle just one supply is a limitation of the driver. Panfrost in its current state would just not enable devfreq if more than supply is given [1]. Looking deeper, the OPP core currently doesn't support more than one regulator for a given device. > > Besides, please don't push bindings that have no upstream driver, > > especially if > > these are for downstream drivers requiring proprietary components, while a > > completely open source implementation is in the works. > > More constructively, Alyssa has already posted a patch (as part of the > series adding driver support) which would extend the existing Bifrost > bindings to (pre-CSF) Valhall: > > https://lore.kernel.org/dri-devel/20220211202728.6146-2-alyssa.rosenzweig@collabora.com/ > > I'm not sure I see the point of having a separate binding document for > Valhall considering the (pre-CSF) hardware is the same from the kernel > perspective. So I suppose the next step should be to move the required MediaTek specific changes into the existing binding instead of having a new one? Separately I think we would need a new binding to spell out the requirements of MediaTek's two supply OPP table? Or maybe this could be in the description of the Mali binding? Thanks ChenYu [1] https://patchwork.freedesktop.org/patch/429782/ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 448C2C433EF for ; Thu, 21 Apr 2022 08:50:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8854410FA18; Thu, 21 Apr 2022 08:50:07 +0000 (UTC) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by gabe.freedesktop.org (Postfix) with ESMTPS id C1BF910FA16 for ; Thu, 21 Apr 2022 08:50:05 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id m132so7526450ybm.4 for ; Thu, 21 Apr 2022 01:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=X7X1O9iZdMtSeshylJiakmEOV4UCGYmtQG5/k2PnUtQR35LhOowY9T0zT0TZ7chMfw PfGEjARNnp5i4aK9OW15d4E4lmkPv0Vfa2+oFSvEzlbOUzewFHAWSTPyjUYccbN26eKB YEtp4B+p7iKbdk4d2wq3m84k/DDtbU/vgWpSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=m43aCNvmFyklyQOVqlc3Z2HvCOYEa+pODngEAIGrISoOEzCdKQ+U7XgEhEzkgRZbEE m/S3ttltU90Kn+ggHu97OiyM4+0wpRMXBkyjoEQEXkGxh84K0b/WcpjNu7lj7tvNpNod A7ki8YMAEYFadkQrvlLxh3LzW4W1kd0wp4EdJpBbK3uXWfmrQbN8+cdbNAVtosSb8gOP JrQ43+eFs35P/XKpEdB8bqf2oM5+U2f5VHoleCMNgliG9jRYFUwIaHiC6vXIMVSnhCFL KQY4qzlNjAOCYmaCkg8TAVPcq/MhbVxO1g/2FSBjXy4sud7FBrZnGT9PxErf3XdM72k9 zr2w== X-Gm-Message-State: AOAM533Ct6LotddLgqbwmsQZwQp/Rvu9gBtKRb9sSHSxEzJIXm9puSrE ONZKEjcENUI4872p8CHhS7cYgyKnqFlE+5tnBPcAtw== X-Google-Smtp-Source: ABdhPJyp/x2iHg2u/UbKD2umcDkFiw3TdbXVeOp6mmt8vzeFktbi6PtrjNtBzfFq1Myl4QMjaHUyxzECRA36CLqzFgs= X-Received: by 2002:a25:2ac3:0:b0:645:36f4:2db3 with SMTP id q186-20020a252ac3000000b0064536f42db3mr12076194ybq.189.1650531004985; Thu, 21 Apr 2022 01:50:04 -0700 (PDT) MIME-Version: 1.0 References: <20220414025023.11516-1-Nick.Fan@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Thu, 21 Apr 2022 16:49:54 +0800 Message-ID: Subject: Re: [PATCH v6 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU To: Steven Price , AngeloGioacchino Del Regno , Nick Fan Content-Type: text/plain; charset="UTF-8" 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: devicetree@vger.kernel.org, srv_heupstream@mediatek.com, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Project_Global_Chrome_Upstream_Group@mediatek.com, Rob Herring , linux-mediatek@lists.infradead.org, alyssa.rosenzweig@collabora.com, Matthias Brugger , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Apr 14, 2022 at 8:47 PM Steven Price wrote: > > On 14/04/2022 12:51, AngeloGioacchino Del Regno wrote: > > Il 14/04/22 04:50, Nick Fan ha scritto: > >> Add devicetree schema for Arm Mali Valhall GPU > >> > >> Define a compatible string for the Mali Valhall GPU > >> for MediaTek's SoC platform. > >> > >> Signed-off-by: Nick Fan > > > > Hello Nick, > > Unfortunately, this binding is completely wrong. > > I think that's unfair, although there is room for improvement. > > > First of all, there's no arm,mali-valhall driver upstream - this will be > > managed > > by panfrost later, yes, but right now there's no support. > > We need a binding agreed upon before support can be added. +1. I asked them to send an updated binding for their hardware so that we could have a discussion about it and converge on something. > > Then, you're also setting opp-microvolt in a way that will never (or, at > > least, > > not anytime soon) be supported by the upstream driver, as it manages > > only one > > supply for devfreq scaling. > > The mt8183 binding (already in tree) is very similar. The binding also > should be describing the hardware not what the driver supports. There > are indeed limitations in Panfrost for supporting multiple supplies, but > that's something that needs improving in the driver not a reason to > block a (presumably correct) description of the hardware. I can't > comments on whether the specifics of the mt8192 are correct. Having an agreed upon binding also means that we can bring our downstream driver into alignment, instead of having to maintain a device tree fork. And +1 to being able to handle just one supply is a limitation of the driver. Panfrost in its current state would just not enable devfreq if more than supply is given [1]. Looking deeper, the OPP core currently doesn't support more than one regulator for a given device. > > Besides, please don't push bindings that have no upstream driver, > > especially if > > these are for downstream drivers requiring proprietary components, while a > > completely open source implementation is in the works. > > More constructively, Alyssa has already posted a patch (as part of the > series adding driver support) which would extend the existing Bifrost > bindings to (pre-CSF) Valhall: > > https://lore.kernel.org/dri-devel/20220211202728.6146-2-alyssa.rosenzweig@collabora.com/ > > I'm not sure I see the point of having a separate binding document for > Valhall considering the (pre-CSF) hardware is the same from the kernel > perspective. So I suppose the next step should be to move the required MediaTek specific changes into the existing binding instead of having a new one? Separately I think we would need a new binding to spell out the requirements of MediaTek's two supply OPP table? Or maybe this could be in the description of the Mali binding? Thanks ChenYu [1] https://patchwork.freedesktop.org/patch/429782/ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0BCFEC433EF for ; Thu, 21 Apr 2022 08:50:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+uuARNyOgTXTk0gskQkqLyWuxd7tQnOqhRIbKWcEdSM=; b=Fm3I2cM7hToh8o ME7URyUVVlS/SxU5QbLGZdULMB+UvoqEvMeIexq0lPbLjM6G/ZIqlgahPWpBTPzgZV6eBIobVXVD7 l23GnmCdnPAyXKlLrs2C74gW059SRuuNW4H1m41ZMrwLHBlHQChoKa0RZrhrYAOqMjCHjombd/+eI 61RextWXKFhzLdO2iPXcjpBu2jTiU+H970dORWV600aQ2yaUG8vFdN42RlUEVHfaz0MBp9zaBFsAS H8KghU4GGUd7eVK7U2eB7weIBs9rq94qbd7deBVDza4Bnmt7Cd8JrLOgZeyuzbINaHdkHcLLeuuAn EivJEifpVDDnthrVhr3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhSWL-00CWLV-1o; Thu, 21 Apr 2022 08:50:37 +0000 Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhSVr-00CW6s-90 for linux-mediatek@lists.infradead.org; Thu, 21 Apr 2022 08:50:09 +0000 Received: by mail-yb1-xb2b.google.com with SMTP id t67so7534991ybi.2 for ; Thu, 21 Apr 2022 01:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=X7X1O9iZdMtSeshylJiakmEOV4UCGYmtQG5/k2PnUtQR35LhOowY9T0zT0TZ7chMfw PfGEjARNnp5i4aK9OW15d4E4lmkPv0Vfa2+oFSvEzlbOUzewFHAWSTPyjUYccbN26eKB YEtp4B+p7iKbdk4d2wq3m84k/DDtbU/vgWpSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=yqOGXtKTIMcXY4e6lJwPjcJB7LIXHsOWHnlFE5Z3iOLEElVWuh83qmVJjBw93O+DT2 6cW0jT66Is2yfENLuyjfx+BQ38ye5GUYKtY0SkKqwNGW0b/A+4C8XC9OCfct6C3Nfz2f 2bL62cX4hCp5QeFlvH4mFHsRNMjZUVohLI2T9/XlT23yeUCsTAyPX5IRjvEnxgeAlehp rFmR9DEdFnHUtxuGbz3n0MMArOR1JIQOOpbN8Q5M04cdHtYqaSjdiFN9xrNicpC1XgMa UCb7z9sCPMUVZusAIz6H3VDmbyGcRBCehwsPa5FFnAlGVeXiIIdLP6qhELEXv1Q7qi+Y q0vw== X-Gm-Message-State: AOAM532EZ+2q1nD/LvEliyqppfqZ1cGT3BHP8TFELVZgJO4zh6Xiuh6D lpjvqMG9fLpPXO72OG7+1fVdzCGT8vmtvfR7JolS4g== X-Google-Smtp-Source: ABdhPJyp/x2iHg2u/UbKD2umcDkFiw3TdbXVeOp6mmt8vzeFktbi6PtrjNtBzfFq1Myl4QMjaHUyxzECRA36CLqzFgs= X-Received: by 2002:a25:2ac3:0:b0:645:36f4:2db3 with SMTP id q186-20020a252ac3000000b0064536f42db3mr12076194ybq.189.1650531004985; Thu, 21 Apr 2022 01:50:04 -0700 (PDT) MIME-Version: 1.0 References: <20220414025023.11516-1-Nick.Fan@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Thu, 21 Apr 2022 16:49:54 +0800 Message-ID: Subject: Re: [PATCH v6 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU To: Steven Price , AngeloGioacchino Del Regno , Nick Fan Cc: Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, srv_heupstream@mediatek.com, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Project_Global_Chrome_Upstream_Group@mediatek.com, linux-mediatek@lists.infradead.org, alyssa.rosenzweig@collabora.com, linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220421_015007_397339_AA314006 X-CRM114-Status: GOOD ( 33.28 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, Apr 14, 2022 at 8:47 PM Steven Price wrote: > > On 14/04/2022 12:51, AngeloGioacchino Del Regno wrote: > > Il 14/04/22 04:50, Nick Fan ha scritto: > >> Add devicetree schema for Arm Mali Valhall GPU > >> > >> Define a compatible string for the Mali Valhall GPU > >> for MediaTek's SoC platform. > >> > >> Signed-off-by: Nick Fan > > > > Hello Nick, > > Unfortunately, this binding is completely wrong. > > I think that's unfair, although there is room for improvement. > > > First of all, there's no arm,mali-valhall driver upstream - this will be > > managed > > by panfrost later, yes, but right now there's no support. > > We need a binding agreed upon before support can be added. +1. I asked them to send an updated binding for their hardware so that we could have a discussion about it and converge on something. > > Then, you're also setting opp-microvolt in a way that will never (or, at > > least, > > not anytime soon) be supported by the upstream driver, as it manages > > only one > > supply for devfreq scaling. > > The mt8183 binding (already in tree) is very similar. The binding also > should be describing the hardware not what the driver supports. There > are indeed limitations in Panfrost for supporting multiple supplies, but > that's something that needs improving in the driver not a reason to > block a (presumably correct) description of the hardware. I can't > comments on whether the specifics of the mt8192 are correct. Having an agreed upon binding also means that we can bring our downstream driver into alignment, instead of having to maintain a device tree fork. And +1 to being able to handle just one supply is a limitation of the driver. Panfrost in its current state would just not enable devfreq if more than supply is given [1]. Looking deeper, the OPP core currently doesn't support more than one regulator for a given device. > > Besides, please don't push bindings that have no upstream driver, > > especially if > > these are for downstream drivers requiring proprietary components, while a > > completely open source implementation is in the works. > > More constructively, Alyssa has already posted a patch (as part of the > series adding driver support) which would extend the existing Bifrost > bindings to (pre-CSF) Valhall: > > https://lore.kernel.org/dri-devel/20220211202728.6146-2-alyssa.rosenzweig@collabora.com/ > > I'm not sure I see the point of having a separate binding document for > Valhall considering the (pre-CSF) hardware is the same from the kernel > perspective. So I suppose the next step should be to move the required MediaTek specific changes into the existing binding instead of having a new one? Separately I think we would need a new binding to spell out the requirements of MediaTek's two supply OPP table? Or maybe this could be in the description of the Mali binding? Thanks ChenYu [1] https://patchwork.freedesktop.org/patch/429782/ _______________________________________________ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E85F9C433F5 for ; Thu, 21 Apr 2022 08:51:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Wl6qJuK52KwbItsEWbBKREleeiyjpK/QLmk9vkjj4Z4=; b=JiIg5xxywvtC1H 2kevm8L7gjpFB1GgNsjtx6QPqAe4eZ0D27Q8bRRhrdhYVirnaNFwfQsJx+m56eUAzVpP3P5QytxkG uERTiHiDgaon5lpBrVSoOJK1YyPKe5Gh0w8cKkgtdDRSgd98i3H/CfDcdAvwanF6sYge6Guti5gLi 11KHXDyKs354KLfG0Plprki4dTY5DP4XXer8w0WRaG9SobrtrYAZFdLT5HO09cgDd0P/DVoJyU/nv 8ml7zLxXUJhls9O8gbX56lR1Ba4YLTU/VYZWKqJHuEW/krL2LG9Q3eRxkNBqCDo3sBbuPJEOfs1MG ca6B/4KISwGmsghwO72w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhSVw-00CWAD-72; Thu, 21 Apr 2022 08:50:12 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhSVq-00CW6n-OE for linux-arm-kernel@lists.infradead.org; Thu, 21 Apr 2022 08:50:08 +0000 Received: by mail-yb1-xb36.google.com with SMTP id f17so7489488ybj.10 for ; Thu, 21 Apr 2022 01:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=X7X1O9iZdMtSeshylJiakmEOV4UCGYmtQG5/k2PnUtQR35LhOowY9T0zT0TZ7chMfw PfGEjARNnp5i4aK9OW15d4E4lmkPv0Vfa2+oFSvEzlbOUzewFHAWSTPyjUYccbN26eKB YEtp4B+p7iKbdk4d2wq3m84k/DDtbU/vgWpSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C1t5mUF1ebuEHByKOPa7jvd5uPJ4IKlhTRldMrpukDU=; b=yw89gfnHGDO19Q3bkIEfZ1JlNG7SGK6LQgWXXy/R8nNPFJEOTFw2OjjivOkthaqCsC 4e9QGeRbiebhC3Lw0ibtao10K02CIghV9kYFsGvzLOIrMFV6tQLDRW9knSPjFuXNdTu0 /gzy/wr97pFGtWor4nMU6BTYNYS1kAV5Yq5g8XsJTdknyzv7q1gpw4ZPXY1KyvEiNapk JkqWR0KuocHheiPwWFOjdn5BujNRgGH5OAboFRfXup7IOYNgUrubYQCqGS34L9srwddP AKxBcjFBx4LIoh3gUWGqLQKXKGMz6yeud13W53xLYr+j7NDmJnWDu7zheggab/3GX7bB TTsw== X-Gm-Message-State: AOAM53161Q9NoxhjNPQliWVtwk5Axy4A6Pi1OctmWPXQsSXrOhSAiYJK lCYUuiS0EVtm0JXEMkqHOszyEQk1Xi6RPpXKhv7qpA== X-Google-Smtp-Source: ABdhPJyp/x2iHg2u/UbKD2umcDkFiw3TdbXVeOp6mmt8vzeFktbi6PtrjNtBzfFq1Myl4QMjaHUyxzECRA36CLqzFgs= X-Received: by 2002:a25:2ac3:0:b0:645:36f4:2db3 with SMTP id q186-20020a252ac3000000b0064536f42db3mr12076194ybq.189.1650531004985; Thu, 21 Apr 2022 01:50:04 -0700 (PDT) MIME-Version: 1.0 References: <20220414025023.11516-1-Nick.Fan@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Thu, 21 Apr 2022 16:49:54 +0800 Message-ID: Subject: Re: [PATCH v6 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU To: Steven Price , AngeloGioacchino Del Regno , Nick Fan Cc: Rob Herring , Matthias Brugger , devicetree@vger.kernel.org, srv_heupstream@mediatek.com, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Project_Global_Chrome_Upstream_Group@mediatek.com, linux-mediatek@lists.infradead.org, alyssa.rosenzweig@collabora.com, linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220421_015006_865636_7591392A X-CRM114-Status: GOOD ( 34.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 14, 2022 at 8:47 PM Steven Price wrote: > > On 14/04/2022 12:51, AngeloGioacchino Del Regno wrote: > > Il 14/04/22 04:50, Nick Fan ha scritto: > >> Add devicetree schema for Arm Mali Valhall GPU > >> > >> Define a compatible string for the Mali Valhall GPU > >> for MediaTek's SoC platform. > >> > >> Signed-off-by: Nick Fan > > > > Hello Nick, > > Unfortunately, this binding is completely wrong. > > I think that's unfair, although there is room for improvement. > > > First of all, there's no arm,mali-valhall driver upstream - this will be > > managed > > by panfrost later, yes, but right now there's no support. > > We need a binding agreed upon before support can be added. +1. I asked them to send an updated binding for their hardware so that we could have a discussion about it and converge on something. > > Then, you're also setting opp-microvolt in a way that will never (or, at > > least, > > not anytime soon) be supported by the upstream driver, as it manages > > only one > > supply for devfreq scaling. > > The mt8183 binding (already in tree) is very similar. The binding also > should be describing the hardware not what the driver supports. There > are indeed limitations in Panfrost for supporting multiple supplies, but > that's something that needs improving in the driver not a reason to > block a (presumably correct) description of the hardware. I can't > comments on whether the specifics of the mt8192 are correct. Having an agreed upon binding also means that we can bring our downstream driver into alignment, instead of having to maintain a device tree fork. And +1 to being able to handle just one supply is a limitation of the driver. Panfrost in its current state would just not enable devfreq if more than supply is given [1]. Looking deeper, the OPP core currently doesn't support more than one regulator for a given device. > > Besides, please don't push bindings that have no upstream driver, > > especially if > > these are for downstream drivers requiring proprietary components, while a > > completely open source implementation is in the works. > > More constructively, Alyssa has already posted a patch (as part of the > series adding driver support) which would extend the existing Bifrost > bindings to (pre-CSF) Valhall: > > https://lore.kernel.org/dri-devel/20220211202728.6146-2-alyssa.rosenzweig@collabora.com/ > > I'm not sure I see the point of having a separate binding document for > Valhall considering the (pre-CSF) hardware is the same from the kernel > perspective. So I suppose the next step should be to move the required MediaTek specific changes into the existing binding instead of having a new one? Separately I think we would need a new binding to spell out the requirements of MediaTek's two supply OPP table? Or maybe this could be in the description of the Mali binding? Thanks ChenYu [1] https://patchwork.freedesktop.org/patch/429782/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel