From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28A4B2DECC2; Sat, 3 Oct 2026 15:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.118.77.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791041801; cv=none; b=AnqtaRX5KbOptvo+NIKLCJrCAJGx83dfr6r1hMA7i84+ud31YUdDl8A+bC/imdweQOcyX2Xcr1/BzTcyPB2FfRU6X5d2O6EbVsT7FjrITtJTNfPVTBBJ5PItSEM0978Mf4NPYNlJC6HNpiTfkQOO1M727+2iVZZb//AG9vZKMKE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791041801; c=relaxed/simple; bh=R1SaWeYMMbeZGDSXBSN/rMNKOG6/CCkSASIw2cgwwEU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To: Content-Type:References; b=dWL1H0u+2GtDah2FUF/scbMmzFYuWTU2h0tf65bm/DyvdxnusMKQ/JeDBKdnsRxuOOSYra4GdfbaRWAMQsVgCO6k/FQwsG9uejp91blp0PYfJW/ZU3/usMFNkHotTAhK8J96yVMpM+TWdkQ7buz8IKIIK9YkdniIo4GWrbJ9vW4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=iyRdI8uv; arc=none smtp.client-ip=210.118.77.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="iyRdI8uv" Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20261003153628euoutp012ff25533234c428be9ff26b1fae8bcaf~bDwR0T6ER1714317143euoutp01W; Sat, 3 Oct 2026 15:36:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20261003153628euoutp012ff25533234c428be9ff26b1fae8bcaf~bDwR0T6ER1714317143euoutp01W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1791041788; bh=cezTBuZnRU09BC5t/TXbbnr/2mOgRJXIrT1bA9nKYfk=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=iyRdI8uvT1VnyJT6tqgggenZI6nITXILkxQtf0XryX352UU+lQidWIGBUPATnmApl NqErh1NgfRSaacsdX3dVtsHcj+ObkGldlks/K3Pp/ACh4wuzlI3nw9I71uwYTuobcz MAqgn33qV3D/4uufZns8VtPAgjSZZJfnfsm8yK1Y= Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20261003153627eucas1p1f4cc5dc15e7a5dbebdfb26617afe1f56~bDwQpLxK00845508455eucas1p1j; Sat, 3 Oct 2026 15:36:27 +0000 (GMT) Received: from [192.168.1.44] (unknown [106.210.136.40]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20261003153625eusmtip1ba5f07ce91f2ac9a6e0ffa2ce26ac1cb~bDwPATbZ22801128011eusmtip1E; Sat, 3 Oct 2026 15:36:25 +0000 (GMT) Message-ID: Date: Sat, 3 Oct 2026 17:36:25 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/20] dt-bindings: phy: Add starfive,jh7110-inno-hdmi-phy To: Krzysztof Kozlowski Cc: Vinod Koul , Neil Armstrong , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lee Jones , Andy Yan , Philipp Zabel , Emil Renner Berthing , Hal Feng , Michael Turquette , Stephen Boyd , Heiko Stuebner , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Dominique Belhachemi , Brian Masney , Jerome Brunet , linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mfd@lists.linux.dev, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-riscv@lists.infradead.org, Marek Szyprowski , Maud Spierings , Graham Markall , Icenowy Zheng , Chaoyi Chen , Joshua Peisach , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= Content-Language: en-US From: Michal Wilczynski In-Reply-To: <6cf9e611-bfc5-407b-8132-bd328f8b61fc@kernel.org> Content-Transfer-Encoding: 7bit X-CMS-MailID: 20261003153627eucas1p1f4cc5dc15e7a5dbebdfb26617afe1f56 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20260915153214eucas1p2b548f3236ef98fb0cbf320e397420125 X-EPHeader: CA X-CMS-RootMailID: 20260915153214eucas1p2b548f3236ef98fb0cbf320e397420125 References: <20260915-jh7110-clean-send-v4-0-f0e4fd6f2cc8@samsung.com> <20260915-jh7110-clean-send-v4-1-f0e4fd6f2cc8@samsung.com> <20260917-mutant-chamois-of-competence-46ca77@quoll> <1a1a9b49-430b-4218-b27d-e133d488e8d9@samsung.com> <6cf9e611-bfc5-407b-8132-bd328f8b61fc@kernel.org> On 9/30/26 13:01, Krzysztof Kozlowski wrote: > On 25/09/2026 23:05, Michal Wilczynski wrote: >>>> + clocks: >>>> + maxItems: 1 >>>> + description: Reference oscillator. >>> >>> This barely counts as a resource, so usual question: no resources here? >>> no MMIO? Even the user of this phy is the block itself. >>> >>> This makes me wonder if this should be a device node in the first place >>> (instead folded into the parent). >> >> The PHY has no reg because the reg is shared with the controller and >> owned by the parent - patch 9 lets the bridge take its regmap from >> there. >> >> The user of the PHY is not only the block itself. It is the pixel clock >> provider for the whole display subsystem, voutcrg takes hdmitx0_pixelclk >> as the parent of its DC8200 pixel MUXes, and while HDMI output is active >> it is the only intended source for that clock. The parent has to be >> assigned explicitly so the general PLL does not end up driving the pixel >> clock, and so a DSI user does not reach the HDMI PHY clock generator. >> >> So it has to be its own node. The HDMI block has two independent > > I do not see the logic which lead to this conclusion. Pixel clock > provider, so a clock controller, cannot be a user of a phy. Clock > controller does not have a physical layer. Sorry I think the wording was not perfect. I meant the PHY node is a pixel clock provider. voutcrg consumes a clock not a PHY. voutcrg: clock-controller@295c0000 { clocks = <&syscrg ...>, <&hdmi_phy>; clock-names = ...,"hdmitx0_pixelclk"; }; The consumer of the PHY is only the hdmi controller. What matters for the node layout is where that clock goes. voutcrg is the SoC display clock controller - it is not part of the HDMI block: hdmi_phy -- pixel clock -> voutcrg | - pclk/mclk/bclk -> hdmi_controller - pix0/pix1 -> dc8200 hdmi_phy and hdmi_controller are the same register block with one reg owned by the parent. So if that block is described as a single node: hdmi_node - pixel clock -> voutcrg ^ | --- pclk/mclk/bclk -------- the node provides a clock to voutcrg and consumes three clocks from voutcrg. That is a cycle in the device tree description. Split in two there is no cycle: the PHY's only input is xin24m - the 24 MHz oscillator which gives a linear order - hdmi_phy, voutcrg, hdmi_controller. > > And really, I have no clue what hdmitx0_pixelclk and voutcrg are. I > could probably study the patches a lot to figure that out, but my review > queue has still 200 more, so I'll skip. > > But nevertheless assigning clock parent of HDMI clock to PHY is > standard, most of the platforms have it, thus it is not a justification > for odd design. Agreed and that is what this is - I followed RK3328, which uses the same Innosilicon IP and also describes it as two nodes: hdmi: hdmi@ff3c0000 clocks = <&cru PCLK_HDMI>, ... hdmiphy: phy@ff430000 clocks = <&cru PCLK_HDMIPHY>, <&xin24m>, <&cru DCLK_HDMIPHY> clock-output-names = "hdmi_phy"; #clock-cells = <0>; #phy-cells = <0>; The only difference is reg: RK3328 has two register ranges, the JH7110 has one, so the parent owns it and the children have none. > >> functions with different clock inputs and one of them feeds back into >> the SoC clock tree. The PHY generates hdmitx0_pixelclk which voutcrg >> consumes the controller consumes pclk/mclk/bclk from voutcrg. Folded >> into one node that node is both a provider to and a consumer of >> voutcrg which is a cycle in the hardware description, not just in Linux. > > > Best regards, > Krzysztof > Best regards, -- Michal Wilczynski