Message ID | 20160825194133.GC3296@wotan.suse.de (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Cutting down since a lot of this is probably better discussed at ks/lpc. Aside, if you want to check out Chris Wilson's work on our new depency handling, it's called kfence. https://lkml.org/lkml/2016/7/17/37 On Thu, Aug 25, 2016 at 9:41 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote: >> > So .. I agree, let's avoid the hacks. Patches welcomed. >> >> Hm, this is a definite change of tack - back when I discussed this >> with Greg about 2 ks ago it sounded like "don't do this". The only >> thing we need is some way to wait for rootfs before we do the >> request_firmware. Everything else we handle already in the kernel. > > OK so lets just get this userspace event done, and we're set. Ah great. As long as that special wait-for-rootfs-pls firmware request is still allowed, i915&gfx folks will be happy. We will call it from probe though ;-) but all from our own workers. -Daniel
On Thu, Aug 25, 2016 at 10:10:52PM +0200, Daniel Vetter wrote: > Cutting down since a lot of this is probably better discussed at > ks/lpc. Aside, if you want to check out Chris Wilson's work on our new > depency handling, it's called kfence. > > https://lkml.org/lkml/2016/7/17/37 Thanks more reading.. :) > On Thu, Aug 25, 2016 at 9:41 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote: > >> > So .. I agree, let's avoid the hacks. Patches welcomed. > >> > >> Hm, this is a definite change of tack - back when I discussed this > >> with Greg about 2 ks ago it sounded like "don't do this". The only > >> thing we need is some way to wait for rootfs before we do the > >> request_firmware. Everything else we handle already in the kernel. > > > > OK so lets just get this userspace event done, and we're set. > > Ah great. As long as that special wait-for-rootfs-pls firmware request > is still allowed, i915&gfx folks will be happy. We will call it from > probe though ;-) but all from our own workers. We should strive for this to be transparent to drivers, ie, this safeguard of looking for firmware should be something handled by the kernel as otherwise we're just forcing a race condition given the review in the last thread. Luis
On Thu, Aug 25, 2016 at 12:41 PM, Luis R. Rodriguez <mcgrof@kernel.org> 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@kernel.org> wrote: >> > Can they use initramfs for this ? >> >> Apparently that's also uncool with the embedded folks. > > What's uncool with embedded folks? To use initramfs for firmware ? > If so can you explain why ? Because it is not needed? If you are embedded you have an option of only compiling drivers and services that you need directly into the kernel, then initramfs is just an extra piece that complicates your boot process. Thanks.
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@kernel.org> 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
diff --git a/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci b/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci index cf180c59e042..e19e6d3dfc0f 100644 --- a/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci +++ b/scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci @@ -49,7 +49,7 @@ identifier init; module_init(init); -@ has_probe depends on defines_module_init@ +@ has_probe @ identifier drv_calls, drv_probe; type bus_driver; identifier probe_op =~ "(probe)"; @@ -59,7 +59,7 @@ bus_driver drv_calls = { .probe_op = drv_probe, }; -@hascall depends on !after_start && defines_module_init@ +@hascall depends on !after_start @ position p; @@