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: > > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> 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. > > > >> 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 --> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
