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:
...
On Tegra, there are two DTBs:
The first is attached to the U-Boot image, and parameterizes U-Boot itself. The bindings used in this are often quite different from the kernel:-(
[snip]
Perhaps the two should be unified, although there isn't much interest in bringing the U-Boot DT content up to scratch, it seems:-( I would just ignore the U-Boot copy for now, and treat it as an internal implementation detail of U-Boot.
I would very much like to see them unified and used more in U-Boot. Most U-Boot development is about scratching ones own itch, is the biggest hurdle towards mass conversion to DTs (followed by the number of platforms that aren't being updated to DT in the kernel, followed by needing more conversion done in the kernel, bindings finalized, etc).
I was mainly talking about the people specifically working on Tegra support in U-Boot rather than U-Boot as a generality.
Right. And with my U-Boot guy hat on, I want to be clear that this is a direction I want to see the project move in, once things have settled down a bit with the kernel side of things (since we'll have our own headaches like "how little of the system can we hard-code" and "how can we merge device trees, or do we discard that first one?").
...
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:
- 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.
- 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?