Hi,

On 10/05/2014 10:01 PM, Mike Turquette wrote:

Quoting jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org (2014-10-05 10:09:52)

quoted

I edited the subject line to something more appropriate. This impacts
a lot of platforms and we should be getting more replies from people
on the ARM kernel list. This is likely something that deserves a
Kernel Summit discussion.

ELC-E and LPC are just around the corner as well. I am attending both. I
suppose some of the others interested in this topic will be present?

Having a get together about this there sounds very good. I'm willing to
organize this. If you want to attend please reply to this thread (or drop
me a personal mail) with when you will be available to attend, then I'll
pick a time where hopefully we will all be available, and I'll try to get
a room for this, not sure if I'll be able to get a room, if not we will
just need to find a quiet spot in the lobby or some such.

I'll be present for the entire week too. Monday I'll be at the u-boot
mini-conf. Thursday and Friday I'll be at the Linux Kernel Media mini-summit,
and Friday afternoon I'll be at the Wayland mini-conf.

If this causes scheduling problems, I can miss parts of the media mini-summit,
and if I really have to I can maybe miss some parts of the u-boot mini-conf,
I cannot walk out of the Wayland track as I'm one of the session leaders
there.

quoted

To summarize the problem....

The BIOS (uboot, etc) may have set various devices up into a working
state before handing off to the kernel.  The most obvious example of
this is the boot display.

So how do we transition onto the kernel provided device specific
drivers without interrupting these functioning devices?

This used to be simple, just build everything into the kernel. But
then along came multi-architecture kernels where most drivers are not
built in. Those kernels clean up everything (ie turn off unused
clocks, regulators, etc) right before user space starts. That's done
as a power saving measure.

Unfortunately that code turns off the clocks and regulators providing
the display on your screen. Which then promptly gets turned back on a
half second later when the boot scripts load the display driver. Let's
all hope the boot doesn't fail while the display is turned off.

I would say this is one half of the discussion. How do you ever really
know when it is safe to disable these things? In a world with loadable
modules the kernel cannot know that everything that is going to be
loaded has been loaded. There really is no boundary that makes it easy
to say, "OK, now it is truly safe for me to disable these things because
I know every possible piece of code that might claim these resources has
probed".

Somebody (Geert?) proposed an ioctl for userspace to send such an "all
clear" signal, but I dislike that idea. We're talking about managing
fairly low-level hardware bits (clocks, regulators) and getting
userspace involved feels wrong.

Ack, also see my other reply as on why this can never work 100% reliable.

Additionally clocks and regulators should be managed by PM Runtime
implementations (via generic power domains and friends), so any solution
that we come up with today that is specific for the clock and regulator
frameworks would need to scale up to other abstraction layers, because
those layers would probably like to know that they are not really
idle/gated in hardware because the ioctl/garbage collector has not yet
happened.

The second half of the discussion is specific to simple framebuffer and
the desire to keep it extremely simple and narrowly focused. I can
understand both sides of the argument and I hope to stay well out of the
flame zone.

Even if we do leave simple framebuffer alone, the *idea* behind a very
simple, entirely data-driven driver implementation that is meant to be
compiled into the kernel image, claim resources early, ensure they stay
enabled and then hand-off to a real driver that may be a loadable module
is very interesting. It doesn't have to be simplefb. It could be
something new.

Right, as I already said earlier if this is just about keeping simplefb
simple, I'm more then happy to clone the simplefb binding to a new binding,
called say firmwarefb, and add resource management there.

Regards,

Hans