[alsa-devel] [PATCH v7 6/9] ASoC: Intel: bxt-da7219-max98357a: common hdmi codec support

[Pierre-Louis Bossart]

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
>