On 10/28/19 11:58 AM, Takashi Iwai wrote:
On Wed, 23 Oct 2019 11:03:28 +0200,
Kai Vehmanen wrote:
@@ -4,7 +4,7 @@ snd-soc-sst-byt-rt5640-mach-objs := byt-rt5640.o
snd-soc-sst-byt-max98090-mach-objs := byt-max98090.o
snd-soc-sst-bdw-rt5677-mach-objs := bdw-rt5677.o
snd-soc-sst-broadwell-objs := broadwell.o
-snd-soc-sst-bxt-da7219_max98357a-objs := bxt_da7219_max98357a.o
+snd-soc-sst-bxt-da7219_max98357a-objs := bxt_da7219_max98357a.o hda_dsp_common.o
Hrm, this can be a problem. I see there are multiple drivers that are
built with this object. When they are built as modules and more than
one module get loaded on a system, it'll lead to a conflict because
both modules try to put the same stuff.
So, hda_dsp_common.o should be in the common helper module that is
used by both drivers, or we need other trick.
But I'm not entirely sure whether this is true on the recent kernel
build. At least it *was* a problem in the past.
In anyway, please try to load the two modules on your system and check
whether the module loading works.
along the same lines, we have a Kconfig issue that I didn't see earlier.
These bxt parts will only compile with the Skylake driver with the
upstream code, the following test applies:
if SND_SOC_INTEL_APL
In the SOF tree, we have a different test:
if SND_SOC_INTEL_APL || (SND_SOC_SOF_APOLLOLAKE && SND_SOC_SOF_HDA_LINK)
I kept this change back on purpose since we can only use APL+SOF on
chromebooks with an experimental CoreBoot and only on pre-production
hardware, but what this means is that GLK devices wouldn't work with
SOF...I'll add this fix to my Kconfig update series.
Also I wonder if anyone tested bxt_rt298 with SOF? I see a topology for
it but I've never seen any test results from anyone.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
