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

["Henrik Nordström" <henrik@henriknordstrom.net>]

m?n 2014-08-04 klockan 19:28 +0200 skrev Luc Verhaegen:

> 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).

I seriously don't worry about display mode corruption or showing random
memory if people boot configurations/combinations which are not
supported.

> 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.

If it in any way hinders development of the KMS driver then yes.

> 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?

> * 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?

> * 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).

Regards
Henrik