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

[Luc Verhaegen]

On Mon, Aug 04, 2014 at 10:39:13AM +0200, Hans de Goede wrote:
> Hi Luc,
> 
> First of all many thanks for your work on this.
> 
> ATM I don't have time to do a full review, but I don't expect there
> to be too many suprises when I do find the time.
> 
> Really my only concern is the handover of the reserved memory, etc. to
> the kernel. We need to get a plan in place for that *before* this can
> be merged. Note I don't want to raise any artificial barriers here,
> I would love to see this merged ASAP. But I don't want to paint us
> in a corner where u-boot having hdmi console support makes it harder
> to get kms support in the kernel going. I think we can both agree on that.
>
> So I really want to see some plan how this will work in place before merging.
> Note just a plan, I don't expect kernel patches ready to be merged for this,
> just a good idea / sketch of how all the bits will fit together.

Memory is not the biggest worry.

Some kernel code needs to claim clocks if the mode is to cleanly survive 
the start of the kernel. If not, there is no coming back until a proper 
display driver runs. If the simplefb driver claims these clocks, then 
the simplefb driver also must release these clocks, and this driver 
should then never be started again, so it should set the simplefb dt 
node status to "disabled".

But that's not the full extent of this story. If we have a kms driver, 
then we need to claim these clocks, and set a proper mode on the hw. So 
the simplefb driver claiming these resources must've properly unclaimed 
them by then, _and_ have set the dt node to disabled. This kills your 
flicker-free right here unless there is a clean way for the kms driver 
to reclaim the clocks before the simplefb driver unclaims them.

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?

Suddenly, simplefb doesn't look as simple anymore. It's turned into 
quite the mess. Life is easy when you are called rpi, and you sweep 
everything under the videocore rug, and do everything behind the lesser 
cores back. But if you want to solve this properly, then you end up 
smearing bits of simplefb driver code all over the kernel tree.

As for memory, that's closely tied into the clock code, as whatever code
claims or disables the clocks for the display engine, that's also where 
the dt node gets set to disabled, and thus also where the memory either 
is added to some cma area directly, released from (upcoming) reserved 
memory, or forgotten. Simplefb at least gives us a nice handle on the 
location and size of the memory, so we can always find a workable 
solution.

So i don't think the memory issue is as important. We already give the
kernel a nice handle on that. How the kernel wishes to handle it in 
detail is then pretty much up to the kernel, and i expect the kernels 
behaviour to change when kms comes out and i have to think about dealing 
with simplefb.

Clocks are quite a bit more crucial in this context. How the memory 
is handled needs to follow how the clocks are handled.

> In one of the threads about this there was some discussion about doing a
> "flicker free" handover. I agree with you that given that we will be fixed
> to 1024x768 in u-boot this won't be realistic. But in the light of that
> it would be nice if we could make it so that if none of the stdout and stderr
> variables point to vga we don't init the hdmi at all, this will avoid
> what ever is attached to first have to sync at 1024x768 and then at its
> native resolution when the kernel takes over, and this will also allow
> for an easy way to not steal the 8MB of memory for people who care about
> that (think headless server which is low on memory)

That's not how u-boot or the console code works.

First off, this stdout/stderr variable setting, that's all handled after 
the driver has been loaded and an (extra) console device is created. The 
cfb console driver is created because of a build time config, but it is 
allowed to fail (in our case, because HPD says nothing is attached).

Iirc, without iomux, the last created console driver is the one that 
gets stdout, stderr and stdin, so you lose the UART console. With iomux, 
you always need to load env for anything but the uart console to work. 
This means that you can have both cfb and uart working side by side, but 
you do not get anything on cfb unless the env is set as such.

For a future spin of this patch, the logic around enabling this code 
will be swapped around. People will have to manually add VIDEO to their 
board config. There's just to many hairy cornercases and tough to answer 
"what if"s here, when you actually start thinking things through, to 
keep this as the default.

Luc Verhaegen.