[PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property

[Maxime Ripard]

On Mon, Jun 30, 2025 at 11:36:51AM +0200, Krzysztof Kozlowski wrote:
> On 30/06/2025 10:38, Maxime Ripard wrote:
> > On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
> >> On 29/06/2025 14:07, Hans de Goede wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
> >>>> On 27/06/2025 11:48, Luca Weiss wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
> >>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
> >>>>>>> Document the interconnects property which is a list of interconnect
> >>>>>>> paths that is used by the framebuffer and therefore needs to be kept
> >>>>>>> alive when the framebuffer is being used.
> >>>>>>>
> >>>>>>> Acked-by: Thomas Zimmermann <tzimmermann at suse.de>
> >>>>>>> Signed-off-by: Luca Weiss <luca.weiss at fairphone.com>
> >>>>>>> ---
> >>>>>>>  Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
> >>>>>>>  1 file changed, 3 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> @@ -79,6 +79,9 @@ properties:
> >>>>>>>    power-domains:
> >>>>>>>      description: List of power domains used by the framebuffer.
> >>>>>>>  
> >>>>>>> +  interconnects:
> >>>>>>> +    description: List of interconnect paths used by the framebuffer.
> >>>>>>> +
> >>>>>>
> >>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
> >>>>>> some sort of resources in unknown way is not simple anymore. You need
> >>>>>> device specific bindings.
> >>>>>
> >>>>> The bindings support an arbitrary number of clocks, regulators,
> >>>>> power-domains. Why should I artificially limit the interconnects to only
> >>>>> one?
> >>>>
> >>>> And IMO they should not. Bindings are not supposed to be generic.
> >>>
> >>> The simplefb binding is a binding to allow keeping the firmware, e.g.
> >>> uboot setup framebuffer alive to e.g. show a boot splash until
> >>> the native display-engine drive loads. Needing display-engine
> >>> specific bindings totally contradicts the whole goal of 
> >>
> >> No, it does not. DT is well designed for that through expressing
> >> compatibility. I did not say you cannot have generic fallback for simple
> >> use case.
> >>
> >> But this (and previous patchset) grows this into generic binding ONLY
> >> and that is not correct.
> > 
> > Can we have a proper definition of what a correct device tree binding is
> > then?
> > 
> > It's a bit surprising to have *that* discussion over a binding that is
> > now well older than a decade now, and while there is definitely some
> > generic bindings in ePAPR/DT spec, like the CPU ones.
> 
> Hm? In ARM world at least they are specific, e.g. they have specific
> compatibles.
> 
> > 
> > If you don't consider that spec to be correct DT bindings, please
> > provide a definition of what that is, and / or reasonable alternatives.
> > 
> > Also, no, a device specific binding isn't reasonable here, because we
> > *don't* have a device. From a technical standpoint, the firmware creates
> 
> You touch internal parts of the SoC and you list very specific SoC
> parts. Interconnect is internal part of the SoC and only specific
> devices are using it.
> 
> You define here generic SW construct for something which is opposite of
> generic: the interconnect connecting two specific, unique components of
> one, given SoC.
> 
> > the framebuffer, Linux just uses it. Just like you don't have a
> > device/platform specific compatible for PSCI, SCPI, et al.
> 
> They follow some sort of spec and still they do not reference chosen
> SoC-design-specific properties.

ish.

I mean, on theory, you're absolutely correct. In practice,
assigned-clock-parents, assigned-clock-rates, or protected-clocks for
example exist and are *only* about SoC-design specific behaviours.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250630/5fbf08f8/attachment.sig>