On 20/02/24 13:51, Arnd Bergmann wrote:
On Tue, Feb 20, 2024, at 08:54, Mukunda,Vijendar wrote:
On 20/02/24 12:40, Arnd Bergmann wrote:
On Tue, Feb 20, 2024, at 07:23, Mukunda,Vijendar wrote:
On 20/02/24 11:43, Arnd Bergmann wrote:
On Tue, Feb 20, 2024, at 06:57, Mukunda,Vijendar wrote:
On 19/02/24 15:08, Arnd Bergmann wrote: > From: Arnd Bergmann arnd@arndb.de > In normal configs, they should all either be built-in or all loadable > modules anyway, so this simplification does not limit any real usecases. Tested this patch. SOUNWIRE_AMD flag is not selected by default causing AMD SOF driver for ACP 6.3 platform is build without enabling SoundWire.
Yes, that is what I described. But as SOUNWIRE_AMD is a user visible symbol, there is no problem in expecting users to enable it when they have this hardware, and distros just enable all the drivers anyway.
Want to set SOUNDWIRE_AMD flag by default, similar to Intel & Qcom platforms instead of explicitly enabling the Kconfig option.
Maybe use 'default SND_SOC_SOF_AMD_TOPLEVEL' then?
Didn't get your point.
Even with the current patch, if we select 'SOUNDWIRE_AMD' flag explicitly AMD ACP63 SOF driver Kconfig option is not visible for user configuration. This results in ACP63 SOF driver won't be built at all.
I don't understand what you mean here. What I see in linux-next both with and without my patch is
config SND_SOC_SOF_AMD_ACP63 tristate "SOF support for ACP6.3 platform" depends on SND_SOC_SOF_PCI
so it clearly should be visible as long as SND_SOC_SOF_PCI is enabled.
There is still a problem that SND_SOC_SOF_AMD_TOPLEVEL can't use my "depends on SOUNDWIRE_AMD || !SOUNDWIRE_AMD" trick if SOUNDWIRE_AMD in turn uses "default SND_SOC_SOF_AMD_TOPLEVEL", but I don't think you meant that, right?
Yes, you are correct.
I don't think copying the mistake from the intel driver is helpful, though I agree it would be nice to be consistent between them.
As a general rule, you should not have a Kconfig symbol that is both user visible and also selected by the drivers that depend on it.
To avoid the dependency problems from coming back and keep the complexity to a minimum, I think there are two logical ways to handle soundwire:
a) keep the current drivers/soundwire/Kconfig contents and change all the 'select SOUNDWIRE_foo' to 'depends on'.
Current patch already using 'depends on SOUNDWIRE_AMD" for SND_SOC_SOF_AMD_SOUNDWIRE Kconfig option.
Correct, because this is the Kconfig option that actually controls whether sound/soc/sof/amd/acp-common.c calls into the soundwire-amd module.
Still we couldn't see SND_SOC_SOF_AMD_ACP63 Kconfig option is enabled.
I need more information here. Do you have additional patches on top of what is in today's linux-next? I have it enabled on my build here.
Sorry, it's my bad. My local patches created the problem. Validated patch on our side. It's working fine.
Arnd