Re: [PATCH v4 01/20] dt-bindings: phy: Add starfive,jh7110-inno-hdmi-phy

On 25/09/2026 23:05, Michal Wilczynski wrote:

quoted

quoted

+  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.

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.

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