[alsa-devel] module dependency between i915 and snd-hda-intel

[Takashi Iwai]

At Fri, 17 May 2013 13:00:02 +0000,
Wang, Xingchao wrote:
> 
> 
> 
> > -----Original Message-----
> > From: alsa-devel-bounces at alsa-project.org
> > [mailto:alsa-devel-bounces at alsa-project.org] On Behalf Of Takashi Iwai
> > Sent: Friday, May 17, 2013 6:45 PM
> > To: Wang, Xingchao
> > Cc: Li, Jocelyn; Lin, Mengdong; alsa-devel at alsa-project.org; Girdwood, Liam R;
> > david.henningsson at canonical.com
> > Subject: Re: [alsa-devel] module dependency between i915 and snd-hda-intel
> > 
> > At Fri, 17 May 2013 10:14:19 +0000,
> > Wang, Xingchao wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > > Sent: Friday, May 17, 2013 6:03 PM
> > > > To: Wang, Xingchao
> > > > Cc: Lin, Mengdong; david.henningsson at canonical.com; Li, Jocelyn;
> > > > Girdwood, Liam R; alsa-devel at alsa-project.org
> > > > Subject: Re: module dependency between i915 and snd-hda-intel
> > > >
> > > > At Fri, 17 May 2013 09:55:13 +0000,
> > > > Wang, Xingchao wrote:
> > > > >
> > > > > Hi Takashi,
> > > > >
> > > > > Seems kernel building will determine the module loading sequence,
> > > > > this would
> > > > fix the dependency for i915 and snd-hda-intel.
> > > > > If we call the i915 module API directly in snd-hda-intel side,
> > > > > kernel building will
> > > > change the module.dep accordingly like:
> > > > > "
> > > > > kernel/sound/pci/hda/snd-hda-intel.ko:
> > > > > kernel/drivers/gpu/drm/i915/i915.ko
> > > > kernel/drivers/gpu/dr     m/drm_kms_helper.ko
> > > > kernel/drivers/gpu/drm/drm.ko
> > > > kernel/drivers/i2c/algos/i2c-algo-bit.ko kerne l/drivers/acpi/video.ko
> > kernel/sound/pci/hda/snd-hda-codec.ko
> > > > kernel/sound/core/snd-hwdep.ko ker     nel/sound/core/snd-pcm.ko
> > > > kernel/sound/core/snd-timer.ko kernel/sound/core/snd.ko
> > > > kernel/sound/s oundcore.ko kernel/sound/core/snd-page-alloc.ko
> > > > > "
> > > > > So snd-hda-intel will wait for i915 loading. Even I added i915
> > > > > into blacklist.conf,
> > > > it will force load i915.ko.
> > > > >
> > > > > So I think the only bad case is no i915 module built-in, that
> > > > > would cause
> > > > haswell hda initialize fail, and the patch would output error message.
> > > >
> > > > Is it the result with your patch?  If so, something must be wrong.
> > > >
> > >
> > > No. i'm testing the case to call the API directly.
> > > The issue is with current patch to load i915.ko by request_module(),
> > > It would take ~50s and symbol_get() would fail, but I can see i915 module
> > already there by "lsmod".
> > 
> > Which distro are you using? 
> 
> I'm using ubuntu 12.10, kernel image was built based on daniel's drm-intel-next branch, with latest commits.

Note that the long stall is not about kernel but an issue in
user-space, either udev or kmod.

But, if the latest distro shows the problem, maybe we need a
workaround in anyway.  For example, kicking a work to call
azx_probe_contine(), and call the dynamic binding including the
request_module() call there; the similar hack is found for the
firmware loading stuff via request_firmware_nowait().

If such a complication isn't preferred, the best option is to split
Haswell-specific snd-hda-intel driver.


Takashi

> 
> Thanks
> --xingchao
> 
>  I guess you are bitten by a known problem, and
> > maybe it's the reason request_module_notime() is used in drm driver.  This
> > should have been fixed some time ago in udev, I thought.
> > 
> > > So is there any difference between request_module() and auto-loading i915
> > module?
> > 
> > Yes.
> > 
> > 
> > Takashi
> > 
> > > > We don't want to call i915 functions directly from snd-hda-intel.
> > > > That's the exact reason symbol_get() is used.  Otherwise i915 module
> > > > is always referred, thus always load when HD-audio is used, no
> > > > matter which hardware is.
> > >
> > > Okay, I see.
> > >
> > > Thanks
> > > --xingchao
> > > >
> > > >
> > > > Takashi
> > >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>