Re: [PATCH] ASoC: intel: Fix sst-dsp dependency on dw stuff

From: Takashi Iwai <tiwai@suse.de>
To: Yang Jie <yang.jie@linux.intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] ASoC: intel: Fix sst-dsp dependency on dw stuff
Date: Tue, 12 Jul 2016 07:31:52 +0200	[thread overview]
Message-ID: <s5hlh17ifqv.wl-tiwai@suse.de> (raw)
In-Reply-To: <57844FB1.4070005@linux.intel.com>

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel