Re: [PATCH v2 2/5] dt-bindings: Add a clocks property to the simple-framebuffer binding

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

 




Hi,

On 10/03/2014 03:20 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 6:52 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate this to the OS.
>>
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>> Reviewed-by: Mike Turquette <mturquette@xxxxxxxxxx>
>> ---
>>  Documentation/devicetree/bindings/video/simple-framebuffer.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> index 70c26f3..e75478e 100644
>> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
>> @@ -14,6 +14,9 @@ Required properties:
>>    - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
>>    - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>>
>> +Optional properties:
>> +- clocks : List of clocks used by the framebuffer
> 
> A simple framebuffer represents a memory region. So now you are saying
> this memory region has a clock. That does not make sense and the
> description of simple framebuffer is no longer correct.

Good point, I'll do a v3 updating the description changing it to:

"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 ref property."

> I assume you are trying to work around the clock framework turning off
> clocks on you. If you bothered to describe the clock such that it can
> be turned off by the kernel, you should then describe it's actual
> connection to the hardware.

In the parts of devicetree where we actually describe the hardware yes,
for the simplefb virtual device it suffices to simple list the used
clocks. Note that a display pipeline often consists of multiple hw-blocks,
so there is not 1:1 mapping between the involved hardware blocks and
the simplefb. The blocks (and clocks) used my even differ between boots
depending on which video output the firmware / bootloader has setup.

> Furthermore, when you do add actual driver(s) for the hardware, that
> driver will not be able to turn off the clocks because the simplefb
> has forced them on. I can see the cases where you want to use
> simple-framebuffer early for splash screen or something before the
> real driver is up and use it to provide the default video mode for the
> real driver.

When we get a real driver, that will (and must) unregister simplefb, at
which point simplefb will release the clocks, and from then on that real
driver can turn off the clocks just fine.

Regards,

Hans

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