| Message ID | 1415885645-24613-1-git-send-email-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 13/11/14 15:34, Hans de Goede wrote: > +chosen { > + framebuffer0: framebuffer@5fc00000 { > compatible = "simple-framebuffer"; > - reg = <0x1d385000 (1600 * 1200 * 2)>; > + reg = <0x5fc00000 (4096 * 1024)>; Was there a reason for this change? The former version seems much more obvious to me, especially as this is an example. Tomi
Hi, On 11/13/2014 03:28 PM, Tomi Valkeinen wrote: > On 13/11/14 15:34, Hans de Goede wrote: > >> +chosen { >> + framebuffer0: framebuffer@5fc00000 { >> compatible = "simple-framebuffer"; >> - reg = <0x1d385000 (1600 * 1200 * 2)>; >> + reg = <0x5fc00000 (4096 * 1024)>; > > Was there a reason for this change? I changed the node name to match the new bindings text which specifies that the node name must be framebuffer@<address>, while at it I've taken a real world address range. I assume you refer to the bit where the size of the reg property is changed ? That indeed is not really necessary. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13/11/14 16:46, Hans de Goede wrote: > Hi, > > On 11/13/2014 03:28 PM, Tomi Valkeinen wrote: >> On 13/11/14 15:34, Hans de Goede wrote: >> >>> +chosen { >>> + framebuffer0: framebuffer@5fc00000 { >>> compatible = "simple-framebuffer"; >>> - reg = <0x1d385000 (1600 * 1200 * 2)>; >>> + reg = <0x5fc00000 (4096 * 1024)>; >> >> Was there a reason for this change? > > I changed the node name to match the new bindings text which > specifies that the node name must be framebuffer@<address>, > while at it I've taken a real world address range. > > I assume you refer to the bit where the size of the reg property > is changed ? That indeed is not really necessary. Yes, I meant the size of the reg prop. As this is an example, I think it should be as clear as possible. I guess a valid use case here is to set the size to larger-than-needed, so that it gets preallocated and you don't need to worry about getting the memory later when the system has already been running for a longer time. But if that's the case in this example, I think it would be better to describe it explicitly. Tomi
On Thu, Nov 13, 2014 at 3:52 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 13/11/14 16:46, Hans de Goede wrote: >> Hi, >> >> On 11/13/2014 03:28 PM, Tomi Valkeinen wrote: >>> On 13/11/14 15:34, Hans de Goede wrote: >>> >>>> +chosen { >>>> + framebuffer0: framebuffer@5fc00000 { >>>> compatible = "simple-framebuffer"; >>>> - reg = <0x1d385000 (1600 * 1200 * 2)>; >>>> + reg = <0x5fc00000 (4096 * 1024)>; >>> >>> Was there a reason for this change? >> >> I changed the node name to match the new bindings text which >> specifies that the node name must be framebuffer@<address>, >> while at it I've taken a real world address range. >> >> I assume you refer to the bit where the size of the reg property >> is changed ? That indeed is not really necessary. > > Yes, I meant the size of the reg prop. As this is an example, I think it > should be as clear as possible. > > I guess a valid use case here is to set the size to larger-than-needed, > so that it gets preallocated and you don't need to worry about getting > the memory later when the system has already been running for a longer > time. But if that's the case in this example, I think it would be better > to describe it explicitly. Besides, we already have a mechanism for that called /reserved-memory. Any memory used by a framebuffer needs to be described in the reserved map anyway, and that region can be made larger than the firmware configured framebuffer. g. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt index 8f35718..6c7339b 100644 --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt @@ -4,6 +4,31 @@ A simple frame-buffer describes a frame-buffer setup by firmware or the bootloader, with the assumption that the display hardware has already been set up to scan out from the memory pointed to by the reg property. +Since simplefb nodes represent runtime information they must be sub-nodes of +the chosen node (*). Simplefb nodes must be named "framebuffer@<address>". + +If a simplefb node represents the preferred console for user interaction, +then the chosen node's stdout-path property must point to it. + +If the devicetree contains nodes for the display hardware used by a simplefb, +then the simplefb node must contain a property called "display", which +contains a phandle pointing to the primary display hw node, so that the OS +knows which simplefb to disable when handing over control to a driver for the +real hardware. The bindings for the hw nodes must specify which node is +considered the primary node. + +It is advised to add display# aliases to help the OS determine how to number +things. If display# aliases are used, then if the simplefb node contains a +"display" property then the /aliases/display# path must point to the display +hw node the "display" property points to, otherwise it must point directly +to the simplefb node. + +It is advised that devicetree files contain pre-filled, disabled framebuffer +nodes, so that the firmware only needs to update the mode information and +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. + Required properties: - compatible: "simple-framebuffer" - reg: Should contain the location and size of the framebuffer memory. @@ -19,14 +44,36 @@ Optional properties: are expected to already be configured correctly. The OS must ensure these clocks are not modified or disabled while the simple framebuffer remains active. +- display : phandle pointing to the primary display hardware node Example: - framebuffer { +aliases { + display0 = &lcdc0; +} + +chosen { + framebuffer0: framebuffer@5fc00000 { compatible = "simple-framebuffer"; - reg = <0x1d385000 (1600 * 1200 * 2)>; + reg = <0x5fc00000 (4096 * 1024)>; width = <1600>; height = <1200>; stride = <(1600 * 2)>; format = "r5g6b5"; + clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; + display = <&lcdc0>; + }; + stdout-path = &framebuffer0; +}; + +soc@01c00000 { + lcdc0: lcdc@1c0c000 { + compatible = "allwinner,sun4i-a10-lcdc"; + ... }; +}; + + +*) Older devicetree files may have a compatible = "simple-framebuffer" node +in a different place, operating systems must first enumerate any compatible +nodes found under chosen and then check for other compatible nodes.