On Tue, 12 Jul 2016 04:02:25 +0200, Yang Jie wrote:
On 2016年07月11日 16:39, Takashi Iwai wrote:
The recent commit [a92ea59b74e2: ASoC: Intel: sst: only select sst-firmware when DW DMAC is built-in] introduced more strict kconfig dependency (depends on DW_DMAC_CORE=y) for avoiding the build failures due to dependency messes in intel-sst. This makes, however, it impossible to use this driver with the modularized systems, i.e. typically on Linux distros.
The problem addressed in the commit above is that sst_dsp_new() and sst_dsp_free() includes the firmware init / finish that call dw_*() functions. Thus building it as built-in with DW_DMAC_CORE module results in the missing symbols.
However, these sst_dsp functions are basically called only from the drivers that depend on DW_DMAC_CORE already. That is, once when these functions are split out, the rest can be independent from dw stuff.
This patch attempts to solve the issue by the following:
- Split sst-dsp stuff into two modules: snd-soc-sst-dsp and snd-soc-sst-firmware.
- Move sst_dsp_new() and sst_dsp_free() to the latter module so that the former module can be independent from DW_DMAC_CORE.
- Add a new kconfig SND_SOC_INTEL_SST_FIRMWARE to select the latter module by machine drivers.
One only remaining pitfall is that each machine driver has to select SND_SOC_INTEL_SST_FIRMWARE carefully depending on DW_DMAC_CORE. This can't be done cleanly due to the restriction of the current kbuild.
is it good to let SND_SOC_INTEL_SST_FIRMWARE select DW_DMAC_CORE in your opinion? That may fix this pitfall, but I am not sure if it is comply with convention -- a module should not select another upper layer one?
It depends. But in this case, DW_DMAC_CORE alone won't help to make it functional. Thus it might be rather confusing for users.
Takashi