[alsa-devel] [RFC PATCH 0/7] Fix Intel audio Kconfig issues
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok.
The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC).
The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better.
The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is.
I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me.
I'll do some more testing on my side but I could use feedback. Thanks!
Pierre-Louis Bossart (7): ASoC: Intel: Fix Kconfig ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies ASoC: Intel: document what Kconfig options do ASoC: Intel: Fix nested/unnecessary Kconfig dependencies ASoC: Intel: boards: align Kconfig dependencies for Haswell/Broadwell ASoC: Intel: boards: align Kconfig configurations for HiFi2 ASoC: Intel: boards: align/fix SKL/BXT/KBL Kconfigs
sound/soc/intel/Kconfig | 89 ++++++++++++++++++-------- sound/soc/intel/boards/Kconfig | 140 ++++++++++++++++++++++------------------- 2 files changed, 137 insertions(+), 92 deletions(-)
Follow network example suggested by Linus, move Intel definitions in if/endif block and clarify which options distro configurations should enable - everything except legacy Baytrail stuff and NOCODEC (test only)
There should be no functionality change - except that sound capabilities are restored when using older configs without any user selection.
Fixes: f6a118a800e3 ("ASoC: Intel: clarify Kconfig dependencies") Reported-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/Kconfig | 57 +++++++++++++++---------- sound/soc/intel/boards/Kconfig | 97 ++++++++++++++++++++++++------------------ 2 files changed, 90 insertions(+), 64 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 7b49d04e3c60..98ef2273665f 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -1,3 +1,18 @@ +config SND_SOC_INTEL_SST_TOPLEVEL + bool "Intel ASoC SST drivers" + default y + depends on X86 || COMPILE_TEST + help + Intel ASoC SST Platform Drivers. If you have a Intel machine that + has audio controller with a DSP and I2S or DMIC port, then + enable this option by saying Y + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all + the questions about Intel SST drivers. + +if SND_SOC_INTEL_SST_TOPLEVEL + config SND_SST_IPC tristate
@@ -11,9 +26,6 @@ config SND_SST_IPC_ACPI select SND_SOC_INTEL_SST select IOSF_MBI
-config SND_SOC_INTEL_COMMON - tristate - config SND_SOC_INTEL_SST tristate select SND_SOC_INTEL_SST_ACPI if ACPI @@ -25,47 +37,48 @@ config SND_SOC_INTEL_SST_FIRMWARE config SND_SOC_INTEL_SST_ACPI tristate
-config SND_SOC_ACPI_INTEL_MATCH - tristate - select SND_SOC_ACPI if ACPI - -config SND_SOC_INTEL_SST_TOPLEVEL - tristate "Intel ASoC SST drivers" - depends on X86 || COMPILE_TEST - select SND_SOC_INTEL_MACH - select SND_SOC_INTEL_COMMON - help - Intel ASoC Audio Drivers. If you have a Intel machine that - has audio controller with a DSP and I2S or DMIC port, then - enable this option by saying Y or M - If unsure select "N". - config SND_SOC_INTEL_HASWELL tristate "Intel ASoC SST driver for Haswell/Broadwell" - depends on SND_SOC_INTEL_SST_TOPLEVEL && SND_DMA_SGBUF + depends on SND_DMA_SGBUF depends on DMADEVICES select SND_SOC_INTEL_SST select SND_SOC_INTEL_SST_FIRMWARE + select SND_SOC_INTEL_COMMON
config SND_SOC_INTEL_BAYTRAIL tristate "Intel ASoC SST driver for Baytrail (legacy)" - depends on SND_SOC_INTEL_SST_TOPLEVEL depends on DMADEVICES select SND_SOC_INTEL_SST select SND_SOC_INTEL_SST_FIRMWARE + select SND_SOC_INTEL_COMMON
config SND_SST_ATOM_HIFI2_PLATFORM tristate "Intel ASoC SST driver for HiFi2 platforms (*field, *trail)" - depends on SND_SOC_INTEL_SST_TOPLEVEL && X86 + depends on X86 select SND_SOC_COMPRESS + select SND_SOC_INTEL_COMMON
config SND_SOC_INTEL_SKYLAKE tristate "Intel ASoC SST driver for SKL/BXT/KBL/GLK/CNL" - depends on SND_SOC_INTEL_SST_TOPLEVEL && PCI && ACPI + depends on PCI && ACPI select SND_HDA_EXT_CORE select SND_HDA_DSP_LOADER select SND_SOC_TOPOLOGY select SND_SOC_INTEL_SST + select SND_SOC_INTEL_COMMON + +endif ## SND_SOC_INTEL_SST_TOPLEVEL
# ASoC codec drivers source "sound/soc/intel/boards/Kconfig" + +# configs common to SST and SOF to compile sound/soc/intel/common +# directory and use matching tables + +config SND_SOC_INTEL_COMMON + tristate + select SND_SOC_ACPI_INTEL_MATCH if ACPI + +config SND_SOC_ACPI_INTEL_MATCH + tristate + select SND_SOC_ACPI if ACPI diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 6f754708a48c..4ae44b0cea0a 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -1,7 +1,14 @@ -config SND_SOC_INTEL_MACH - tristate "Intel Audio machine drivers" - depends on SND_SOC_INTEL_SST_TOPLEVEL - select SND_SOC_ACPI_INTEL_MATCH if ACPI +config SND_SOC_INTEL_MACH + bool "Intel ASoC machine drivers" + default y + help + Intel ASoC Audio Machine Drivers. If you have a Intel machine that + has audio controller with a DSP and I2S or DMIC port, then + enable this option by saying Y + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all + the questions about Intel SST machine drivers.
if SND_SOC_INTEL_MACH
@@ -17,103 +24,108 @@ config SND_MFLD_MACHINE Say Y if you have such a device. If unsure select "N".
+if SND_SOC_INTEL_HASWELL + config SND_SOC_INTEL_HASWELL_MACH tristate "ASoC Audio DSP support for Intel Haswell Lynxpoint" depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM - depends on SND_SOC_INTEL_HASWELL select SND_SOC_RT5640 help This adds support for the Lynxpoint Audio DSP on Intel(R) Haswell - Ultrabook platforms. - Say Y if you have such a device. + Ultrabook platforms. This is a recommended option. + Say Y or m if you have such a device. If unsure select "N".
config SND_SOC_INTEL_BDW_RT5677_MACH tristate "ASoC Audio driver for Intel Broadwell with RT5677 codec" depends on X86_INTEL_LPSS && GPIOLIB && I2C - depends on SND_SOC_INTEL_HASWELL select SND_SOC_RT5677 help This adds support for Intel Broadwell platform based boards with - the RT5677 audio codec. + the RT5677 audio codec. This is a recommended option. + Say Y or m if you have such a device. + If unsure select "N".
config SND_SOC_INTEL_BROADWELL_MACH tristate "ASoC Audio DSP support for Intel Broadwell Wildcatpoint" depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM - depends on SND_SOC_INTEL_HASWELL select SND_SOC_RT286 help This adds support for the Wilcatpoint Audio DSP on Intel(R) Broadwell Ultrabook platforms. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N". +endif + +if SND_SOC_INTEL_BAYTRAIL
config SND_SOC_INTEL_BYT_MAX98090_MACH tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec" + default n depends on X86_INTEL_LPSS && I2C - depends on SND_SST_IPC_ACPI = n - depends on SND_SOC_INTEL_BAYTRAIL select SND_SOC_MAX98090 help This adds audio driver for Intel Baytrail platform based boards - with the MAX98090 audio codec. + with the MAX98090 audio codec. This driver is deprecated, use + SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH instead for better + functionality.
config SND_SOC_INTEL_BYT_RT5640_MACH tristate "ASoC Audio driver for Intel Baytrail with RT5640 codec" + default n depends on X86_INTEL_LPSS && I2C - depends on SND_SST_IPC_ACPI = n - depends on SND_SOC_INTEL_BAYTRAIL select SND_SOC_RT5640 help This adds audio driver for Intel Baytrail platform based boards with the RT5640 audio codec. This driver is deprecated, use SND_SOC_INTEL_BYTCR_RT5640_MACH instead for better functionality.
+endif + +if SND_SST_ATOM_HIFI2_PLATFORM + config SND_SOC_INTEL_BYTCR_RT5640_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5640 codec" depends on X86 && I2C && ACPI select SND_SOC_RT5640 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR platforms with RT5640 audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BYTCR_RT5651_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5651 codec" depends on X86 && I2C && ACPI select SND_SOC_RT5651 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR platforms with RT5651 audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_CHT_BSW_RT5672_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5672 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT5670 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with RT5672 audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_CHT_BSW_RT5645_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5645/5650 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT5645 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with RT5645/5650 audio codec. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH @@ -121,63 +133,68 @@ config SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_MAX98090 select SND_SOC_TS3A227E - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with MAX98090 audio codec it also can support TI jack chip as aux device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BYT_CHT_DA7213_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail with DA7212/7213 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_DA7213 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail & CherryTrail platforms with DA7212/7213 audio codec. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BYT_CHT_ES8316_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail with ES8316 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_ES8316 - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail & Cherrytrail platforms with ES8316 audio codec. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail platform with no codec (MinnowBoard MAX, Up)" + default n depends on X86_INTEL_LPSS && I2C && ACPI - depends on SND_SST_ATOM_HIFI2_PLATFORM select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for the MinnowBoard Max or Up boards and provides access to I2S signals on the Low-Speed - connector + connector. This is not a recommended option outside of these cases. + It is not intended to be enabled by distros by default. + Say Y or m if you have such a device. + If unsure select "N".
+endif + +if SND_SOC_INTEL_SKYLAKE + config SND_SOC_INTEL_SKL_RT286_MACH tristate "ASoC Audio driver for SKL with RT286 I2S mode" depends on X86 && ACPI && I2C - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_RT286 select SND_SOC_DMIC select SND_SOC_HDAC_HDMI help This adds support for ASoC machine driver for Skylake platforms with RT286 I2S audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. If unsure select "N".
config SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and SSM4567 in I2S Mode" depends on X86_INTEL_LPSS && I2C - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_NAU8825 select SND_SOC_SSM4567 select SND_SOC_DMIC @@ -185,13 +202,12 @@ config SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH help This adds support for ASoC Onboard Codec I2S machine driver. This will create an alsa sound card for NAU88L25 + SSM4567. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and MAX98357A in I2S Mode" depends on X86_INTEL_LPSS && I2C - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_NAU8825 select SND_SOC_MAX98357A select SND_SOC_DMIC @@ -199,13 +215,12 @@ config SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH help This adds support for ASoC Onboard Codec I2S machine driver. This will create an alsa sound card for NAU88L25 + MAX98357A. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH tristate "ASoC Audio driver for Broxton with DA7219 and MAX98357A in I2S Mode" depends on X86 && ACPI && I2C - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_DA7219 select SND_SOC_MAX98357A select SND_SOC_DMIC @@ -214,13 +229,12 @@ config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH help This adds support for ASoC machine driver for Broxton-P platforms with DA7219 + MAX98357A I2S audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_BXT_RT298_MACH tristate "ASoC Audio driver for Broxton with RT298 I2S mode" depends on X86 && ACPI && I2C - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_RT298 select SND_SOC_DMIC select SND_SOC_HDAC_HDMI @@ -228,14 +242,13 @@ config SND_SOC_INTEL_BXT_RT298_MACH help This adds support for ASoC machine driver for Broxton platforms with RT286 I2S audio codec. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663 and MAX98927 in I2S Mode" depends on X86_INTEL_LPSS && I2C select SND_SOC_INTEL_SST - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_RT5663 select SND_SOC_MAX98927 select SND_SOC_DMIC @@ -243,14 +256,13 @@ config SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH help This adds support for ASoC Onboard Codec I2S machine driver. This will create an alsa sound card for RT5663 + MAX98927. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
config SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663, RT5514 and MAX98927 in I2S Mode" depends on X86_INTEL_LPSS && I2C && SPI select SND_SOC_INTEL_SST - depends on SND_SOC_INTEL_SKYLAKE select SND_SOC_RT5663 select SND_SOC_RT5514 select SND_SOC_RT5514_SPI @@ -259,7 +271,8 @@ config SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH help This adds support for ASoC Onboard Codec I2S machine driver. This will create an alsa sound card for RT5663 + RT5514 + MAX98927. - Say Y if you have such a device. + Say Y or m if you have such a device. This is a recommended option. If unsure select "N". +endif
endif
On Sat, 18 Nov 2017 01:01:56 +0100, Pierre-Louis Bossart wrote:
+if SND_SOC_INTEL_BAYTRAIL
config SND_SOC_INTEL_BYT_MAX98090_MACH tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec"
- default n
default=n is superfluous, can be dropped.
depends on X86_INTEL_LPSS && I2C
- depends on SND_SST_IPC_ACPI = n
- depends on SND_SOC_INTEL_BAYTRAIL select SND_SOC_MAX98090
So the dependency on ND_SST_IPC_ACPI=n is removed here too, and I guess this will allow this machine driver built although it shouldn't be?
thanks,
Takashi
On 11/18/2017 10:49 AM, Takashi Iwai wrote:
On Sat, 18 Nov 2017 01:01:56 +0100, Pierre-Louis Bossart wrote:
+if SND_SOC_INTEL_BAYTRAIL
config SND_SOC_INTEL_BYT_MAX98090_MACH tristate "ASoC Audio driver for Intel Baytrail with MAX98090 codec"
- default n
default=n is superfluous, can be dropped.
depends on X86_INTEL_LPSS && I2C
- depends on SND_SST_IPC_ACPI = n
- depends on SND_SOC_INTEL_BAYTRAIL select SND_SOC_MAX98090
So the dependency on ND_SST_IPC_ACPI=n is removed here too, and I guess this will allow this machine driver built although it shouldn't be?
This dependency doesn't really make sense any longer at the machine driver level. There is now an explicit layer on the platform side (SND_SOC_INTEL_BAYTRAIL) where the exclusion with SND_SOC_INTEL_HIFI2 platforms should be handled. I also removed this dependency because it was 'one way', I couldn't find a way to show explicit mutual exclusions without getting into circular dependencies.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Sat, 18 Nov 2017 01:01:56 +0100, Pierre-Louis Bossart wrote:
Follow network example suggested by Linus, move Intel definitions in if/endif block and clarify which options distro configurations should enable - everything except legacy Baytrail stuff and NOCODEC (test only)
There should be no functionality change - except that sound capabilities are restored when using older configs without any user selection.
Fixes: f6a118a800e3 ("ASoC: Intel: clarify Kconfig dependencies") Reported-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
A few another things I noticed while looking at the end result:
config SND_SOC_INTEL_SKYLAKE tristate "Intel ASoC SST driver for SKL/BXT/KBL/GLK/CNL"
- depends on SND_SOC_INTEL_SST_TOPLEVEL && PCI && ACPI
- depends on PCI && ACPI select SND_HDA_EXT_CORE select SND_HDA_DSP_LOADER select SND_SOC_TOPOLOGY select SND_SOC_INTEL_SST
- select SND_SOC_INTEL_COMMON
+endif ## SND_SOC_INTEL_SST_TOPLEVEL
This endif should cover the whole including the source boards/Kconfig. In that way, deselecting SND_SOC_INTEL_SST_TOPLEVEL will skip the whole. As of this patch, you'll be still asked about the board config even if you say TOPLEVEL=n.
# ASoC codec drivers source "sound/soc/intel/boards/Kconfig"
+# configs common to SST and SOF to compile sound/soc/intel/common +# directory and use matching tables
+config SND_SOC_INTEL_COMMON
- tristate
- select SND_SOC_ACPI_INTEL_MATCH if ACPI
+config SND_SOC_ACPI_INTEL_MATCH
- tristate
- select SND_SOC_ACPI if ACPI
... so here should be placed the endif.
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 6f754708a48c..4ae44b0cea0a 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -1,7 +1,14 @@ -config SND_SOC_INTEL_MACH
- tristate "Intel Audio machine drivers"
- depends on SND_SOC_INTEL_SST_TOPLEVEL
- select SND_SOC_ACPI_INTEL_MATCH if ACPI
+config SND_SOC_INTEL_MACH
- bool "Intel ASoC machine drivers"
- default y
- help
Intel ASoC Audio Machine Drivers. If you have a Intel machine thathas audio controller with a DSP and I2S or DMIC port, thenenable this option by saying YNote that the answer to this question doesn't directly affect thekernel: saying N will just cause the configurator to skip allthe questions about Intel SST machine drivers.
Do we still need this filtering? Since we have a top-level filter, users who want to skip the Intel stuff can say N there already, and I can't imagine anyone who want only the SST core / platform drivers built without machine drivers explicitly.
thanks,
Takashi
On 11/21/17 11:07 AM, Takashi Iwai wrote:
On Sat, 18 Nov 2017 01:01:56 +0100, Pierre-Louis Bossart wrote:
Follow network example suggested by Linus, move Intel definitions in if/endif block and clarify which options distro configurations should enable - everything except legacy Baytrail stuff and NOCODEC (test only)
There should be no functionality change - except that sound capabilities are restored when using older configs without any user selection.
Fixes: f6a118a800e3 ("ASoC: Intel: clarify Kconfig dependencies") Reported-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
A few another things I noticed while looking at the end result:
config SND_SOC_INTEL_SKYLAKE tristate "Intel ASoC SST driver for SKL/BXT/KBL/GLK/CNL"
- depends on SND_SOC_INTEL_SST_TOPLEVEL && PCI && ACPI
- depends on PCI && ACPI select SND_HDA_EXT_CORE select SND_HDA_DSP_LOADER select SND_SOC_TOPOLOGY select SND_SOC_INTEL_SST
- select SND_SOC_INTEL_COMMON
+endif ## SND_SOC_INTEL_SST_TOPLEVEL
This endif should cover the whole including the source boards/Kconfig. In that way, deselecting SND_SOC_INTEL_SST_TOPLEVEL will skip the whole. As of this patch, you'll be still asked about the board config even if you say TOPLEVEL=n.
yes for now, but it's a feature needed for SOF integration...see below.
# ASoC codec drivers source "sound/soc/intel/boards/Kconfig"
+# configs common to SST and SOF to compile sound/soc/intel/common +# directory and use matching tables
+config SND_SOC_INTEL_COMMON
- tristate
- select SND_SOC_ACPI_INTEL_MATCH if ACPI
+config SND_SOC_ACPI_INTEL_MATCH
- tristate
- select SND_SOC_ACPI if ACPI
... so here should be placed the endif.
Those two are needed for SOF and shouldn't be filtered out by SST. we can move them somewhere else if needed.
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 6f754708a48c..4ae44b0cea0a 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -1,7 +1,14 @@ -config SND_SOC_INTEL_MACH
- tristate "Intel Audio machine drivers"
- depends on SND_SOC_INTEL_SST_TOPLEVEL
- select SND_SOC_ACPI_INTEL_MATCH if ACPI
+config SND_SOC_INTEL_MACH
- bool "Intel ASoC machine drivers"
- default y
- help
Intel ASoC Audio Machine Drivers. If you have a Intel machine thathas audio controller with a DSP and I2S or DMIC port, thenenable this option by saying YNote that the answer to this question doesn't directly affect thekernel: saying N will just cause the configurator to skip allthe questions about Intel SST machine drivers.Do we still need this filtering? Since we have a top-level filter, users who want to skip the Intel stuff can say N there already, and I can't imagine anyone who want only the SST core / platform drivers built without machine drivers explicitly.
Yes, but when we add SOF we will have an alternate top-level and the machine drivers should be selectable even when SST is filtered out.
thanks,
Takashi
PCI/ACPI selections should not happen in Kconfig for machine drivers, move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms. The PCI-based platforms may be removed at some point since Medfield is not really supported by anyone and there is no publicly available firmware for Merrifield.
There should be no functionality change.
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/Kconfig | 16 ++++++++++++---- sound/soc/intel/boards/Kconfig | 14 ++++---------- 2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 98ef2273665f..175b2965ca21 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -39,7 +39,7 @@ config SND_SOC_INTEL_SST_ACPI
config SND_SOC_INTEL_HASWELL tristate "Intel ASoC SST driver for Haswell/Broadwell" - depends on SND_DMA_SGBUF + depends on SND_DMA_SGBUF && ACPI depends on DMADEVICES select SND_SOC_INTEL_SST select SND_SOC_INTEL_SST_FIRMWARE @@ -47,14 +47,22 @@ config SND_SOC_INTEL_HASWELL
config SND_SOC_INTEL_BAYTRAIL tristate "Intel ASoC SST driver for Baytrail (legacy)" - depends on DMADEVICES + depends on DMADEVICES && ACPI select SND_SOC_INTEL_SST select SND_SOC_INTEL_SST_FIRMWARE select SND_SOC_INTEL_COMMON
+config SND_SST_ATOM_HIFI2_PLATFORM_PCI + tristate "Intel ASoC SST driver for PCI HiFi2 platforms (Medfield, Merrifield)" + depends on X86 && PCI + select SND_SST_IPC_PCI + select SND_SOC_COMPRESS + select SND_SOC_INTEL_COMMON + config SND_SST_ATOM_HIFI2_PLATFORM - tristate "Intel ASoC SST driver for HiFi2 platforms (*field, *trail)" - depends on X86 + tristate "Intel ASoC SST driver for ACPI HiFi2 platforms (Baytrail, Cherrytrail)" + depends on X86 && ACPI + select SND_SST_IPC_ACPI select SND_SOC_COMPRESS select SND_SOC_INTEL_COMMON
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 4ae44b0cea0a..bb40f042962f 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -12,18 +12,20 @@ config SND_SOC_INTEL_MACH
if SND_SOC_INTEL_MACH
+if SND_SST_ATOM_HIFI2_PLATFORM_PCI + config SND_MFLD_MACHINE tristate "SOC Machine Audio driver for Intel Medfield MID platform" depends on INTEL_SCU_IPC select SND_SOC_SN95031 - depends on SND_SST_ATOM_HIFI2_PLATFORM - select SND_SST_IPC_PCI help This adds support for ASoC machine driver for Intel(R) MID Medfield platform used as alsa device in audio substem in Intel(R) MID devices Say Y if you have such a device. If unsure select "N".
+endif + if SND_SOC_INTEL_HASWELL
config SND_SOC_INTEL_HASWELL_MACH @@ -88,7 +90,6 @@ config SND_SOC_INTEL_BYTCR_RT5640_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5640 codec" depends on X86 && I2C && ACPI select SND_SOC_RT5640 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR platforms with RT5640 audio codec. @@ -99,7 +100,6 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5651 codec" depends on X86 && I2C && ACPI select SND_SOC_RT5651 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR platforms with RT5651 audio codec. @@ -110,7 +110,6 @@ config SND_SOC_INTEL_CHT_BSW_RT5672_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5672 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT5670 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with RT5672 audio codec. @@ -121,7 +120,6 @@ config SND_SOC_INTEL_CHT_BSW_RT5645_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5645/5650 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT5645 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with RT5645/5650 audio codec. @@ -133,7 +131,6 @@ config SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_MAX98090 select SND_SOC_TS3A227E - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with MAX98090 audio codec it also can support TI jack chip as aux device. @@ -144,7 +141,6 @@ config SND_SOC_INTEL_BYT_CHT_DA7213_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail with DA7212/7213 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_DA7213 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail & CherryTrail platforms with DA7212/7213 audio codec. @@ -155,7 +151,6 @@ config SND_SOC_INTEL_BYT_CHT_ES8316_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail with ES8316 codec" depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_ES8316 - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for Intel(R) Baytrail & Cherrytrail platforms with ES8316 audio codec. @@ -166,7 +161,6 @@ config SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail platform with no codec (MinnowBoard MAX, Up)" default n depends on X86_INTEL_LPSS && I2C && ACPI - select SND_SST_IPC_ACPI help This adds support for ASoC machine driver for the MinnowBoard Max or Up boards and provides access to I2S signals on the Low-Speed
On Fri, 2017-11-17 at 18:01 -0600, Pierre-Louis Bossart wrote:
PCI/ACPI selections should not happen in Kconfig for machine drivers, move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms.
The PCI-based platforms may be removed at some point since Medfield is not really supported by anyone
This is rather true,
and there is no publicly available firmware for Merrifield.
while this is not true. Intel Edison board is based on Merrifield SoC and I'm sure people are able to make a sound out of it.
On Sat, 2017-11-18 at 18:53 +0200, Andy Shevchenko wrote:
On Fri, 2017-11-17 at 18:01 -0600, Pierre-Louis Bossart wrote:
PCI/ACPI selections should not happen in Kconfig for machine drivers, move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms.
The PCI-based platforms may be removed at some point since Medfield is not really supported by anyone
This is rather true,
and there is no publicly available firmware for Merrifield.
while this is not true. Intel Edison board is based on Merrifield SoC
s/SoC/platform/
and I'm sure people are able to make a sound out of it.
On 11/18/2017 10:53 AM, Andy Shevchenko wrote:
On Fri, 2017-11-17 at 18:01 -0600, Pierre-Louis Bossart wrote:
PCI/ACPI selections should not happen in Kconfig for machine drivers, move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms.
The PCI-based platforms may be removed at some point since Medfield is not really supported by anyone
This is rather true,
and there is no publicly available firmware for Merrifield.
while this is not true. Intel Edison board is based on Merrifield SoC and I'm sure people are able to make a sound out of it.
I am aware that Edison could run with a modified 4.4 kernel, I just don't know where the firmware is. I don't see anything for Merrifield in /lib/firmware/intel? If there is a simple way of testing this I don't mind looking into this, I just don't have the pointers.
I am aware that Edison could run with a modified 4.4 kernel, I just don't know where the firmware is. I don't see anything for Merrifield in /lib/firmware/intel?
https://downloadmirror.intel.com/25028/eng/edison-image-from-src-package-ww2...
I have no idea why it never made it into the standard Linux firmware package but with Edison now defunct I also don't have anyone I can ask about that !
Alan
On Mon, 2017-11-20 at 10:23 -0600, Pierre-Louis Bossart wrote:
On 11/18/2017 10:53 AM, Andy Shevchenko wrote:
On Fri, 2017-11-17 at 18:01 -0600, Pierre-Louis Bossart wrote:
and there is no publicly available firmware for
Merrifield.
while this is not true. Intel Edison board is based on Merrifield SoC and I'm sure people are able to make a sound out of it.
I am aware that Edison could run with a modified 4.4 kernel,
Edison can just run vanilla (with some caveats, though not related to LPE). But okay, there was last official Yocto kernel v3.10.98 based and v4.4 with Brillo.
I just don't know where the firmware is. I don't see anything for Merrifield in /lib/firmware/intel? If there is a simple way of testing this I don't mind looking into this, I just don't have the pointers.
In any case the official bundle has it (sha1):
fcedef11ac49405389b0fb83d526600e0bd933a3 /lib/firmware/fw_sst_119a.bin
On Fri, 17 Nov 2017 18:01:57 -0600 Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
PCI/ACPI selections should not happen in Kconfig for machine drivers, move to SOC selections.
Add distinction between PCI and ACPI HiFi2 platforms. The PCI-based platforms may be removed at some point since Medfield is not really supported by anyone and there is no publicly available firmware for Merrifield.
Merrifield is (Intel secret decoder ring translation - 'Edison')
I don't thionk anyone would care if Medfield and Moorestown kicked the bucket upstream however. Moorestown wouldn't make much difference code-wise as it has a 'real computer' twin (Oaktrail), but dumping the Medfield code would be IMHO fine.
Alan
Document what the options are supposed to mean, before clean-up in next patch.
No functionality change here.
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/Kconfig | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 175b2965ca21..136426d60da0 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,16 +15,30 @@ if SND_SOC_INTEL_SST_TOPLEVEL
config SND_SST_IPC tristate + help + This option controls the IPC core for HiFi2 platforms
config SND_SST_IPC_PCI tristate select SND_SST_IPC + help + This option controls the PCI-based IPC for HiFi2 platforms + (Medfield, Merrifield).
config SND_SST_IPC_ACPI tristate select SND_SST_IPC select SND_SOC_INTEL_SST select IOSF_MBI + help + This option controls the ACPI-based IPC for HiFi2 platforms + (Baytrail, Cherrytrail) + +config SND_SOC_INTEL_SST_ACPI + tristate + help + This option controls ACPI-based probing on Haswell/Broadwell/ + Baytrail legacy and will be set when these platforms are enabled
config SND_SOC_INTEL_SST tristate @@ -33,9 +47,9 @@ config SND_SOC_INTEL_SST config SND_SOC_INTEL_SST_FIRMWARE tristate select DW_DMAC_CORE - -config SND_SOC_INTEL_SST_ACPI - tristate + help + This option controls firmware download on Haswell/Broadwell/ + Baytrail legacy and will be set when these platforms are enabled
config SND_SOC_INTEL_HASWELL tristate "Intel ASoC SST driver for Haswell/Broadwell"
On Sat, 18 Nov 2017 01:01:58 +0100, Pierre-Louis Bossart wrote:
Document what the options are supposed to mean, before clean-up in next patch.
No functionality change here.
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
sound/soc/intel/Kconfig | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 175b2965ca21..136426d60da0 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,16 +15,30 @@ if SND_SOC_INTEL_SST_TOPLEVEL
config SND_SST_IPC tristate
- help
This option controls the IPC core for HiFi2 platforms
A help section for non-selectable config is fine, per se, but in most cases it's written as a comment.
And, if we do add the help text, it's more important to do that for selectable items. Currently the help texts are missing for the platform configs like SND_SOC_INTEL_HASWELL.
thanks,
Takashi
On 11/21/17 11:09 AM, Takashi Iwai wrote:
On Sat, 18 Nov 2017 01:01:58 +0100, Pierre-Louis Bossart wrote:
Document what the options are supposed to mean, before clean-up in next patch.
No functionality change here.
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
sound/soc/intel/Kconfig | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 175b2965ca21..136426d60da0 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,16 +15,30 @@ if SND_SOC_INTEL_SST_TOPLEVEL
config SND_SST_IPC tristate
- help
This option controls the IPC core for HiFi2 platformsA help section for non-selectable config is fine, per se, but in most cases it's written as a comment.
yes, I can move back to a comment. the main point was to explain the simplifications in the next patch
And, if we do add the help text, it's more important to do that for selectable items. Currently the help texts are missing for the platform configs like SND_SOC_INTEL_HASWELL.
Ah, that's a miss, I did have a help but I didn't add it in the final RFC version. Will add in v2.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
This patch fixes a number of issues: 1. IOSF_MBI is only needed for byt-cr detection, which is only supported on Baytrail/Cherrytrail, move to HiFi2 config
2. SND_SOC_INTEL_SST should not select SND_SOC_INTEL_SST_ACPI, the latter config is only valid for Haswell/Baytrail legacy but not needed by Skylake
3. SND_SST_IPC_ACPI, used only by the atom/sst driver, should not select SND_SOC_INTEL_SST, none of the code under common/sst*.c is used
This nesting of configs really makes no sense, it's easier to maintain if for each platform one can control what is strictly required.
Compiled-tested with each of Haswell, Baytrail legacy, HiFi2, SKL cases selected independently, no obvious issue detected but this needs to be validated for functionality and may expose randconfig issues
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 136426d60da0..dee731d42634 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -28,8 +28,6 @@ config SND_SST_IPC_PCI config SND_SST_IPC_ACPI tristate select SND_SST_IPC - select SND_SOC_INTEL_SST - select IOSF_MBI help This option controls the ACPI-based IPC for HiFi2 platforms (Baytrail, Cherrytrail) @@ -42,7 +40,6 @@ config SND_SOC_INTEL_SST_ACPI
config SND_SOC_INTEL_SST tristate - select SND_SOC_INTEL_SST_ACPI if ACPI
config SND_SOC_INTEL_SST_FIRMWARE tristate @@ -56,6 +53,7 @@ config SND_SOC_INTEL_HASWELL depends on SND_DMA_SGBUF && ACPI depends on DMADEVICES select SND_SOC_INTEL_SST + select SND_SOC_INTEL_SST_ACPI select SND_SOC_INTEL_SST_FIRMWARE select SND_SOC_INTEL_COMMON
@@ -63,6 +61,7 @@ config SND_SOC_INTEL_BAYTRAIL tristate "Intel ASoC SST driver for Baytrail (legacy)" depends on DMADEVICES && ACPI select SND_SOC_INTEL_SST + select SND_SOC_INTEL_SST_ACPI select SND_SOC_INTEL_SST_FIRMWARE select SND_SOC_INTEL_COMMON
@@ -77,6 +76,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM tristate "Intel ASoC SST driver for ACPI HiFi2 platforms (Baytrail, Cherrytrail)" depends on X86 && ACPI select SND_SST_IPC_ACPI + select IOSF_MBI select SND_SOC_COMPRESS select SND_SOC_INTEL_COMMON
Make sure that the same I2C/I2C_DESIGNWARE_PLATFORM are selected. The latter might actually need to be moved to the SOC side of things, it really has no place in a machine driver dependency
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/boards/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index bb40f042962f..f900b1e6b952 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -40,7 +40,7 @@ config SND_SOC_INTEL_HASWELL_MACH
config SND_SOC_INTEL_BDW_RT5677_MACH tristate "ASoC Audio driver for Intel Broadwell with RT5677 codec" - depends on X86_INTEL_LPSS && GPIOLIB && I2C + depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM && GPIOLIB select SND_SOC_RT5677 help This adds support for Intel Broadwell platform based boards with
The patch
ASoC: Intel: boards: align Kconfig dependencies for Haswell/Broadwell
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 043f5a0b8d6e4b9cb373978ca1883fe16287abfd Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Date: Thu, 4 Jan 2018 16:35:57 -0600 Subject: [PATCH] ASoC: Intel: boards: align Kconfig dependencies for Haswell/Broadwell
Make sure that the same I2C/I2C_DESIGNWARE_PLATFORM are selected. The latter might actually need to be moved to the SOC side of things, it really has no place in a machine driver dependency
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Acked-By: Vinod Koul vinod.koul@intel.com Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/intel/boards/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index e926f9747232..358f8f33adc4 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -40,7 +40,7 @@ config SND_SOC_INTEL_HASWELL_MACH
config SND_SOC_INTEL_BDW_RT5677_MACH tristate "ASoC Audio driver for Intel Broadwell with RT5677 codec" - depends on X86_INTEL_LPSS && GPIOLIB && I2C + depends on X86_INTEL_LPSS && I2C && I2C_DESIGNWARE_PLATFORM && GPIOLIB select SND_SOC_RT5677 help This adds support for Intel Broadwell platform based boards with
Make sure all the configs are aligned Also add the missing dependencies on SOC_ACPI stuff used to fix DAI names based on HID.
FIXME: not sure why X86_INTEL_LPSS is needed in a machine driver config, should it be back to X86 everywhere?
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/boards/Kconfig | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index f900b1e6b952..7379b0220210 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -88,7 +88,8 @@ if SND_SST_ATOM_HIFI2_PLATFORM
config SND_SOC_INTEL_BYTCR_RT5640_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5640 codec" - depends on X86 && I2C && ACPI + depends on X86_INTEL_LPSS && I2C && ACPI + select CONFIG_SND_SOC_ACPI select SND_SOC_RT5640 help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR @@ -98,7 +99,8 @@ config SND_SOC_INTEL_BYTCR_RT5640_MACH
config SND_SOC_INTEL_BYTCR_RT5651_MACH tristate "ASoC Audio driver for Intel Baytrail and Baytrail-CR with RT5651 codec" - depends on X86 && I2C && ACPI + depends on X86_INTEL_LPSS && I2C && ACPI + select CONFIG_SND_SOC_ACPI select SND_SOC_RT5651 help This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR @@ -109,7 +111,8 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH config SND_SOC_INTEL_CHT_BSW_RT5672_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5672 codec" depends on X86_INTEL_LPSS && I2C && ACPI - select SND_SOC_RT5670 + select CONFIG_SND_SOC_ACPI + select SND_SOC_RT5670 help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell platforms with RT5672 audio codec. @@ -119,6 +122,7 @@ config SND_SOC_INTEL_CHT_BSW_RT5672_MACH config SND_SOC_INTEL_CHT_BSW_RT5645_MACH tristate "ASoC Audio driver for Intel Cherrytrail & Braswell with RT5645/5650 codec" depends on X86_INTEL_LPSS && I2C && ACPI + select CONFIG_SND_SOC_ACPI select SND_SOC_RT5645 help This adds support for ASoC machine driver for Intel(R) Cherrytrail & Braswell @@ -140,6 +144,7 @@ config SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH config SND_SOC_INTEL_BYT_CHT_DA7213_MACH tristate "ASoC Audio driver for Intel Baytrail & Cherrytrail with DA7212/7213 codec" depends on X86_INTEL_LPSS && I2C && ACPI + select CONFIG_SND_SOC_ACPI select SND_SOC_DA7213 help This adds support for ASoC machine driver for Intel(R) Baytrail & CherryTrail
On Fri, 2017-11-17 at 18:02 -0600, Pierre-Louis Bossart wrote:
Make sure all the configs are aligned Also add the missing dependencies on SOC_ACPI stuff used to fix DAI names based on HID.
FIXME: not sure why X86_INTEL_LPSS is needed in a machine driver config, should it be back to X86 everywhere?
X86_INTEL_LPSS makes sense only for Haswell, Broadwell, BayTrail and CherryTrail (more precisely for PCH inside those SoCs).
Basically it enables few peripheral drivers in case they are enumerated via ACPI (SPI, I2C, UART, PWM, SDHCI) on SoCs listed above.
Hope this would help how to deal with the option in ASoC case.
On 11/18/2017 11:08 AM, Andy Shevchenko wrote:
On Fri, 2017-11-17 at 18:02 -0600, Pierre-Louis Bossart wrote:
Make sure all the configs are aligned Also add the missing dependencies on SOC_ACPI stuff used to fix DAI names based on HID.
FIXME: not sure why X86_INTEL_LPSS is needed in a machine driver config, should it be back to X86 everywhere?
X86_INTEL_LPSS makes sense only for Haswell, Broadwell, BayTrail and CherryTrail (more precisely for PCH inside those SoCs).
Basically it enables few peripheral drivers in case they are enumerated via ACPI (SPI, I2C, UART, PWM, SDHCI) on SoCs listed above.
Hope this would help how to deal with the option in ASoC case.
Yes, and my proposal would be to move this dependency where applicable in the sound/soc/intel Kconfig. the board-level dependency should only be I2C or SPI - or both in some cases, there is no reason to have something SoC-dependent at the machine level, and those cases would be filtered out anyway.
No reason why SND_SOC_INTEL_SST should be set here. Also make sure same dependencies are used everywhere (only last one has SPI in addition)
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com --- sound/soc/intel/boards/Kconfig | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 7379b0220210..810fa769c4cb 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -181,7 +181,7 @@ if SND_SOC_INTEL_SKYLAKE
config SND_SOC_INTEL_SKL_RT286_MACH tristate "ASoC Audio driver for SKL with RT286 I2S mode" - depends on X86 && ACPI && I2C + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT286 select SND_SOC_DMIC select SND_SOC_HDAC_HDMI @@ -193,7 +193,7 @@ config SND_SOC_INTEL_SKL_RT286_MACH
config SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and SSM4567 in I2S Mode" - depends on X86_INTEL_LPSS && I2C + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_NAU8825 select SND_SOC_SSM4567 select SND_SOC_DMIC @@ -206,7 +206,7 @@ config SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH
config SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and MAX98357A in I2S Mode" - depends on X86_INTEL_LPSS && I2C + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_NAU8825 select SND_SOC_MAX98357A select SND_SOC_DMIC @@ -219,7 +219,7 @@ config SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH
config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH tristate "ASoC Audio driver for Broxton with DA7219 and MAX98357A in I2S Mode" - depends on X86 && ACPI && I2C + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_DA7219 select SND_SOC_MAX98357A select SND_SOC_DMIC @@ -233,7 +233,7 @@ config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH
config SND_SOC_INTEL_BXT_RT298_MACH tristate "ASoC Audio driver for Broxton with RT298 I2S mode" - depends on X86 && ACPI && I2C + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT298 select SND_SOC_DMIC select SND_SOC_HDAC_HDMI @@ -246,8 +246,7 @@ config SND_SOC_INTEL_BXT_RT298_MACH
config SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663 and MAX98927 in I2S Mode" - depends on X86_INTEL_LPSS && I2C - select SND_SOC_INTEL_SST + depends on X86_INTEL_LPSS && I2C && ACPI select SND_SOC_RT5663 select SND_SOC_MAX98927 select SND_SOC_DMIC @@ -260,8 +259,7 @@ config SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH
config SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663, RT5514 and MAX98927 in I2S Mode" - depends on X86_INTEL_LPSS && I2C && SPI - select SND_SOC_INTEL_SST + depends on X86_INTEL_LPSS && I2C && SPI && ACPI select SND_SOC_RT5663 select SND_SOC_RT5514 select SND_SOC_RT5514_SPI
On Fri, 2017-11-17 at 18:02 -0600, Pierre-Louis Bossart wrote:
No reason why SND_SOC_INTEL_SST should be set here. Also make sure same dependencies are used everywhere (only last one has SPI in addition)
Regarding to my comment against previous patch...
config SND_SOC_INTEL_SKL_RT286_MACH tristate "ASoC Audio driver for SKL with RT286 I2S mode"
- depends on X86 && ACPI && I2C
- depends on X86_INTEL_LPSS && I2C && ACPI
Skylake -> No.
config SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and SSM4567 in I2S Mode"
- depends on X86_INTEL_LPSS && I2C
- depends on X86_INTEL_LPSS && I2C && ACPI
Skylake -> No.
config SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH tristate "ASoC Audio driver for SKL with NAU88L25 and MAX98357A in I2S Mode"
- depends on X86_INTEL_LPSS && I2C
- depends on X86_INTEL_LPSS && I2C && ACPI
Skylake -> No.
config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH tristate "ASoC Audio driver for Broxton with DA7219 and MAX98357A in I2S Mode"
- depends on X86 && ACPI && I2C
- depends on X86_INTEL_LPSS && I2C && ACPI
Broxton -> No.
config SND_SOC_INTEL_BXT_RT298_MACH tristate "ASoC Audio driver for Broxton with RT298 I2S mode"
- depends on X86 && ACPI && I2C
- depends on X86_INTEL_LPSS && I2C && ACPI
Broxton -> No.
config SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663 and MAX98927 in I2S Mode"
- depends on X86_INTEL_LPSS && I2C
- select SND_SOC_INTEL_SST
- depends on X86_INTEL_LPSS && I2C && ACPI
Kabylake -> No.
config SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH tristate "ASoC Audio driver for KBL with RT5663, RT5514 and MAX98927 in I2S Mode"
depends on X86_INTEL_LPSS && I2C && SPIselect SND_SOC_INTEL_SST
depends on X86_INTEL_LPSS && I2C && SPI && ACPI
Kabylake -> No.
This patch WRT X86_INTEL_LPSS for selected SoCs does not make any sense.
Perhaps you need to depend on
MFD_INTEL_LPSS (Skylake and newer)
instead.
On Fri, Nov 17, 2017 at 4:01 PM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
Without actually testing it (just scanning through the patches) it looks sane. I noticed a couple of "default n" (just get rid of them - that's already the default), but other than that nothing obviously wrong.
But testing may show something else entirely.
Linus
On Sat, 18 Nov 2017 01:01:55 +0100, Pierre-Louis Bossart wrote:
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok.
The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC).
The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better.
The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is.
I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me.
I'll do some more testing on my side but I could use feedback. Thanks!
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
thanks,
Takashi
On Sat, Nov 18, 2017 at 10:25 AM, Takashi Iwai tiwai@suse.de wrote:
On Sat, 18 Nov 2017 01:01:55 +0100, Pierre-Louis Bossart wrote:
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok.
The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC).
The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better.
The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is.
I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me.
I'll do some more testing on my side but I could use feedback. Thanks!
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
I've found several problems in this area in the past with the randconfig builds, so I've now added that branch to my build setup as well, and should be able to run a few hundred x86 randconfig builds today on it. If you don't hear back from me later today, it's probably ok.
Arnd
On Sat, 18 Nov 2017 10:25:28 +0100, Takashi Iwai wrote:
On Sat, 18 Nov 2017 01:01:55 +0100, Pierre-Louis Bossart wrote:
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok.
The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC).
The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better.
The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is.
I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me.
I'll do some more testing on my side but I could use feedback. Thanks!
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
No news is a good news, it seems that your patchset doesn't break builds, at least. Let's go ahead!
Takashi
On 11/21/17 11:10 AM, Takashi Iwai wrote:
On Sat, 18 Nov 2017 10:25:28 +0100, Takashi Iwai wrote:
On Sat, 18 Nov 2017 01:01:55 +0100, Pierre-Louis Bossart wrote:
At the risk of being scolded for the third time in two days by Linux overlords (no hard feelings), here's an attempt to clean things up.
The first patch *should* implement what Linus, Takashi and Mark tried to explain by email. There should be no functionality change and could be merged if deemed ok.
The rest of the patch series does a more in-depth cleanup and should not be merged without more testing (hence the RFC).
The 4th patch is really the most important one, there were nested configs which made no sense to me. I don't know the history which led to such complicated stuff but simpler is better.
The last 3 patches are just clean-ups of the machine driver configs, for some reason there is no consistency in the settings so I tried to apply common sense. There might be additional cleanup needed since I don't really get why we need references to LPSS or DESIGNWARE for things which are not visible to a machine driver, we should only depend on IC2 or SPI in my opinion - depending on what the control interface is.
I tried to keep things to a minimum in each patch to make the reviews easier, if people want them squashed that's fine by me.
I'll do some more testing on my side but I could use feedback. Thanks!
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
No news is a good news, it seems that your patchset doesn't break builds, at least. Let's go ahead!
There is additional testing being done at Intel on Skylake platforms, let's see after the Turkey break if additional fixes are needed. I also need to spend a bit more time on PCI platforms and SOF - those two were the main source of comments. Thanks for the feedback and comments everyone, much appreciated.
On Tue, Nov 21, 2017 at 06:10:52PM +0100, Takashi Iwai wrote:
Takashi Iwai wrote:
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
No news is a good news, it seems that your patchset doesn't break builds, at least. Let's go ahead!
OTOH there's a bunch of "I'll fix that in the next version" stuff in the thread and the immediate issue got fixed already - I'd been expecting a new version.
On 11/22/17 5:54 AM, Mark Brown wrote:
On Tue, Nov 21, 2017 at 06:10:52PM +0100, Takashi Iwai wrote:
Takashi Iwai wrote:
FYI, I've put these to a test branch, test/asoc-intel-kconfig, so that 0day bot can catch issues. Let's see.
No news is a good news, it seems that your patchset doesn't break builds, at least. Let's go ahead!
OTOH there's a bunch of "I'll fix that in the next version" stuff in the thread and the immediate issue got fixed already - I'd been expecting a new version.
Yes, there will be a new version with the comments addressed. This series was not intended to be applied as is.
participants (8)
-
Alan Cox -
Andy Shevchenko -
Arnd Bergmann -
Linus Torvalds -
Mark Brown -
Pierre-Louis Bossart -
Shevchenko, Andriy -
Takashi Iwai