[U-Boot] [linux-sunxi] Re: [PATCH] video: add cfb console driver for sunxi

[Luc Verhaegen]

On Mon, Aug 04, 2014 at 05:31:36PM +0200, Henrik Nordström wrote:
> mån 2014-08-04 klockan 17:05 +0200 skrev Luc Verhaegen:
> > But... What do we do when u-boot sets up cfb, without setting up a
> > simplefb node in the dt. Or what do we do when a simplefb node is set 
> > up, but no simplefb code is included in the kernel? Well, we then either 
> > need to claim the clocks, and make sure that nothing else touches the 
> > memory, or we need to cleanly disable the display engine. But which do 
> > we choose, do we keep the u-boot output forever, or do we sync off when 
> > the kernel starts?
> 
> And what happens if we simply ignore it? Is there a risk of anything
> burning beyond software repair? If not, ignore it. There is no need to
> support all incompatible mixes even if it means some people will see
> strange fireworks on their screens when not following the software
> requirements.
> 
> It's really no different from booting a kernel with wrong dt, or using a
> u-boot with wrong DRAM settings etc. An incompatible mix which is not
> meant to function properly.
> 
> If you use a u-boot with this framebuffer support then you must also
> either use a kernel which supports being booted in such state, or make
> sure u-boot shuts things off before handing over to the kernel.
> 
> If we can handle the situation gracefully in the kernel then fine, but
> it's by no means required, or even desired to spend any effort or even
> any serious thoughts on before compatible setups works.
> 
> Regards
> Henrik

We can work around most situations gracefully in kernelspace. We should 
for instance never set a bad mode, and never show random memory content, 
as that is a total no-go. So some code will have to exist to cleanly 
disable the display engine (we're in luck, we only need to poke the ahb 
gating and some clocks).

But if we can overlook some of the above, we also should just consider 
the memory lost until a kms driver kicks in, and ioremaps/whatevers it 
for its own use.

How's this for the sunxi implementation of simplefb:
* u-boot lists used clocks, to allow some code in simplefb.c to grab all 
  clocks. This is necessary as the list of clocks might change with 
  changed cfb-console driver functionality.
* when the clocks get disabled, the existing display engine setup 
  becomes useless. the dt simplefb node has its status set to disabled. 
  The memory range info remains, none of the reserved ram is returned 
  to system. This needs to happen in both simplefb.c and in clk-sunxi.c.
* when the memory range gets mapped by the kms driver (currently, on 
  sunxi-3.4 i just use the full disp driver reserved range directly) in 
  a way that it will be released again at unload, the memory range info 
  remains. This ensures that future kms driver reloads can still grab 
  this memory.
* when however the memory range gets mapped to cma globally, the memory 
  range info is removed.

It makes sense to add the clock handling and the disabling of the
simple-framebuffer node in the actual simplefb driver. The memory 
handling should be considered platform specific behaviour for now, but 
perhaps dt reserved memory infrastructure can come to the rescue in 
future.

Luc Verhaegen.