For some reason we test if the machine is passed as a parameter before
fixing up the codec name. This is unnecessary, generates false
positives in static analysis tools and done only in this machine
driver, remove and adjust indentation.
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper to override dailink platform name, if passed as parameter
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't populate the const arrays on the stack but instead make
it static. Makes the object code smaller, for example:
Before:
text data bss dec hex filename
14107 8832 224 23163 5a7b bytcht_es8316.o
After:
text data bss dec hex filename
14015 8896 224 23135 5a5f bytcht_es8316.o
(gcc version 8.2.0 x86_64)
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>
Quite a big batch of fixes here. There's a couple of things going on,
the main one is that we found some issues with not deferring probe when
we should, causing us to skip some driver initialization. The fixes for
this then in turn exposed some issues with how we were searching for
components which had previously gone unnoticed due to the original
issue.
There's also been the normal driver specific stuff and there's been what
looks like several batches of automated scanning for issues which have
generated quite a large set of smaller fixes for potential crashes and
missed error handling.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlxBy/wTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0HNQB/wI7qx/bNGOX1p2C0M5ENdgsMcYDpMh
OHD073hL4wDkNJ/O2josnceCtrPUS5tuOxmx765IFXrAR4FWlNezQL4dHwTNGfG9
Femd6iAxv47lC2fROpuHfB0j32LIjVrHLYDG0wAiDvteXK2VrGbj8vedfWqflOBj
PX2kqkkgWfSCTrEYdrE09ExYoYKYdEqU/LEKFmIUnMuXc/HNHLo6e1sFNzTo8DIo
g5P8nQ//Qgi1U9UWMabKjy4lYL2Tcid9jcNlz0QIffK2qwIEpVBeuhqJaT4sQrf5
G51UrSk2y4lJ0t9WXv1SwQTDi2slCCGcOHA3fylGkJl1cxgOFMAR37Xs
=ev1L
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlxCJZ0THGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0L+2B/0VnSutpVWaJnGyBuJ6zrydcSIW4183
G51jmioR10cl5LDV0DiI9l7IoiOwUyODbrIl/swoQPs7FWUsFRGFYytdmAoqaKIC
HK1j4D6Tlzac++e6bP6G6NzBMW6TGTu8c7hu3UtIGCz5uPRUKBthnndHmSbEB4h+
10N7RMs9+/BvH1Zt+x9VqEIP5OHpwc7rP/8yANYbQCY7CPehqDiGpE7SvUgFFl5t
IHx0nM1lJNeJyeu0Z/9BGAB5GWM/DzuMSrppNwl2k/QujSSyf1EPZvThpYNCBbnQ
6cQ51+7SZi06ejzMBB5h5z/9yFZTSKmTwFwzJwg/fJ/QngZVkksRRNLV
=9LPf
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.0-rc2' into asoc-5.1
ASoC: Fixes for v5.0
Quite a big batch of fixes here. There's a couple of things going on,
the main one is that we found some issues with not deferring probe when
we should, causing us to skip some driver initialization. The fixes for
this then in turn exposed some issues with how we were searching for
components which had previously gone unnoticed due to the original
issue.
There's also been the normal driver specific stuff and there's been what
looks like several batches of automated scanning for issues which have
generated quite a large set of smaller fixes for potential crashes and
missed error handling.
Quite a big batch of fixes here. There's a couple of things going on,
the main one is that we found some issues with not deferring probe when
we should, causing us to skip some driver initialization. The fixes for
this then in turn exposed some issues with how we were searching for
components which had previously gone unnoticed due to the original
issue.
There's also been the normal driver specific stuff and there's been what
looks like several batches of automated scanning for issues which have
generated quite a large set of smaller fixes for potential crashes and
missed error handling.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlxBy/wTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0HNQB/wI7qx/bNGOX1p2C0M5ENdgsMcYDpMh
OHD073hL4wDkNJ/O2josnceCtrPUS5tuOxmx765IFXrAR4FWlNezQL4dHwTNGfG9
Femd6iAxv47lC2fROpuHfB0j32LIjVrHLYDG0wAiDvteXK2VrGbj8vedfWqflOBj
PX2kqkkgWfSCTrEYdrE09ExYoYKYdEqU/LEKFmIUnMuXc/HNHLo6e1sFNzTo8DIo
g5P8nQ//Qgi1U9UWMabKjy4lYL2Tcid9jcNlz0QIffK2qwIEpVBeuhqJaT4sQrf5
G51UrSk2y4lJ0t9WXv1SwQTDi2slCCGcOHA3fylGkJl1cxgOFMAR37Xs
=ev1L
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.0-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.0
Quite a big batch of fixes here. There's a couple of things going on,
the main one is that we found some issues with not deferring probe when
we should, causing us to skip some driver initialization. The fixes for
this then in turn exposed some issues with how we were searching for
components which had previously gone unnoticed due to the original
issue.
There's also been the normal driver specific stuff and there's been what
looks like several batches of automated scanning for issues which have
generated quite a large set of smaller fixes for potential crashes and
missed error handling.
Since the refactoring of HD-audio display power management, the
display power status is managed per domain. Meanwhile the ASoC
hdac_hdmi driver still keeps and relies (incorrectly) on the
refcounting together with ASoC skl driver, and this leads to the
display state always on.
This patch is an attempt to address the regression by simplifying the
PM code of ASoC skl and hdac_hdmi drivers. Basically, since the
refactoring, we don't have to manage the display power at HD-audio
controller suspend / resume but only at HD-audio HDMI codec suspend /
resume. So the patch drops the superfluous snd_hdac_display_power()
calls in skl driver.
Meanwhile, in hdac_hdmi side, we rewrite the PM call just to re-use
the runtime PM callbacks like other drivers do. Now the logic is
simple: turn off at suspend and turn on at resume.
The patch also fixes the possibly missing display-power off at skl
driver removal as well as some error paths at probe.
Fixes: 029d92c289 ("ALSA: hda: Refactor display power management")
Reported-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The snd_byt_cht_es8316_mc_remove() use the platform drvdata as a type
of 'struct byt_cht_es8316_private', but snd_byt_cht_es8316_mc_probe()
set it to 'struct snd_soc_card', as suggested by Dan Carpenter, fix
the usage in snd_byt_cht_es8316_mc_remove().
Fixes: 0d3e91da07 ("ASoC: Intel: bytcht_es8316: Add external speaker mux support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
move the codec PLL to rt5682_codec_init, because codec only need to config the clock source/PLL once.
As the result, remove the platform_clock_controls since no need to control clock anymore.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
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>
Add a DMI quirk for the Point of View TAB-P1006W-232 (v1.0) tablet, this
tablet is special in a number of ways:
1) It uses the 2nd GPIO resource in the ACPI tables for jack-detect rather
then using the rt5651 codec's builtin jack-detect functionality
2) It uses the 3th GPIO resource in the ACPI tables to control the
external amplifier rather then the usual first non GpioInt resource and
the GPIO is active-low.
3) It is a BYTCR device, without a CHAN package and it uses SSP0-AIF1
rather then the default SSP0-AIF2.
4) Its internal mic is a digital mic (the first x86 rt5651 device that
I'm aware of which does this), combined with having its headset-mic
connected to IN2.
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some board designs hook the jack-detect up to an external GPIO, rather
then to one of the codec pins, add support for this.
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add quirks module parameter to allow manually specifying quirks
from the kernel commandline (or modprobe.conf).
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 37c7401e8c ("ASoC: Intel: bytcr_rt5651: Fix DMIC map
headsetmic mapping"), changed the headsetmic mapping from IN3P to IN2P,
this was based on the observation that all bytcr_rt5651 devices I have
access to (7 devices) where all using IN3P for the headsetmic. This was
an attempt to unifify / simplify the mapping, but it was wrong.
None of those devices was actually using a digital internal mic. Now I've
access to a Point of View TAB-P1006W-232 (v1.0) tabler, which does use a
DMIC and it does have its headsetmic connected to IN2P, showing that the
original mapping was correct, so this commit reverts the change changing
the mapping back to IN2P.
Fixes: 37c7401e8c ("ASoC: Intel: bytcr_rt5651: Fix DMIC map ... mapping")
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Point of View TAB-P1006W-232 (v1.0) tablet uses 10EC5640 as
ACPI HID, but it has a rt5651 codec add a quirk for this.
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_pcm_lib_malloc_pages() may fail, so let's check its status and
return its error code upstream.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Add quirks to select the correct input map, jack-detect options
and channel map to make sound work on the ASUS MeMO Pad 7 (ME176C).
Note: Although sound works out of the box, jack detection currently
requires overriding the ACPI DSDT table. This is necessary because
the rt5640 ACPI device (10EC5640) has the wrong GPIO listed as
interrupt (one of the Bluetooth GPIOs).
The correct GPIO is GPO2 0x0004 (listed as the first GPIO in the
Intel(R) Audio Machine Driver - AMCR0F28 device).
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some devices detected as BYT-T by the PMIC-type based detection
have only a single IRQ listed in the 80860F28 ACPI device. This
causes -ENXIO later when attempting to get the IRQ at index 5.
It turns out these devices behave more like BYT-CR devices,
and using the IRQ at index 0 makes sound work correctly.
This patch adds a fallback for these devices to is_byt_cr():
If there is no IRQ resource at index 5, treating the device
as BYT-T is guaranteed to fail later, so we can safely treat
these devices as BYT-CR without breaking any working device.
Link: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-December/143176.html
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
is_byt_cr() and its usage can be simplified by returning the bool
directly, instead of through a pointer. This works because the
return value is just treated as bytcr = false and is not used
otherwise.
This patch also removes the extra check of
IS_ENABLED(CONFIG_IOSF_MBI) in favor of checking
iosf_mbi_available() directly. The header already takes care
of returning false if the config option is not enabled.
No functional change.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some BYTCR devices use an ES8316 codec, add an ACPI match table entry
for this.
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>
Depending on the input-map and on if 1 or 2 speakers are connected,
userspace needs to use a different UCM profile.
Since we already deal with quirks in the kernel driver and set the
input-map from the kernel, add a quirk for devices with a single / mono
speaker and set the card's long_name based on the input and speaker
quirks, so that userspace can use the long_name to pick the right UCM
profile.
This change, including how the long_name is build-up mirrors how we do
this in the bytcr_rt5640 and bytcr_rt5651 machine drivers.
Note since all devices I have access to use a mono speaker setup I've
chosen to default the speaker setting to mono.
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>
After adding jack-detect support we have 3 microphone input switches:
"Microphone 1", "Microphone 2" and "Headset Mic". But the ES8316 has only
2 microphone inputs.
In the app-note explaining how to use the codec and on the 3 boards I
have one input is used for an internal microphone and one for the headset
microphone. On the 2 CHT boards I have the internal mic is on on MIC1 and
the headset mic is on MIC2, on the BYTCR board I have it is the other way
around.
This commit replaces the 2 "Microphone 1" and "Microphone 2" input switches
with a single "Internal Mic" switch and adds support for selecting either
possible input mapping.
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 ES8316 only has a single (amplified) output. The ES8316 appnote showing
the intended usage uses a jack-receptacle which physically disconnects the
speakers from the output when a jack is plugged in.
But all 3 devices using the es8316 which I have (2 Cherry Trail devices and
one Bay Trail CR device), use an analog mux to disconnect the speakers,
driven by a GPIO.
This commit adds support for this, modelling this as a separate speaker
widget / dapm pin-switch which sets the mux to drive the speakers when
selected.
The intend is for userspace to use the recently added jack-detect support
and then automatically select either the Headphone or Speaker output based
on that.
Note this commit includes a workaround for an ACPI table bug which is
present on 2 of the 3 devices I have, see the added comment in the code.
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>
Hookup the jack-detect support added to the codec driver.
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 support for having the codec connected to SSP0 instead of SSP2. This
is controlled through a new quirk parameter, similar to how this is done
in the bytcr_rt5640 and bytcr_rt5651 machine drivers.
Bay Trail CR (cost reduced) SoCs do not have an SSP2, so we default to SSP0
there.
Note the SPP0 quirk gets BIT(16) because bits 0-15 are reserved for non
boolean quirks like the input-map added in a later commit in this series.
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>
Some minor refactoring:
1) Group the code setting the card dev and prive pointers together with
registering the card
2) Properly put the comment about registering the card at the place where
we actually register the card and add a new comment for getting the clk
3) Add a struct device *dev helper variable (this will be used more in
follow up commits)
4) Reword error message to have the same "foo failed: %d" wording as others
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>
For lack of a better (non-random) way of sorting includes more and more
files in the kernel are moving over to sorting the includes alphabetically.
Move the bytcht_es8316 driver over to this sorting before we add a
bunch of more includes.
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>
Fix Sparse warnings with two machine drivers which weren't updated
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Detected with Coccinelle
skl-messages.c:419:5-32: WARNING: Comparison to bool
skl-pcm.c:1426:6-33: WARNING: Comparison to bool
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Detected with Coccinelle
sound/soc/intel/skylake/skl-topology.c:3106:16-20: WARNING: casting
value returned by memory allocation function to (char *) is useless.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
After 'commit 5d32a66541 ("PCI/ACPI: Allow ACPI to be built without
CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
satisfied implicitly through dependencies on CONFIG_ACPI have to be
specified directly. This code relies on IOSF_MBI and IOSF_MBI depends
on PCI. For this reason, add a direct dependency on CONFIG_PCI to the
IOSF_MBI driver.
Fixes: 5d32a66541 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason this field was set to zero when all other drivers use
.dynamic = 1 for front-ends. This change was tested on Dell XPS13 and
has no impact with the existing legacy driver. The SOF driver also works
with this change which enables it to override the fixed topology.
Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
