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

[Maxime Ripard]

On Tue, Aug 05, 2014 at 12:10:30AM +0200, Henrik Nordström wrote:
> > 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.
> 
> Is this list of clocks in any way different from what KMS needs to use?

Not really, but Luc haven't been using all the clocks that might be
used by the KMS driver, and just uses a subset of it.

> > * 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.
> 
> Disabled by whom?

Linux' clock framework.

> > * 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.
> 
> Why do a KMS reload need to be able to grab the same memory again? The
> display is shut off when the KMS driver is unloaded, right? Or this only
> temporary?
> 
> > * 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.
> 
> Maybe, but people who need framebuffer in u-boot likley need it in
> kernel as well I would think, so I do not worry much about releasing the
> memory back to kernel for general purpose use if it has been reserved by
> u-boot.
> 
> If you really have no use of the display then don't enable it in the
> first place (or make sure it's shut off). Including any memory
> reservations.
> 
> Similar to PC BIOS settings for reserved (shared) memory on many IGP
> devices. You don't normally change such settings in kernel. If you want
> a different memory layout then shut down, change BIOS settings and boot
> again. Not a problem imho. (shut down, change u-boot & DT settings, boot
> again).

Except that here, "change u-boot & DT settings" means "recompile
u-boot and the DT, and flash the whole thing again to your
system". Not really as painless as what you're suggesting.


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140805/5d94b6a5/attachment.pgp>