On 27/06/2025 11:48, Luca Weiss wrote:
Hi Krzysztof,And IMO they should not. Bindings are not supposed to be generic.
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:The bindings support an arbitrary number of clocks, regulators,
Document the interconnects property which is a list of interconnectmaxItems: 1, or this is not a simple FB anymore. Anything which needs
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@xxxxxxx>
Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
---
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.
+
some sort of resources in unknown way is not simple anymore. You need
device specific bindings.
power-domains. Why should I artificially limit the interconnects to only
one?
The driver code also has that support added in this series.That's not the problem here.
Best regards,
Krzysztof