Re: [PATCH] dt-bindings: simplefb: Document naming scheme for pre-populated simplefb nodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

On 11/14/2014 10:12 AM, Grant Likely wrote:
> On Fri, Nov 14, 2014 at 9:02 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>> 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 <hdegoede@xxxxxxxxxx>
>> ---
>>  Documentation/devicetree/bindings/video/simple-framebuffer.txt | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index c548f33..01dc948 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -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.

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.

> 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



> 
> 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux