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