On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
<maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
>> If pre-filled framebuffer nodes are used, the firmware may need extra
>> properties to find the right node. This documents the properties to use
>> for this on sunxi platforms.
>>
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>> ---
>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> new file mode 100644
>> index 0000000..84ca264
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> @@ -0,0 +1,33 @@
>> +Sunxi specific Simple Framebuffer bindings
>> +
>> +This binding documents sunxi specific extensions to the simple-framebuffer
>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>> +pre-populated simplefb nodes.
>> +
>> +These extensions are intended so that u-boot can select the right node based
>> +on which pipeline and output is being used. As such they are solely intended
>> +for firmware / bootloader use, and the OS should ignore them.
>> +
>> +Required properties:
>> +- compatible: "sunxi,framebuffer"
>> +- sunxi,pipeline:
>> + <0> for the de_be0 -> lcdc0 -> output pipeline
>> + <1> for the de_be1 -> lcdc1 -> output pipeline
>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
>> +
>> +Example:
>> +
>> +chosen {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + framebuffer@0 {
>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
>> + sunxi,pipeline = <0>;
>> + sunxi,output = "hdmi";
>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
>> + <&ahb_gates 44>;
>
> If we're going that way, then maybe having to specify clock-names
> would be better in order to know which clock is what?
I wouldn't go that way with this binding since the driver has no need
to differentiate between the clocks, and driver authors shouldn't be
encouraged to do so. The purpose of the clocks in this node is only
for itemizing dependencies, not for how to configure the clocks.
Firmware shouldn't care at all about the clocks list, it only needs to
find the correct pre-populated node to fill in and enable.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
