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 15FCDC433F5 for ; Mon, 17 Jan 2022 21:07:06 +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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7p9Hs1PyGFBp/P1Gz2M9M39lzpuciVIyuejsua+kdcQ=; b=Uhbo+qeQUjw/x3 qcitnqTBPSPkEP833SyW0LidGonpgAHlP+wawIB5yo9uuOFMXhWGda/E0uBMV+eDNbK2vqvtjFar3 zMzRWYRjKhtPzlSVwCy/m3LRq39jPl6EO4pr6VB9ROvAntykyGXGDpA6iuYPmlgw1EWvHq+WrrIg8 Ugpn/byBKf1n1P/ftnCBQef37hZkM5bsxa+Ex6+quOE7yFxPBMESOL/3JSlvMzlcu0PoiW8FDGCkO rF98no0XBnz3CXg/IEfcrIyC77m9VlsAphtDXzSlwAeK17+BKB2Hk9Fdx18nucE/PW1H2I5kUGEVR km/CMNPBAlEI4/QA0llg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9ZC8-00GOKz-Ru; Mon, 17 Jan 2022 21:05:40 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9ZC4-00GOKY-Ec; Mon, 17 Jan 2022 21:05:38 +0000 Received: from ip5b412258.dynamic.kabel-deutschland.de ([91.65.34.88] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9ZBz-0001NU-2L; Mon, 17 Jan 2022 22:05:31 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Frank Wunderlich , Peter Geis Cc: Johan Jonker , Frank Wunderlich , "open list:ARM/Rockchip SoC..." , Rob Herring , devicetree , arm-mail-list , Linux Kernel Mailing List Subject: Re: [PATCH v1 1/3] dts64: rk3568: drop pclk_xpcs from gmac0 Date: Mon, 17 Jan 2022 22:05:29 +0100 Message-ID: <236548630.RelmrRfzIS@diego> In-Reply-To: References: <20220116124911.65203-1-linux@fw-web.de> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220117_130536_556609_1D4336E2 X-CRM114-Status: GOOD ( 38.87 ) 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 Am Montag, 17. Januar 2022, 19:26:27 CET schrieb Peter Geis: > On Mon, Jan 17, 2022 at 6:59 AM Frank Wunderlich > wrote: > > > > Hi > > > > > Gesendet: Montag, 17. Januar 2022 um 11:47 Uhr > > > Von: "Johan Jonker" > > > Hi Frank, > > > > > > Despite that the DT is hosted in the kernel tree > > > DT and mainline kernel driver support are 2 separate things. > > > PCLK_XPCS might be in use elsewhere. > > > > > > Given the link below pclk_xpcs is only needed for rk3568. > > > Maybe gmac1 should have a PCLK_XPCS too, because one can select between > > > them. > > > > > > ethernet: stmicro: stmmac: Add SGMII/QSGMII support for RK3568 > > > https://github.com/rockchip-linux/kernel/commit/1fc7cbfe9e227c700c692f1de3137914b3ea6ca6 > > > > > > The original dtsi did have PCLK_XPCS in both nodes. > > > https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L2121 > > > https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L1492 > > > > > > Maybe fix the document or leave it as it is for now as long the driver > > > isn't updated and someone has tested it. > > > That's up to the DT maintainer. > > > > > > Johan > > > > as far as i understand, the PCLK_XPCS is part of the naneng combphy, which is not yet available in mainline. > > Naneng driver needs some changes and imho this should be part of it (including change documentation). That also makes it clear why this clock is added. > > But leaving an unused property with sideeffects is imho no good choice. > > > > So this was the easiest way to fix the dtbs_check. Else i got no usable result for it. Maybe adding it to Documentation is also easy, but have not yet looked into it as it currently unused from my POV. > > > > But i leave it as decision for Maintainer to drop this patch as it is not needed for my Board DTS. > > As both the current submission of the combophy driver and the gmac > driver do not support xpcs, I elected to remove the clock vice adding > documentation for something which is not currently supported. > This is especially true as it only leaked through for the gmac0 port, > the gmac1 port is modeled to the current support level. > > Once xpcs support is introduced, the clock can be added to the > documentation and both controllers as part of the same patch series. > > Do you concur, Heiko? Did you see my own reply from some hours ago? >From looking at the documentation I got the impression that the pclk_xpcs is related to the separate qsgmii_pcs in the memory map. So yes, I fully agree to dropping this clock from here and then adding them to whatever ip block really needs it. Heiko > > > === > > > > > > XPCS is also part of PD_PIPE. > > > See Rockchip RK3568 TRM Part1 V1.0-20210111.pdf page 475. > > > Please advise if the power-domain@RK3568_PD_PIPE does need a PCLK_XPCS > > > fix or is PCLK_PIPE enough in combination with a PHY driver? > > > > > > PD_PIPE: > > > > > > BIU_PIPE > > > USB3OTG > > > PCIE20 > > > PCIE30 > > > SATA > > > XPCS > > > > > > > > > power-domain@RK3568_PD_PIPE { > > > reg = ; > > > clocks = <&cru PCLK_PIPE>; > > > pm_qos = <&qos_pcie2x1>, > > > <&qos_pcie3x1>, > > > <&qos_pcie3x2>, > > > <&qos_sata0>, > > > <&qos_sata1>, > > > <&qos_sata2>, > > > <&qos_usb3_0>, > > > <&qos_usb3_1>; > > > #power-domain-cells = <0>; > > > }; > > > > PD_PIPE is imho also part of Naneng. But more for usage as USB3/SATA/... phy. This is not part of Mainline too. > > > > But thanks for pointing. > > > > regards Frank > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel