[PATCH v4 0/5] simplefb: add clock handling code

[Grant Likely]

On Wed, Nov 12, 2014 at 10:08 AM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> Hi Grant,
>
> On Wed, Nov 12, 2014 at 10:57 AM, Grant Likely <grant.likely at linaro.org> wrote:
>> On Wednesday, November 12, 2014, Geert Uytterhoeven
>> <geert at linux-m68k.org> wrote:
>>> On Tue, Nov 11, 2014 at 10:49 PM, Grant Likely <grant.likely at linaro.org> wrote:
>>> > However, I am concerned about handover. I've lost track over the entire
>>> > thread on whether the handover mechanism has been resolved, and I would
>>> > really like to have a proposed solution to this documented in the
>>> > binding. The fact that there is nothing tying the simple framebuffer to
>>> > the actual hardware backing the framebuffer is concerning. It means the
>>> > kernel needs to guess which graphics device is associated with the
>>> > framebuffer.
>>>
>>> We did discuss handover in Düsseldorf, and concluded that the simplefb's
>>> regs property can be used for this.
>>>
>>> While on a modern system with unified memory this association cannot be
>>> derived in a generic way, a device-specific driver for the graphics hardware
>>> can if the regs property of the simplefb node matches the address the CRTC
>>> engine is configured for.
>>
>> ???
>>
>> Right, I'm going to be blunt here: That's just dumb. All the
>> capability needed is there in the DT to associate a simple FB to a
>> display controller, and the solution chosen is to use a heuristic?
>>
>> The association needs to be explicit. I strongly prefer putting the
>> simple FB directly into the display controller node, but I would
>> consider phandle linkage also.
>
> IFF there's a display controller node, you can put it there.
> I actually proposed to have a minimal/preliminary display controller node,
> but people countered that for various reasons (too many components
> with multiple nodes on many systems, bindings not yet defined, etc.).
>
> And if there's no graphics driver/bindings yet at the time the bootloader
> is written, it doesn't know how to link simplefb with it in DT.
> Hence the heuristic to match regs... Does that make sense?

No, not really. The simplefb binding /should/ make it clear that
handover to the real display controller driver is an expected use
case; therefore the simplefb binding should itemize exactly how that
linkage is supposed to be expressed. When the display controller
binding is written, it should go hand in glove with the simplefb
binding. We want to be sure that generic code can be used to resolve a
display controller with (one of) the simple framebuffers.

It also sounds like some are making the assumption that firmware
should generate the simplefb node from scratch, hence all the hand
wringing about firmware not knowing what extra stuff to put into the
simplefb node. I don't think this is necessary, or even a good
approach. A disabled simplefb node can be put into the dts file with
any dependencies it needs to care about and linkage to the real
display controller. Firmware should be able to locate that node,
update the parameters as needed, and enable it. That gets out of the
cycle of updating firmware in lockstep.

g.