Message ID | 20221017104141.7338-3-linux@fw-web.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1375714wrs; Mon, 17 Oct 2022 03:43:10 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4QFkWQfP1e7xvBpfHK3IAf/ACkt5Fxj0NOBIYCBGXw7rt+KTXROfEDVdJ55Ww65u7HYIlm X-Received: by 2002:a17:90a:3841:b0:20b:650:60d1 with SMTP id l1-20020a17090a384100b0020b065060d1mr12760996pjf.102.1666003390226; Mon, 17 Oct 2022 03:43:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666003390; cv=none; d=google.com; s=arc-20160816; b=FbaMUKIauTNL28q95dnKABjBLDxOiqGxEWYfHs1/FWtPnvhyr+Vt/F4FZw94Cpf6s0 V8xLliwMwXUshpjxgn3ev7zdQwi/Z6BTz3ioTcg00uBwITTlnk3L23URB0PAB60uYj+z BwkiuI6Wj2v+sw1ioGriUwzjmzKxU7G/Q851eTZjsx371MfqY7TkAi+AtSjUYSpivYkz 3nyX7aWzrWFq+BzrSM74sQsOrkMfX8bqjneru82GsoDf2QbCu2AK9poI9R4gUZxU7WBM WL37UrqoOZJMzz8onUminx5bn0DT085Xbpy2w6MyBMnhklPlJ85uLa9EVfvRQW1I3hbx ynAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=X/rv2/xAUdG1oY3mqfLC41QXomMeexmYUY9AH2+9l9o=; b=M3eeAtUYEKRPgy4KsD8n2G54YQA2LnzEezUhRO+S0aJiavPTtzNMDWG1QYR0ZIfE0Q 2CjkbwpyyG32UhDSq6iBUT6RqGnBjpyA+ikHp5DmPs56/AwubwPDW/ZhWkGbgx1fRitd HsLbz9CXjufi9ofMiFaJaAnmxvJojqBCaIkLlrTwoHOdgTDwbWvgTPeS56HX2nBpsIJA dinVoskobUAPTf5tMHTiaXx4uIo3CQQ0FO0SgW0igYKBb6l+BZah31cWOlh0iJXKJrAx n3sAguMpN9gVTeRa67mVJT+ge75Zh3BL2OwdpWwqMo/Kpa3onlRx/pYH343yoTV5wkLq y4zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mailerdienst.de header.s=20200217 header.b=i5Qo7klc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i11-20020a170902cf0b00b0017f580f646fsi13001200plg.304.2022.10.17.03.42.57; Mon, 17 Oct 2022 03:43:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mailerdienst.de header.s=20200217 header.b=i5Qo7klc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229562AbiJQKmJ (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Mon, 17 Oct 2022 06:42:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229950AbiJQKl6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Oct 2022 06:41:58 -0400 Received: from mxout3.routing.net (mxout3.routing.net [IPv6:2a03:2900:1:a::8]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C2761BEB7; Mon, 17 Oct 2022 03:41:57 -0700 (PDT) Received: from mxbox1.masterlogin.de (unknown [192.168.10.88]) by mxout3.routing.net (Postfix) with ESMTP id 88834604D6; Mon, 17 Oct 2022 10:41:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailerdienst.de; s=20200217; t=1666003315; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X/rv2/xAUdG1oY3mqfLC41QXomMeexmYUY9AH2+9l9o=; b=i5Qo7klc8WKbTAkYWsV5t4LXXq3aY0simORcZJ/8SQgI3bLnDPvunKuaUzPWLu34Ylhcde fy39FCmGuChGBrwK57bJO3tDSxAEDJ41aausmiIsYPAEl/OCew99zad0jKMAEQbvdD1531 6H7+aKqHvGWCLlJBe2kqZDAZ6SvqJpI= Received: from frank-G5.. (fttx-pool-217.61.154.127.bambit.de [217.61.154.127]) by mxbox1.masterlogin.de (Postfix) with ESMTPSA id E5B934053E; Mon, 17 Oct 2022 10:41:54 +0000 (UTC) From: Frank Wunderlich <linux@fw-web.de> To: linux-mediatek@lists.infradead.org Cc: Frank Wunderlich <frank-w@public-files.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Matthias Brugger <matthias.bgg@gmail.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [RFC v1 02/12] dt-bindings: PCI: mediatek-gen3: add support for mt7986 Date: Mon, 17 Oct 2022 12:41:31 +0200 Message-Id: <20221017104141.7338-3-linux@fw-web.de> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221017104141.7338-1-linux@fw-web.de> References: <20221017104141.7338-1-linux@fw-web.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mail-ID: 83c5a80d-4315-46aa-b94f-9c0f82fc4136 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746931171088103870?= X-GMAIL-MSGID: =?utf-8?q?1746931171088103870?= |
Series |
Add BananaPi R3
|
|
Commit Message
Frank Wunderlich
Oct. 17, 2022, 10:41 a.m. UTC
From: Frank Wunderlich <frank-w@public-files.de> Add compatible string for mt7986. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> --- mt7986a.dtsi misses clock-names which are now required since support of MT8192/MT8188/MT8195. This change also introduces a 6th clock which is now needed for all pcie-gen3 dts. i do not know how to map the clocks to the names... mediatek-pcie-gen3.yaml: clock-names: items: - const: pl_250m - const: tl_26m - const: tl_96m - const: tl_32k - const: peri_26m - enum: - top_133m # for MT8192 - peri_mem # for MT8188/MT8195 mt7986a.dtsi: clocks = <&infracfg CLK_INFRA_PCIE_SEL>, <&infracfg CLK_INFRA_IPCIE_CK>, <&infracfg CLK_INFRA_IPCIE_PIPE_CK>, <&infracfg CLK_INFRA_IPCIER_CK>, <&infracfg CLK_INFRA_IPCIEB_CK>; --- Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 1 + 1 file changed, 1 insertion(+)
Comments
On 17/10/2022 06:41, Frank Wunderlich wrote: > From: Frank Wunderlich <frank-w@public-files.de> > > Add compatible string for mt7986. > > Signed-off-by: Frank Wunderlich <frank-w@public-files.de> > --- > mt7986a.dtsi misses clock-names which are now required since support of > MT8192/MT8188/MT8195. This change also introduces a 6th clock which is > now needed for all pcie-gen3 dts. > > i do not know how to map the clocks to the names... > > mediatek-pcie-gen3.yaml: > > clock-names: > items: > - const: pl_250m > - const: tl_26m > - const: tl_96m > - const: tl_32k > - const: peri_26m > - enum: > - top_133m # for MT8192 > - peri_mem # for MT8188/MT8195 > > mt7986a.dtsi: > > clocks = <&infracfg CLK_INFRA_PCIE_SEL>, > <&infracfg CLK_INFRA_IPCIE_CK>, > <&infracfg CLK_INFRA_IPCIE_PIPE_CK>, > <&infracfg CLK_INFRA_IPCIER_CK>, > <&infracfg CLK_INFRA_IPCIEB_CK>; Maybe the clock is not required on mt7986? Anyway, for the bindings: Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
Hi, > Gesendet: Dienstag, 18. Oktober 2022 um 17:35 Uhr > Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org> > On 17/10/2022 06:41, Frank Wunderlich wrote: > > From: Frank Wunderlich <frank-w@public-files.de> > Maybe the clock is not required on mt7986? yes, mt7986 does not have all clocks currently defined in binding for gen3-pcie (currently mt8xxx) the mapping is as followed: CLK_INFRA_IPCIER_CK: peri_26m CLK_INFRA_IPCIEB_CK: top_133m CLK_INFRA_IPCIE_CK: pcie working clock from SoC, in MT7986 it is equal to tl_26m + tl_96m + tl_32k in MT8192 CLK_INFRA_PCIE_SEL: clock mux to select source clock to CLK_INFRA_IPCIE_CK CLK_INFRA_IPCIE_PIPE_CK : pcie working clock from PHY, pl_250m as far as i see the driver only enables the clocks in bulk (no access to the clock-names), but binding needs the names got it solved with help from mtk (see my comment on part 7) with filling missing clocks with a fixed-clock-node. If this is the right way this binding-change is enough ;) > Anyway, for the bindings: > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> thx regards Frank
Il 17/10/22 12:41, Frank Wunderlich ha scritto: > From: Frank Wunderlich <frank-w@public-files.de> > > Add compatible string for mt7986. > > Signed-off-by: Frank Wunderlich <frank-w@public-files.de> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > mt7986a.dtsi misses clock-names which are now required since support of > MT8192/MT8188/MT8195. This change also introduces a 6th clock which is > now needed for all pcie-gen3 dts. > > i do not know how to map the clocks to the names... > > mediatek-pcie-gen3.yaml: > > clock-names: > items: > - const: pl_250m > - const: tl_26m > - const: tl_96m > - const: tl_32k > - const: peri_26m > - enum: > - top_133m # for MT8192 > - peri_mem # for MT8188/MT8195 > > mt7986a.dtsi: > > clocks = <&infracfg CLK_INFRA_PCIE_SEL>, > <&infracfg CLK_INFRA_IPCIE_CK>, > <&infracfg CLK_INFRA_IPCIE_PIPE_CK>, > <&infracfg CLK_INFRA_IPCIER_CK>, > <&infracfg CLK_INFRA_IPCIEB_CK>; If this SoC has a different clock tree... then you should add bindings for this kind of clock tree. CLK_INFRA_IPCIER_CK is *not* a peri clock: "peri" means PERICFG, which does not seem to be present in this SoC... so no, you can't assign it to "peri_26m", nor you can assign it to tl_32k, as that's not a 32KHz clock. CLK_INFRA_PCIEB_CK can be a "top_133m" clock... as it is gating "sysaxi_sel", which is a topckgen clock. CLK_INFRA_IPCIE_CK is your "tl_(something)" clock, as that's effectively gating "pextp_tl_ck_sel" (which is the PCIe Transaction Layer clock mux). CLK_INFRA_IPCIE_PIPE_CK seems to be parented to "top_xtal", frequency = 40MHz, so I don't see how can this be a pl_250m? Looks like being a 40m clock and I wish we didn't have clock frequencies specified in the names, as "pl" would fit, but "pl_250m" does not. I wonder if we can change the clock names and reflect the changes to the mt8192 devicetree (mt8195 does not have any pcie node yet), and if that would be a good idea right now. ...and I've left the first for last, because... CLK_INFRA_PCIE_SEL: I have no datasheet for this SoC, but if you're sure that this clock is selecting the source clock to CLK_INFRA_IPCIE_CK, then the clock driver is wrong... Right now, I see the following: static const char *const infra_pcie_parents[] __initconst = { "top_rtc_32p7k", "csw_f26m_sel", "top_xtal", "pextp_tl_ck_sel" }; GATE_INFRA2(CLK_INFRA_IPCIE_CK, "infra_ipcie", "pextp_tl_ck_sel", 12), MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_SEL, "infra_pcie_sel", infra_pcie_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1, -1, -1), ....so if you're right, we should instead have: GATE_INFRA2(CLK_INFRA_IPCIE_CK, "infra_ipcie", "infra_pcie_sel", 12), ....with this meaning that adding CLK_INFRA_PCIE_SEL in devicetree is useless. This clock tree looks a bit unclear (because again, there's no datasheet around), but that's what I understand with a rather fast look in the clock drivers and with some experience on other MTK SoCs. Then again, if this tree is effectively incompatible with the one from MT8192 and MT8195, you should have different clock names... and just as a fast idea: clock-names = "axi", "tl", "pl", "top"; with clocks, in order: CLK_INFRA_PCIEB_CK, CLK_INFRA_IPCIE_CK, CLK_INFRA_IPCIE_PIPE_CK, CLK_INFRA_IPCIER_CK. ...but feel free to reiterate that :-) Hope that was helpful. Cheers, Angelo
Am 19. Oktober 2022 10:28:59 MESZ schrieb AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>: >Il 17/10/22 12:41, Frank Wunderlich ha scritto: >If this SoC has a different clock tree... then you should add bindings for this >kind of clock tree. > >CLK_INFRA_IPCIER_CK is *not* a peri clock: "peri" means PERICFG, which does not >seem to be present in this SoC... so no, you can't assign it to "peri_26m", nor >you can assign it to tl_32k, as that's not a 32KHz clock. > >CLK_INFRA_PCIEB_CK can be a "top_133m" clock... as it is gating "sysaxi_sel", >which is a topckgen clock. > >CLK_INFRA_IPCIE_CK is your "tl_(something)" clock, as that's effectively gating >"pextp_tl_ck_sel" (which is the PCIe Transaction Layer clock mux). > >CLK_INFRA_IPCIE_PIPE_CK seems to be parented to "top_xtal", frequency = 40MHz, >so I don't see how can this be a pl_250m? Looks like being a 40m clock and I >wish we didn't have clock frequencies specified in the names, as "pl" would fit, >but "pl_250m" does not. >I wonder if we can change the clock names and reflect the changes to the mt8192 >devicetree (mt8195 does not have any pcie node yet), and if that would be a good >idea right now. > >...and I've left the first for last, because... > >CLK_INFRA_PCIE_SEL: I have no datasheet for this SoC, but if you're sure that >this clock is selecting the source clock to CLK_INFRA_IPCIE_CK, then the clock >driver is wrong... > >Right now, I see the following: > >static const char *const infra_pcie_parents[] __initconst = { > "top_rtc_32p7k", "csw_f26m_sel", "top_xtal", "pextp_tl_ck_sel" >}; > >GATE_INFRA2(CLK_INFRA_IPCIE_CK, "infra_ipcie", "pextp_tl_ck_sel", 12), > >MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_SEL, "infra_pcie_sel", > infra_pcie_parents, 0x0028, 0x0020, 0x0024, 0, 2, > -1, -1, -1), > >....so if you're right, we should instead have: > >GATE_INFRA2(CLK_INFRA_IPCIE_CK, "infra_ipcie", "infra_pcie_sel", 12), > >....with this meaning that adding CLK_INFRA_PCIE_SEL in devicetree is useless. > >This clock tree looks a bit unclear (because again, there's no datasheet around), >but that's what I understand with a rather fast look in the clock drivers and >with some experience on other MTK SoCs. > >Then again, if this tree is effectively incompatible with the one from MT8192 and >MT8195, you should have different clock names... and just as a fast idea: > >clock-names = "axi", "tl", "pl", "top"; > >with clocks, in order: >CLK_INFRA_PCIEB_CK, CLK_INFRA_IPCIE_CK, >CLK_INFRA_IPCIE_PIPE_CK, CLK_INFRA_IPCIER_CK. > >...but feel free to reiterate that :-) >Hope that was helpful. > >Cheers, >Angelo Hi, thanks for digging into the clock-driver. Currently i have mapped it like this (see comment to part7) clocks = <&infracfg CLK_INFRA_IPCIE_PIPE_CK>, <&infracfg CLK_INFRA_IPCIE_CK>, <&clk40m>, <&clk40m>, <&infracfg CLK_INFRA_IPCIER_CK>, <&infracfg CLK_INFRA_IPCIEB_CK>; clock-names = "pl_250m", "tl_26m", "tl_96m", "tl_32k", "peri_26m", "top_133m"; Mtk says it has same IP block and except missing clocks it is compatible with mt8xxx gen3 pcie driver/binding. Pcie driver only enables the clocks in bulk without names,but binding requires the names property so mapping needs to be correct. regards Frank
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index c00be39af64e..b372c8351d9a 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -51,6 +51,7 @@ properties: oneOf: - items: - enum: + - mediatek,mt7986-pcie - mediatek,mt8188-pcie - mediatek,mt8195-pcie - const: mediatek,mt8192-pcie