On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel Vetter wrote:
>
> > The binding with i915 from HD-audio controller is done in an async
> > work invoked from the probe callback. It makes harder to deal with
> > EPROBEDEFER.
> >
> > IMO, a saner way would be to rather wait for the component binding.
> > The component mechanism is there just for that purpose, after all.
> >
> > Does a patch like below work (totally untested)?
>
> Yeah this looks like a reasonable first step at least. Probably need to
> thread the real errno value through, and at that point probably better to
> just nuke the async worker (and maybe switch all of hda over to async
> driver loading instead).
> -Daniel
Hi Daneil/Jani/Takashi,
When I was testing this patch from Takashi, I further checked the kernel
module code, and found that: we may need NOT to add any new codes to
prepare for i915's async probe feature!
Say when i915 module is being loader due to HDA's request_module() call,
in the callchain, do_init_module() has such code:
if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC))
async_synchronize_full();
This will garantee the asynced probe is done before it returns.
I have just tested and this seems to be enough. If I am not wrong, then
we can take the i915 async patch directly. What do you think?
Thanks,
Feng
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
