dt-bindings: simplefb: Document naming scheme for pre-populated simplefb nodes
Subsystems (2)
PATCH 1/1 dt-bindings: simplefb: Document naming scheme for pre-populated simplefb nodes
Since we advice to use pre-populated simeplfb nodes in dt files, where the firmware then only needs to fill in the mode info + address and enable it, we should also specify how these pre-populated nodes should be named so that the firmware can find and enable the right one.
--- Documentation/devicetree/bindings/video/simple-framebuffer.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/devicetree/bindings/video/simple-framebuffer.txt +7 -0
@@ -29,6 +29,13 @@ enable them. This way if e.g. later on support for more display clocks get added, the simplefb nodes will already contain this info and the firmware does not need to be updated. +If pre-filled framebuffer nodes are used, they should be named +"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be +included in the name since different outputs typically require different +clocks and the clocks are part of the pre-populated nodes. The firmware must +rename the nodes to the standard "framebuffer@<address>" using the runtime +chosen address when enabling the nodes. + Required properties: - compatible: "simple-framebuffer" - reg: Should contain the location and size of the framebuffer memory.
Signature · 1 line
2.1.0
PATCH 1/1 dt-bindings: simplefb: Document naming scheme for pre-populated simplefb nodes
Quoted 15 lines · Hans de Goede
Since we advice to use pre-populated simeplfb nodes in dt files, where the firmware then only needs to fill in the mode info + address and enable it, we should also specify how these pre-populated nodes should be named so that the firmware can find and enable the right one.
Signed-off-by Hans de Goede <[email protected]>--- Documentation/devicetree/bindings/video/simple-framebuffer.txt | 7 +++++++ 1 file changed, 7 insertions(+)Documentation/devicetree/bindings/video/simple-framebuffer.txt +0
-0
Documentation/devicetree/bindings/video/simple-framebuffer.txt enable them. This way if e.g. later on support for more display clocks get · line 37
Quoted 9 lines
Documentation/devicetree/bindings/video/simple-framebuffer.txt +6
-0@@ -29,6 +29,13 @@ enable them. This way if e.g. later on support for more display clocks get added, the simplefb nodes will already contain this info and the firmware does not need to be updated. +If pre-filled framebuffer nodes are used, they should be named +"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be +included in the name since different outputs typically require different +clocks and the clocks are part of the pre-populated nodes. The firmware must +rename the nodes to the standard "framebuffer@<address>" using the runtime +chosen address when enabling the nodes.
-<output> should be optional, an only used when there are multiple options.
Something we've not talked about is how to handle a framebuffer that has been set up with mirrored displays. Does that case matter?
g.
PATCH 1/1 dt-bindings: simplefb: Document naming scheme for pre-populated simplefb nodes
Hi,
Quoted 19 lines · Grant Likely
Quoted 18 lines · Hans de Goede
Since we advice to use pre-populated simeplfb nodes in dt files, where the firmware then only needs to fill in the mode info + address and enable it, we should also specify how these pre-populated nodes should be named so that the firmware can find and enable the right one.
Signed-off-by Hans de Goede <[email protected]>--- Documentation/devicetree/bindings/video/simple-framebuffer.txt | 7 +++++++ 1 file changed, 7 insertions(+)Documentation/devicetree/bindings/video/simple-framebuffer.txt +0
-0@@ -29,6 +29,13 @@ enable them. This way if e.g. later on support for more display clocks get added, the simplefb nodes will already contain this info and the firmware does not need to be updated.
Quoted 8 lines
Documentation/devicetree/bindings/video/simple-framebuffer.txt enable them. This way if e.g. later on support for more display clocks get · line 37
Quoted 6 lines
Documentation/devicetree/bindings/video/simple-framebuffer.txt +6
-0+If pre-filled framebuffer nodes are used, they should be named +"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be +included in the name since different outputs typically require different +clocks and the clocks are part of the pre-populated nodes. The firmware must +rename the nodes to the standard "framebuffer@<address>" using the runtime +chosen address when enabling the nodes.-<output> should be optional, an only used when there are multiple options.
Right, notice the "should be named", I would rather leave it at that then complicate the wording by adding something about only use -output when there are multiple options.
Quoted 2 lines
Something we've not talked about is how to handle a framebuffer that has been set up with mirrored displays. Does that case matter?
It is bound to happen sooner or later I guess, but it is still just a single framebuffer, so from the simplefb kernel driver pov it does not matter, it really is just another variant on the -<output> theme where there happen to be 2 outputs active at the same time.
Regards,
Hans
Quoted 3 lines
g.