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.
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.
Takashi