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. 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 the framebuffer, Linux just uses it. Just like you don't have a device/platform specific compatible for PSCI, SCPI, et al. And from a process standpoint, that driver is typically used years before we even get to writing a driver for the actual display driver. And since bindings are far from standard and actually pretty opionionated, even if we submitted a binding to use a proper binding without having a clear idea of what the hardware is, or what a driver would want, we would end up with either a broken binding, or a broken driver. Maxime
signature.asc
Description: PGP signature
