Re: [RFC] Best practices for hardware shipping device trees

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/15/2013 12:56 PM, Tom Rini wrote:
> On Thu, Aug 15, 2013 at 11:31:54AM -0600, Stephen Warren wrote:
>> On 08/15/2013 10:37 AM, Tom Rini wrote:
>>> On Thu, Aug 15, 2013 at 09:30:01AM -0600, Stephen Warren wrote:
...
>>>> We certainly expect U-Boot to update the DT that's passed to the kernel,
>>>> for:
>> ...
>>>> * Possibly to add a "simplefb" node, until the kernel has LCD panel
>>>> support (CDF).
>>>
>>> Can we talk about that last one more?  That sounds like some sort of
>>> temporary binding.  Or am I using the terms wrong?  But, it sounds like
>>> we're saying add whatever nodes might be missing?
> [snip useful explanation of what simplefb is]
>> simplefb information could get into DT in a couple ways:
>>
>> 1) The DTB for the platform could include the simplefb node right from
>> the start.
>>
>> This model would be appropriate for more permanent use of simplefb,
>> since the node appears in the orignial DT.
>>
>> In this case, the bootloader would at least have to fill in the physical
>> memory address of the frame-buffer that it allocated. If the display is
>> device with variable resolution, rather than a fixed built-in LCD, the
>> bootloader would also have to fill in the resolution properties.
>>
>> 2) The DTB for the platform doesn't include the simplefb node.
>>
>> This would be appropriate for platforms that use simplefb as a temporary
>> step until complete OS support for the display HW is present, so a real
>> driver can be used. This prevents DTBs from ever having the
>> soon-to-be-removed simplefb node encoded into them.
>>
>> In this case, the bootloader would have to add a completely new simplefb
>> node to the DT, and fill in all the properties.
> 
> OK, now why wouldn't the right thing to do here be to #1 and later in
> time, the DT is updated when the better drivers are merged in?
> 
> I don't think it's strictly a bad thing to say that firmware/bootloader
> is allowed to construct temporary nodes, but we should make it clear
> when that's an OK practice.  Yes?

For systems where simplefb is a transitional measure (i.e. where it
would eventually make sense to define a complete binding for the HW),
I'd prefer to avoid churn in the *.dts files by never including the
simplefb node in them, but rather adding it dynamically. In other words,
we don't add something to the file just to take it away later.

That's the logic behind why I wrote separate "add node" and "fill in
node" functions for the simplefb in U-Boot.

One thing that's slightly different about simplefb is that the node
isn't useful without the bootloader filling in some information, which
generally isn't true of DT content.

It'd certainly be technically possible to just add the simplefb node
into DT in all cases, then swap it out later when something else came along.