summaryrefslogtreecommitdiff
path: root/sound/soc/intel
AgeCommit message (Collapse)AuthorFilesLines
2018-05-17ASoC: Intel: bytcr_rt5640: Add quirks for various devicesHans de Goede1-0/+141
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Use dmi_first_match() for DMI quirk handlingHans de Goede1-15/+4
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Sort DMI quirk list alphabeticallyHans de Goede1-20/+21
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Add default jack-detect settingsHans de Goede1-1/+7
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Unify BYTCR input defaultsHans de Goede1-3/+6
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Change BYTCR default input to IN3Hans de Goede1-1/+1
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Enable jack detectionHans de Goede1-16/+148
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Fix Dell Venue 8 5830 Pro quirkHans de Goede1-2/+3
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>
2018-05-17ASoC: Intel: bytcr_rt5640: Use device properties for setting up dmicHans de Goede1-28/+14
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>
2018-05-17ASoC: rt5663: Use the set_jack() instead of the export functionOder Chiou2-2/+3
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>
2018-05-13ASoC: Intel: bytcr_rt5640: Fix compile errorHans de Goede1-2/+2
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>
2018-05-11ASoC: Intel: bytcr_rt5640: Use device-property for differential micsHans de Goede1-5/+43
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>
2018-05-11ASoC: Intel: bytcr_rt5640: Configure PLL1 before using itHans de Goede1-51/+49
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>
2018-05-03ASoC: Intel: bytcr_rt565: fix missing assignment to ret_valColin Ian King1-2/+3
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: 02c0a3b3047f ("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>
2018-05-01ASoC: Intel: cht-bsw-rt5672: allow for topology-defined codec-dai setupPierre-Louis Bossart1-9/+21
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>
2018-04-20ASoC: Intel: kbl_rt5663_rt5514_max98927: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: kbl_rt5663_max98927: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: kbl_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: cht_bsw_nau8824: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: bytcr_rt5651: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: bytcht_es8316: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-20ASoC: Intel: byt-max98090: Replace GFP_ATOMIC with GFP_KERNELVinod Koul1-1/+1
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>
2018-04-19ASoC: Intel: Disable SND_SOC_INTEL_BAYTRAIL when SND_SST_ATOM_HIFI2_PLATFORM ↵Hans de Goede1-1/+1
is enabled 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>
2018-04-18ASoC: topology: Fix build errorsMark Brown3-12/+20
The two commits: 81e9b0a07889 ASoC: topology: Give more data to clients via callbacks 28aa6f7779f7 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>
2018-04-17ASoC: topology: Give more data to clients via callbacksLiam Girdwood3-20/+12
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>
2018-04-17ASoC: Intel: Skylake: Reset stream to link mappingRakesh Ughreja1-0/+7
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>
2018-04-17ASoC: Intel: Skylake: Reset DSP Pipelines in preparePardha Saradhi K1-4/+20
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>
2018-04-17ASoC: Intel: Skylake: Unify the fw ops for SKL and KBLPradeep Tewani3-36/+3
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>
2018-04-17ASoC: Intel: Skylake: Reset DSP pipe in skl_pcm_hw_freeDivya Prakash1-0/+12
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>
2018-04-16Merge branch 'asoc-4.17' into asoc-4.18 to get adau17x1 changes soMark Brown1-9/+13
further patches can be applied.
2018-04-16ASoC: intel: skl_rt286: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
skylake_audio_probe 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>
2018-04-16ASoC: intel: skl_nau88l25_ssm4567: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
skylake_audio_probe 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>
2018-04-16ASoC: intel: skl_nau88l25_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
skylake_audio_probe 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>
2018-04-16ASoC: intel: cht_bsw_rt5645: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
snd_cht_mc_probe 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>
2018-04-16ASoC: intel: cht_bsw_max98090_ti: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
snd_cht_mc_probe 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>
2018-04-16ASoC: intel: bytcr_rt5640: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
snd_byt_rt5640_mc_probe 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>
2018-04-16ASoC: intel: bxt_rt298: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
broxton_audio_probe 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>
2018-04-16ASoC: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in ↵Jia-Ju Bai1-1/+1
broxton_audio_probe 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>
2018-04-12ASoC: Intel: atom: fix ACPI/PCI KconfigPierre-Louis Bossart1-9/+13
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: 4772c16ede52 ("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>
2018-03-28Merge remote-tracking branches 'asoc/topic/rt5670', 'asoc/topic/sgtl5000', ↵Mark Brown1-10/+8
'asoc/topic/si476x' and 'asoc/topic/sirf' into asoc-next
2018-03-28Merge remote-tracking branches 'asoc/topic/rt5645', 'asoc/topic/rt5651', ↵Mark Brown2-23/+23
'asoc/topic/rt5659' and 'asoc/topic/rt5660' into asoc-next
2018-03-28Merge remote-tracking branches 'asoc/topic/rt298', 'asoc/topic/rt5514', ↵Mark Brown2-6/+6
'asoc/topic/rt5616', 'asoc/topic/rt5631' and 'asoc/topic/rt5640' into asoc-next
2018-03-28ASoC: Intel: bytcr_rt5651: don't use codec anymoreKuninori Morimoto1-2/+2
commit aeec6cc08215 ("ASoC: Intel: bytcr_rt5651: Configure PLL1 before using it") is using codec->dev, but codec is replaced to component. Let's use component Fixes: aeec6cc08215 ("ASoC: Intel: bytcr_rt5651: Configure PLL1 before using it") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-13ASoC: Intel: Skylake: Disable clock and power gating during FW/LIB downloadSanyog Kale5-2/+46
In order to achieve better DMA performance and reduce download time for firmware and library, it is recommended to disable dynamic clock and power gating. In some scenarios, DMA may wait to accumulate more data and last chunk of data never gets completed if dynamic clock and power gating is kept enabled. This patch adds support to disable/enable dynamic clock and power gating and use it during firmware and library download. Signed-off-by: Rakesh Ughreja <rakesh.a.ughreja@intel.com> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com> Signed-off-by: Guneshwor Singh <guneshwor.o.singh@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Select RCCLK on init()Hans de Goede1-0/+5
When the BYT_RT5651_MCLK_EN quirk is set, we disable the MCLK from byt_rt5651_init(), we need to select the RCCLK as sysclk before doing this to make sure that jack-detect works directly after boot. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Change defaults to enable jack-detect, analog micsHans de Goede1-9/+6
Change the default quirk settings to enable jack-detect, analog mics. The old default input mapping of DMIC for non Bay Trail CR devices seems like a poor default as I'm not aware of any Intel SST + rt5651 using devices with a DMIC. All Cherry Trail devices using the bytcr_rt5651 machine driver seem to be modelled after BYT-CR devices, And the only non CR Bay Trail devices with a rt5651 codec I'm aware of are the Minnow boards for which we already have board specific quirks. So it seems better to me to use the BYT-CR defaults everywhere. This e.g. makes the Chuwi Hi8 Pro (CWI513) work ootb without needing a quirk. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Add quirk for the VIOS LTH17 laptopHans de Goede1-0/+13
Add a quirk setting up jack-detect and input routing for the VIOS LTH17 laptop. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Add support for Bay Trail CR / SSP0 using boardsHans de Goede1-16/+201
Despite its name being prefixed with bytcr, before this commit the bytcr_rt5651 machine driver could not work with Bay Trail CR boards, as those only have SSP0 and it only supported SSP0-AIF1 setups. This commit adds support for this, autodetecting AIF1 vs AIF2 based on BIOS tables. While at it also add support for SSP2-AIF2 setups, as that requires only minimal extra code on top of the code adding SSP0-AIF1 / SSP0-AIF2 support. Note this code is all copy-pasted from bytcr_rt5640.c. I've looked into merging the 2 machine drivers into 1 to avoid copy-pasting, but there are enough subtile differences to make this hard *and* with all the quirks the machine driver already is full with if (variant-foo) then ... else ... constructs adding more of these is going to make the code unreadable. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Add new IN2_HS_IN3 input map and a quirk using itHans de Goede1-0/+26
Add a new IN2_HS_IN3 input map and add a quirk for the input mapping and jack-detect source for the Chuwi Vi8 Plus tablet, which uses this new map. Note the Chuwi Vi8 Plus lists an extra GPIO in its codecs ACPI resources which needs to be driven high to enable the external speaker amplifier, this is not supported yet and will be fixed in a future patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: Intel: bytcr_rt5651: Rename IN3_MAP to IN1_HS_IN3_MAPHans de Goede1-11/+11
All the mappings are named for where the internal mic is routed and in that sense the newly added in3_map really is the same as in1_map, what makes it different is that it maps the headset mic at IN3 rather then at IN2. Rename in3_map to in1_hs_in3_map to better reflect what it actually does. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>