On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote:

On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:

quoted

On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez [off-list ref] wrote:
Some users want a fully running gfx stack 2s after power-on. There's
not even enough time to load an uefi or vga driver first. i915
directly initializes the gpu from power-on state on those.

I see.. thanks.

quoted

quoted

quoted

I think what would work is loading the different subsystems of the
driver in parallel (we already do that largely)

Init level stuff is actually pretty synchronous, and in fact both
init and probe are called serially. There are a few subsystems which
have been doing things a bit differently, but these are exceptions.

When you say we already do this largely, can you describe a bit more
precisely what you mean ?

Oh, this isn't subsystems as in linux device/driver model, but
different parts within the driver. We fire up a bunch of struct work
to get various bits done asynchronously.

Thanks for the clarification.

<-- snip -->

quoted

One of the proposals which would have worked for us died a while back:

https://lkml.org/lkml/2014/6/15/47

Interesting, the problem stated here, which comes from the fact (as clarified
above) the rootfs comes up only *after* we run do_initcalls() as such there are
possible theoretical races even with request_firmware_nowait() -- as such that
justifies even more the SmPL grammar rule to include even request_firmware_nowait()
on probe / init as this patch has.

Anyway yeah that patch has good intentions but its wrong for a slew of reasons.
The problem is the same as discussed with Bjorn recently. The solution
discussed is that since only userspace knows when the *real* rootfs is ready
(because of slew of reasons) the best we can do is have an event issued by
userspace to inform us of that.

OK I have something I think we can build upon for this. Will send RFC.

  Luis