From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) (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 580D536197E; Sat, 3 Oct 2026 22:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.118.77.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791066970; cv=none; b=kwM/R1j/KuLZFfxlQZopDqTxCTcc3f4mh7bDVwdA/xj5jD17sleexOfPX13x6S0opd80XaaDhhKp+VjTEY/AapJ87MJIEm6unr+J+82jr5lzgavh5Ep6K4kYN3udYpurfh1rI4vdJUs2JyBriQBTO6Gpy/dJfRcXIO3hxRZojxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791066970; c=relaxed/simple; bh=rkgSeiuS4dwhrsy2rkYqxUTiiIo2ge/+uxBwSHcNmBc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To: Content-Type:References; b=h3HuP16B2khe3CjBPvTx56y0SZfKTZ/RkdWVTuE+jsWOcP7Z6GKpBr9getS3y/td7cn417N1v98o63sxIVeUxToG1Vc5Uw7FoBiHteN/Jxp2Ycl5rRtQfS1TU2NtfdFv1847gn6WoWqlfyDQZ8R5cXWXCEkqxfkJH3/gI6zTKPk= 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=s+ttd66V; arc=none smtp.client-ip=210.118.77.12 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="s+ttd66V" Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20261003223559euoutp025c12500faec891b33d1895efec774da0~bJej50LOi2979329793euoutp02W; Sat, 3 Oct 2026 22:35:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20261003223559euoutp025c12500faec891b33d1895efec774da0~bJej50LOi2979329793euoutp02W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1791066959; bh=U3wvj1HZXvSFEqnxTHNRHB1lpN/qwUATGcRBe6uZy5E=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=s+ttd66VboYyGUSjzBv7F9IX2SuCBaJhFEnDHEhqvuOOeO3iV7tsKpo2xRAiGmACk nqccU/5pfph9t+/O5NfG7oJLVN/ERgwwZhnv5V7OBd8Gw10F6uQRnUeXg0TDAqoawV vIKIwNfyoQcs1aNgJ7jQnwNVRcoQEywfr2xjQb9g= Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20261003223558eucas1p2cb1d410a774401ec0c3c69c1f59d658d~bJei3nizz0619606196eucas1p2v; Sat, 3 Oct 2026 22:35:58 +0000 (GMT) Received: from [192.168.1.44] (unknown [106.210.136.40]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20261003223556eusmtip1c175f34ccabf55dbdb34e5940f15ffe5~bJeg2dql11552315523eusmtip1K; Sat, 3 Oct 2026 22:35:56 +0000 (GMT) Message-ID: <3c5c15d9-ea7e-49a2-adae-ec3e3c72594b@samsung.com> Date: Sun, 4 Oct 2026 00:35:55 +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: <3ee91c92-4e3a-4bac-85cf-923f5d77ceff@kernel.org> Content-Transfer-Encoding: 7bit X-CMS-MailID: 20261003223558eucas1p2cb1d410a774401ec0c3c69c1f59d658d 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> <3ee91c92-4e3a-4bac-85cf-923f5d77ceff@kernel.org> On 10/3/26 22:45, Krzysztof Kozlowski wrote: > On 03/10/2026 17:36, Michal Wilczynski wrote: >> >> >> 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. > > There is no cycle. Internal signals to the block are not represented in DT. > > What you have is a driver problem and you create some sort of DT > structure to solve that. DT purpose is NOT to solve your driver > dependencies or circular connections. The structure is not something I added. The voutcrg binding has required an input clock named hdmitx0_pixelclk since it was merged in 2023 a097a5ec14df ("dt-bindings: clock: Add StarFive JH7110 Video-Output clock and reset generator") and this series does not touch that file: Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml - const: hdmitx0_pixelclk Mainline satisfies it with a placeholder, because so far nothing provided the real clock: hdmitx0_pixelclk: hdmitx0-pixel-clock { compatible = "fixed-clock"; clock-output-names = "hdmitx0_pixelclk"; #clock-cells = <0>; }; All this series does is point that existing input at the device that actually generates it. TRM [1] table 5-3 on page 529 lists the display CRG's input clocks. Most come from dom_vout_top, but three come from IP blocks inside the subsystem: clk_hdmitx0_pixelclk 297 MHz u0_hdmi_tx.clk_pix clk_mipitx_dphy_rxesc 10 MHz u0_mipitx_dphy.clk_rxesc clk_mipitx_dphy_txbytehs 297 MHz u0_mipitx_dphy.clk_txbytehs and on page 530 the CRG offers clk_hdmitx0_pixelclk as Source1 for: u0_dc8200.clk_pix0 Source0 clk_dc8200_pix0 Source1 clk_hdmitx0_pixelclk u0_dc8200.clk_pix1 Source0 clk_dc8200_pix0 Source1 clk_hdmitx0_pixelclk u0_cdns_dsiTx.clk_dpi Source0 clk_dc8200_pix0 Source1 clk_hdmitx0_pixelclk The DC8200 and the DSI TX are separate devices, so the pixel clock crosses two block boundaries to reach them. That is also why the DT has to be able to name it. Those MUXes have two parents and the selection is made in DT: &dc8200 { assigned-clocks = <&voutcrg JH7110_VOUTCLK_DC8200_PIX0>, ...; assigned-clock-parents = <&hdmi_phy>, <&hdmi_phy>; }; and voutcrg takes it as an input clock because that is what the hardware does. If the PHY is folded into the HDMI node, that input phandle points at a node which also consumes pclk/mclk/bclk from voutcrg. That is where the cycle comes from - the hardware topology not the driver. [1] - https://doc-en.rvspace.org/JH7110/PDF/JH7110_TRM_StarFive_Preliminary_V2.pdf > > Best regards, > Krzysztof > Best regards, -- Michal Wilczynski