skl-tplg-interface.h describes firmware format details for Skylake
topology files. It is part of the ABI and should reside in the uapi
directory.
While moving the file, also replace the license boilerplate with
the SPDX License Identifier.
No functional change.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit dc31e741db ("ASoC: topology: ABI - Add the types for BE
DAI") introduced sound topology files version 5. Initially, this
change made the topology code incompatible with v4 topology files.
Backwards compatibility with v4 configuration files was
subsequently added with commit 288b8da7e9 ("ASoC: topology:
Support topology file of ABI v4").
Unfortunately, backwards compatibility was never fully implemented.
First, the manifest size in (Skylake) v4 configuration files is set
to 0, which causes manifest_new_ver() to bail out with error messages
similar to the following.
snd_soc_skl 0000:00:1f.3: ASoC: invalid manifest size
snd_soc_skl 0000:00:1f.3: tplg component load failed-22
snd_soc_skl 0000:00:1f.3: Failed to init topology!
snd_soc_skl 0000:00:1f.3: ASoC: failed to probe component -22
skl_n88l25_m98357a skl_n88l25_m98357a: ASoC: failed to instantiate card -22
skl_n88l25_m98357a: probe of skl_n88l25_m98357a failed with error -22
After this problem is fixed, the following error message is seen instead.
snd_soc_skl 0000:00:1f.3: ASoC: old version of manifest
snd_soc_skl 0000:00:1f.3: Invalid descriptor token 1093938482
snd_soc_skl 0000:00:1f.3: ASoC: failed to load widget media0_in cpr 0
snd_soc_skl 0000:00:1f.3: tPlg component load failed-22
This message is seen because backwards compatibility for loading widgets
was never implemented.
The lack of audio support when running the upstream kernel on recent
Chromebooks has been reported in various forums, and can be traced back
to this problem. Attempts to fix the problem, usually by providing v5
configuration files, were only partially successful.
Let's implement backward compatibility properly to solve the problem
for good.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
On APL, commit fd0f237572
("ASoC: Intel: bxt: Move codec sysclk config to codec_init function")
fixed an issue related to jack detection.
The MCLK for DA7219 does not change in this platform, but is
currently being configured everytime as part of the platform_clock
event handler for DAPM. The upshot of this is that we have
unnecessary calls to this function, and it also means that if
a stream hasn't yet been started, DA7219 driver does not have the
correct MCLK rates programmed and so the HP detection feature does
not operate as expected.
The same fix is needed on KBL.
This patch rectifies this issue by moving the sysclk call to
codec_init function so it's only called once at initialisation.
Signed-off-by: Mac Chiang <mac.chiang@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Many X86 devices using a BYT SoC + RT5651 codec are cheap devices with
generic DMI strings, causing snd_soc_set_dmi_name() to fail to set a
long_name, making it impossible for userspace to have a correct UCM
profile which knowns which input is connected to the internal mic,
which input is connected to the hsmic (for correct jack-based switching)
and which inputs are unused.
Our quirks already specify which inputs the internal and headset mic
are connected to.
This commit sets a long_name based on the quirks so that userspace can
have UCM profiles doing the right thing based on the long_name.
Note that if we ever encounter the need for a special UCM profile for
some device we can add a quirk to set a specific long_name for the
device,
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a quirk for the ARCHOS 80 Cesium 8" windows tablet, this device mostly
works with the default settings, except that it has only one speaker.
So add a quirk with the default settings + the mono-speaker flag.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The nau8824 codec can detect whether a headset or plain headphones is
inserted (as well as button presses on the headset) as such the jack_type
passed to snd_soc_card_jack_new() should include SND_JACK_MICROPHONE.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Trivial fix to spelling mistake in snprintf literal string
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Many X86 devices using a BYT SoC + RT5640 codec are cheap devices with
generic DMI strings, causing snd_soc_set_dmi_name() to fail to set a
long_name, making it impossible for userspace to have a correct UCM
profile which only uses inputs / outputs which are actually hooked up
on the device.
Our quirks already specify which input the internal mic is connected to
and if a single (mono) speaker is used or if the device has stereo
speakers.
This commit sets a long_name based on the quirks so that userspace can
have UCM profiles doing the right thing based on the long_name.
Note that if we ever encounter the need for a special UCM profile for
some device we can add a quirk to set a specific long_name for the
device,
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Even with our recently tweaked defaults, quite a few bytcr_rt5640 devices
still need quirks to be fully functional. This commits adds quirks where
necessary for the 16 bytcr_rt5640 devices I have access to.
The quirks are added for the following reasons:
1) Devices with only one speaker need the mono quirk to avoid driving an
unused and potentially short-circuited output. 8 of my sample of 16 devs
are mono, 4 of these would work with the defaults if it were not for their
mono speaker.
2) Devices using a different input for the internal mic then the default,
this is the case for 6 of my sample of 16 devices.
3) BYTCR devices without an ACPI channel map, which do not work with the
default of SSP0-AIF2, this is the case for 2 of my sample of 16 devices.
4) Devices which need non-default jack-detect settings, this is the case
for 6 of my sample of 16 devices.
This commit add quirks for the following devices:
Acer Iconia Tab 8 W1-810
Chuwi Vi8
HP Pavilion X2 10-n000nd
HP Stream 7
I.T. Works TW891
Lamina I8270
MSI S100
Pipo W4
PoV-mobii-800w (v2.0)
PoV-mobii-800w (v2.1)
Toshiba Click Mini L9W-B
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use dmi_first_match() instead of dmi_check_system() + callbacks, this
avoid the need to initialize dmi_system_id.callback for each
byt_rt5640_quirk_table entry.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we add more quirks it is useful to have some sort of order in the
quirk list, sort it alphabetically.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Out of the 11 BYTCR devices which I have access to for testing, 6 use
JD1IN4P for jack-detect, 2 use JD1IN4P non-inverted and the other 3 use
JD2IN4N, the ones not using JD1IN4P are all also special in other ways and
need a DMI quirk regardless.
All 5 BYT (non CR) devices which I have access to use JD2IN4N.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently we've 2 places with BYTCR defaults: 1. The generic catch-all
DMI_SYS_VENDOR=="Insyde" DMI quirk which selects SSP0-AIF1 for generic
Insyde BYTCR tablets without the ACPI channel package; and 2. the
defaults in the if (is_bytcr) {} code block.
Currently these are not identical, both select IN3 as the internal mic
output, but the "Insyde" DMI quirk leaves out the DIFF_MIC quirk. The
DIFF_MIC quirk should be enabled by default, because enabling diff. input
helps a lot for devices with a differential mic, where as it is a nop on
devices with a normal mic.
This commit adds the DIFF_MIC quirk to the "Insyde" DMI quirk path, by
adding a new BYTCR_INPUT_DEFAULTS define and using that in both code paths
which set BYTCR defaults.
Having a single place where the BYTCR input defaults are defined also
allows defining jack-detect defaults in a single place in a follow-up
commit.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Out of the 11 BYTCR devices which I have access to for testing,
7 use IN3 for the internal mic and only 1 uses IN1 for the internal mic,
the other 3 use DMIC1.
So IN3 clearly is a better default, using IN3 as default avoids the need
to add DMI quirks for some of these devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add code to support setting jack-detect parameters through quirks and
extend the existing DMI quirk table entries for the Asus T100TA and the
Dell Venue 8 Pro 5830 to enable jack detection.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes the following 3 issues:
1) The sys_vendor match should be for "Dell Inc." not "DellInc.",
without this fixed the quirk never gets applied
2) DMIC1 is used not DMIC2, this was not a problem sofar because for
regular BYT boards (rather then BYTCR) we default to DMIC1 and because
of 1. the quirk was not being applied
3) The Dell Venue 8 5830 Pro only has a single speaker
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use device-properties for setting up the dmic, based on the
BYT_RT5640_MAP() value, instead of using the codec specific
rt5640_dmic_enable() function for this. This also removes the need
for the BYT_RT5640_DMIC_EN quirk, which was always set together with
a MAP() quirk of DMIC1_MAP or DMIC2_MAP.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The patch replaces the export function with the new API set_jack().
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the compile error introduced by: "ASoC: Intel: bytcr_rt5640:
Configure PLL1 before using it".
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the "realtek,in1-differential" or "realtek,in3-differential"
device-property when the BYT_RT5640_DIFF_MIC quirk is set instead of
directly poking the codec registers.
This also fixes the BYT_RT5640_DIFF_MIC quirk not working when
combined with BYT_RT5640_IN3_MAP.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When platform_clock_control() first selects PLL1 as sysclk the PLL_CTRL
registers have not been setup yet and we effectively have an invalid clock
configuration until byt_rt5640_aif1_hw_params() gets called.
Add a new byt_rt5640_prepare_and_enable_pll1() helper and use that from
both platform_clock_control() and byt_rt5640_aif1_hw_params() to fix this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the check that ret_val is not -ENOENT is always true and
the quirk bit BYT_RY5651_MCLK_EN is never being cleared because ret_val
is always zero at this point from a previous assignment earlier on.
I believe that ret_val should actually be assigned to the return from
devm_clk_get() as this can return -ENOENT (from a deeper call to
clk_get_sys) and that was the original intention to check this.
Detected by CoverityScan, CID#1460228 ("Logically dead code")
Fixes: 02c0a3b304 ("ASoC: Intel: bytcr_rt5651: add MCLK, quirks and cleanups")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Hard-coded setups conflict with topology defined ones. Move this code to
codec_fixup so that SOF can override codec dai settings, e.g. to only use
2 channels.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
In kabylake_audio_probe which is not atomic context, we use GFP_ATOMIC
flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In kabylake_audio_probe which is not atomic context, we use GFP_ATOMIC
flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In kabylake_audio_probe which is not atomic context, we use GFP_ATOMIC
flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In snd_cht_mc_probe which is not atomic context, we use GFP_ATOMIC
flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In snd_byt_rt5651_mc_probe which is not atomic context, we use
GFP_ATOMIC flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In snd_byt_cht_es8316_mc_probe which is not atomic context, we use
GFP_ATOMIC flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In byt_max98090_probe which is not atomic context, we use GFP_ATOMIC
flag with memory allocation, fix that by using GFP_KERNEL.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The sound/soc/intel/common/sst-acpi.c code only tries to load the
"baytrail-pcm-audio" driver (and supporting board drivers) when
SND_SST_ATOM_HIFI2_PLATFORM is not enabled, since otherwise these
are handled by snd-soc-sst-atom-hifi2-platform.ko.
Since these thus will never be used when SND_SST_ATOM_HIFI2_PLATFORM is
enabled, building these drivers when it is enabled is useless.
Add a Kconfig dependency to reflect this, so that SND_SOC_INTEL_BAYTRAIL
cannot be enabled when SND_SST_ATOM_HIFI2_PLATFORM is also enabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The two commits:
81e9b0a078 ASoC: topology: Give more data to clients via callbacks
28aa6f7779 ASoC: topology: Add callback for DAPM route load/unload
break the build so revert them.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mark Brown <broonie@kernel.org>
Give topology clients more access to the topology data by passing index,
pcm, link_config and dai_driver to clients. This allows clients to fully
instantiate and track topology objects.
The SOF driver is the first user of these new APIs and needs them to build
component topology driver and FW objects.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
By default all the streams are mapped to all links after controller is
reset which causes stream to be broadcast on all the links.
This patch resets the stream-link mapping after controller reset. The
stream is mapped later to the appropriate link as part of stream setup.
Tested-by: Abhijeet Kumar <abhijeet.kumar@intel.com>
Signed-off-by: Rakesh Ughreja <rakesh.a.ughreja@intel.com>
Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
An application can choose to call .prepare function
any number of times. In such scenarios, there is a
need to reset the DSP pipeline.
Signed-off-by: Pardha Saradhi K <pardha.saradhi.kesapragada@intel.com>
Signed-off-by: Divya Prakash <divya1.prakash@intel.com>
Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SKL and KBL driver used separate set of fw ops for library loading.
However, with the unification of fw binary, use the common set of fw
ops for both
Signed-off-by: Pradeep Tewani <pradeep.d.tewani@intel.com>
Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently during destroy pipeline the gateway is disabled
before DMA completion. This leads to improper draining of
data and subsequently causing issues on HD-Audio DMA.
Hence added a new pipe reset IPC in skl_pcm_hw_free in
which the Gateway Enable(GEN bit) is reset to 0 after
DMA completion in skl_pcm_trigger.
Signed-off-by: Divya Prakash <divya1.prakash@intel.com>
Signed-off-by: Sriram Periyasamy <sriramx.periyasamy@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_cht_mc_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
snd_cht_mc_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_cht_mc_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
snd_cht_mc_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_byt_rt5640_mc_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
snd_byt_rt5640_mc_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Despite never getting called from atomic context,
broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The split between ACPI and PCI platforms generated issues with randconfig:
with SND_SST_ATOM_HIFI2_PLATFORM_PCI=y and
SND_SST_ATOM_HIFI2_PLATFORM=m, we get this module link failure:
ERROR: "sst_context_init"
[sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
ERROR: "sst_context_cleanup"
[sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
ERROR: "sst_alloc_drv_context"
[sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
ERROR: "intel_sst_pm" [sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko]
undefined!
ERROR: "sst_configure_runtime_pm"
[sound/soc/intel/atom/sst/snd-intel-sst-acpi.ko] undefined!
To keep things simple, let's expose two configs for
SND_SST_ATOM_HIFI2_PLATFORM_PCI and SND_SST_ATOM_HIFI2_PLATFORM_ACPI,
which select a common SND_SST_ATOM_HIFI2_PLATFORM option. To avoid
breaking existing solutions with the semantics change,
SND_SST_ATOM_HIFI2_PLATFORM_ACPI uses "default ACPI" so that "make
oldnoconfig" and "make olddefconfig" still work as expected.
Also remove mentions of Medfield while we are at it since it was
removed recently.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4772c16ede ("ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI
dependencies")
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>
Kees Cook