On Fri, Aug 15, 2014 at 2:43 AM, Maxime Ripard
[off-list ref] wrote:

On Thu, Aug 14, 2014 at 09:27:14PM -0400, jonsmirl at gmail.com wrote:

quoted

On Thu, Aug 14, 2014 at 8:45 PM, Henrik Nordstr?m
[off-list ref] wrote:

quoted

tor 2014-08-14 klockan 08:07 -0400 skrev jonsmirl at gmail.com:

quoted

So what are the rules going to be? Once the OS is up and starts
changing things the state in the DT and the OS are going to diverge.
How does this get handled for a kernel driver that can load/unload?
Should the kernel remove those state nodes as soon as it alters the
state?

hardware that is no longer there should also not be represented/active
in DT.

A simple fb that have been torn down is no more, no different from never
having been there. It can be argued that it never was in the first place
(i.e. that it is not actually hardware) but that it another can of worms
and both have their benefits and drawbacks. One thing is certain
however, as far as simplefb is concerned it is hardware, not really any
different from a persistent framebuffer with hardwired settings in
hardware.

How does the kernel know what clocks to protect? A list in the
simplefb node?  This list of clocks is a reason for adding simplefb to
the compatible list for the real hardware.  That way it won't be
duplicated.

The issues with parameter conflicts between simplefb and the real
hardware can be dealt with.  If the real hardware wants to add the
simplefb compatible field it will need to get its parameters sorted
out so that they don't conflict. Clock syntax is standardized in the
DTS so it shouldn't be a problem.

It shouldn't be, but apparently, some disagree.

Anyway, I'm not sure having the simplefb compatible would work in this
use-case, mainly for two reasons:
  - Most likely, the bindings are going to be very different. Not only
    about which properties you'll have, but also what you will place
    in these properties. reg for example have the memory address of
    the buffer in the simplefb case, while in the KMS driver case, it
    would have the memory address of the registers.
  - There's will be a single driver probed. So if you want to go down
    the hand over road (which is a bit premature at this point if you
    ask me, but anyway), you will have no driver probed to hand over
    to.

The graphic drivers have already been down this road before. Simplefb
should be a driver library not a driver. DRM is also a driver library.

So to implement simplefb whip up a real skeleton driver for the video
hardware that parses the DT and then pokes the appropriate info into
the simplefb library. Initially that driver will just include the
calls out to the simplefb library. Later on it can get KMS
implemented.  This real driver will get bound to the hardware and have
a dependency that loads the simplefb driver library.

Now there is no handover problem. Only a single driver is ever
attached to the hardware. When it wants to go into KMS mode it makes a
call into the simplefb library to shut down whatever it is doing.

But you still need a mechanism for uboot to signal that it has set up
simplefb. Adding a dynamic node like this might work...

video0: video at 01c21800 {
   compatible = "allwinner,sun4i-a10-video";
   clocks = <&apb0_gates 6>, <&ir0_clk>;
   clock-names = "apb", "video";
   interrupts = <0 5 4>;
   reg = <0x01c21800 0x40>;
   status = "enabled";
   simplefb {
       new namespace for simplefb parameters
   }
};

I would have suggested a driver library earlier but it has been a
while since I worked on DRM and I forgot about it.

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
Jon Smirl
jonsmirl at gmail.com