On Wed, Aug 13, 2014 at 09:54:21AM +0200, David Herrmann wrote:

Hi

Hans de Goede shortly told me about this and, tbh, I am not very
pleased. Stephen tried to keep simplefd "as simple as possible", your
patch now adds hardware-specific features. To be fair, the patch is
simple and clocks are easy to handle, but I somehow fear we have to
add more and more hardware-support that is required to keep the
framebuffer active. This really defeats the purpose of simplefb.

SimpleFB is a really deceptive name. If you lie to your ARM core all the 
time, and do most things behind its back, like RPi does, then you can 
get away with simplefb.

If not, it quickly becomes a lot more complicated, fast. This should've 
been called rpibootfb or something.

How does one deal with this dealbreaker issue of clocks? Or memory, 
apart from telling the kernel that the fb area is simple not accessible 
as normal ram. Or dpms?

The biggest question I have, is why do you add the clocks to your DT
at all?

I didn't, someone else did.

The framebuffer is set up by your boot-loader (or maybe
platform code) and should prepare the clocks. I don't see why we add
the clocks to DT now. If they're not added, then no-one will disable
them and simplefb works just fine, right?

Or is there some requirement to make DT a _complete_ hw-description?

Again, i am not responsible for that part. But my impression is that it 
should be absolutely complete, and i have been whining about actual bit 
offsets into registers being provided from the dt :(

Or is there some parent clock which might be used by other drivers and
controls the clock used for your display?

Not at this point for sunxi, but there will be.

The only reason I see to add the clocks, is to support both, simplefb
*and* a hardware-driver. However, fbdev hand-over is horribly racy and
I'd much rather prefer a solution like sysfb that does proper handover
from primitive firmware-FBs to real hardware-drivers. In that case,
we'd have to figure out how to deal with clocks, but we could do it in
sysfb (which is meant to deal with those issues) with the benefit of
controlling hand-over directly, and allowing hw-dependent features.

Yes, a KMS driver is being worked on. I was, as a first order 
approximation (when i move it to mainline code), going to manually do 
some of this handover from simplefb.

My sysfb patches haven't been updated for a while, though, and you
have a working solution here. So I'm not going to NAK this, I
appreciate people working on this. But I'd like to get a discussion
started so we can at least figure out some nicer solution for the
future which might replace your code.

So much for this being simple. again :)

Btw., my current idea was to destroy the platform-devices of EFI/VGA
framebuffers during hand-over (because usually the underlying hw is
shutdown/modified). This automatically unloads simplefb and makes sure
the real hw-driver can be probed without other drivers touching the
hardware in parallel. Iff you unload the hw-driver afterwards, it can
re-create the firmware framebuffer and add a platform-device to make
simplefb load again (in case anyone really needs this).
Looking at your 3rd patch, I wonder whether this works with DT based
machines, or whether we'd have to use the "disable" mechanism you
chose. Any reason destroying the device would not work there? If yes,
I will look into the "disable-idea".

The clocks we currently claim handle the ahb gating of different display 
engines. Disable the gating bit, and all power is lost to the respective 
engine, and register content vanishes. So there is absolutely no coming 
back from that, apart from starting a proper display driver.

Luc Verhaegen.