Hi,

On 08/13/2014 12:16 PM, Koen Kooi wrote:

Op 13 aug. 2014, om 10:36 heeft Hans de Goede [off-list ref] het volgende geschreven:

quoted

Hi,

On 08/13/2014 10:21 AM, Koen Kooi wrote:

quoted

Op 13 aug. 2014, om 09:54 heeft David Herrmann [off-list ref] het volgende geschreven:

quoted

Hi

On Wed, Aug 13, 2014 at 9:17 AM, Luc Verhaegen [off-list ref] wrote:

quoted

This is needed for the sunxi platform, where the u-boot initialized display
engine gets disabled by the clocks framework if certain clocks are not
claimed. Once these clocks are disabled, register content is lost, and there
is no turning back unless a full display driver is loaded, which kind of
beats the purpose of having simplefb running.

The lack of clock handling should plague more hardware, but so far rpi is the
best known user of simplefb, and its stepmotherly handling of the arm core
has kept these sort of issues from the kernel.

The sunxi u-boot side code can be found here:
https://groups.google.com/forum/#!topic/linux-sunxi/dPs958sIXvY

Patch 3 might be controversial, as this does not achieve anything real today,
since the status property in dt is only really evaluated when dealing with a
nodes memory. It still seems like a good idea to at least flag this memory or
node as disabled, as we really have no way back when the clocks get disabled.

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.

The biggest question I have, is why do you add the clocks to your DT
at all? 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?

All clocks known to linux without a consumer will get disabled on most (all?) ARM systems to save power. Years ago OMAP had a Kconfig option to change that behaviour and add printk warnings for the clocks it would touch. 
To be honest, I don't get why sunxi needs a simplefb to begin with, only a proper kms/drm driver is needed which would register the clocks it needs properly. These patches and discussion seem like a lot of effort wasted on the wrong thing. But I can't complain about that since I'm not the one doing the work. 

I believe that having some simple generic fb driver will be useful
on non x86, since we don't have vga-console there, and most distros
will build kms drivers as modules. Having the kernel / initrd code being
able to show output (like e.g. missing symbols in the kms drivers) seems
a very useful feature to me.

The way I envision this to work is:

u-boot lights up display, if it fails to load the kernel / ftd / ramdisk,
it can show this on the display

kernel takes over using something like simplefb (built into the kernel)
for its initial output / any error messages.

initrd loads kms, kms takes over.

This way we've a way to show error messages during boot at all times.

As we start supporting more ARM htpc boxes out of the box, telling the
user to hook up a serial console (which often involves soldering wires
to some test points) when things don't work really is not a viable
answer.

So what you are saying is that the only reason it is needed is because some distros choose to build DRM drivers as modules. So as soon as they stop doing that the problem goes away, right?

Right, except that that is not going to happen, see David's reply also.

Regards,

Hans