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 <[email protected]> > >>>>>>> Signed-off-by: Luca Weiss <[email protected]> > >>>>>>> --- > >>>>>>> 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
signature.asc
Description: PGP signature
