In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the everest es7241 which is a simple 2 channels
analog to digital converter.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We are currently using power saving mode for button detection.
However, it will impact the headset recording performance.
This patch will switch button detection to normal mode in capture
and switch to power saving mode in the end of capture.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the VDD and AVDD power supplies to the DAPM graph as some board may
need to enable a regulator to turn them on.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For each supported sample rate, the es7134 can work with several
mclk / sample rate ratio. Check if ratio we get is actually OK.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
64Khz is actually not supported by the es7134 according to the datasheet
Fixes: 9000b59d7a ("ASoC: es7134: add es7134 DAC driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The .set_pll() and .set_clkdiv() callbacks are considered legacy and should
not be used anymore. In order to support PXA boards on DT platforms, remove
them and let the code figure out the correct dividers and PLL base
frequencies itself.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit d767d3ce5c ("ASoC: pxa: provide PCM ops for ssp, i2s and ac97
components") created a build-time dependency to SND_PXA2XX_LIB but
missed to reflect that in Kconfig.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
use list_head for sub_dais,
since original sub_dais array is sparsely occupied
Signed-off-by: KaiChieh Chuang <kaichieh.chuang@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This platform is no longer needed on DT boards, so let's remove them to
avoid confusion. DT bindings should use the CPU DAIs (I2S/SSP/AC97)
directly.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the functions are now available through pxa2xx-lib, hook them up
to pxa-sspi, pxa-ac97 and pxa-i2s. This allows DT platforms to use the DAIs
without a platform driver.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
To get rid of some intermediate platform layers, move pxa2xx_soc_pcm_new()
and pxa2xx_pcm_ops in pxa2xx-lib.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the namespace a bit and drop the __ prefix of all functions
exported by pxa2xx-lib. This improves the readability of the code.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the PXA SSP bits are ported over to generic DMA, the pxa2xx-pcm
code only has a single user left. This patch folds the remaining bits into
its only user and removes the unnecessary glue layer along with its header
file.
The include dependency to linux/dma/pxa-dma.h is also gone now.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend dpcm_merge_chan to also check backend cpu dai channels
capabilities. Apply the same policy as soc_pcm_init_runtime_hw() for
multicodec links and only check cpu dai in this case.
Cc: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The > should be >= or we could read one element beyond the end of the
port_maps[] array.
Fixes: 7fa2d70f97 ("ASoC: qdsp6: q6afe: Add q6afe driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add simple-audio-amplifier to the list of available compatible
Suggested-by: Nicolò Veronese <nicveronese@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The dio2125 is simple enough that we can make it a generic component.
Just rename and sed the dio2125 amplifier driver to simple_amplifier.
Suggested-by: Nicolò Veronese <nicveronese@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As we get more entries in the DMI quirk table it is nice to have some
sort of ordering in the table, sort it alphabetically.
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>
One some models (Chuwi Vi8 Plus, Chuwi Hi8 Pro) the headphone output has
left and right swapped. This can be fixed in with special mixer settings
in the UCM profile, bit this requires these devices loading a different
UCM profile.
This commit adds a BYT_RT5651_HP_LR_SWAPPED quirk for this and postfixes
the longname with "-hp-swapped" if set, so that a different UCM profile
will be loaded.
We can safely do this without causing regressions (UCM profile not found
due to the longname change) as the UCM profiles are not in upstream
alsa-lib yet.
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>
Now that the headset-mic is always IN3 there is no reason to have
the headset-mic mapping in the long-name.
This commit simplifies the long name to "bytcr-rt5651-<intmic-map>-mic".
We can safely do this without causing regressions (UCM profile not found
due to the longname change) as the UCM profiles are not in upstream
alsa-lib yet.
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 initial bytcr_rt5651 machine driver commit mapped IN2 as the headset
mic. In retrospect this is not correct as all known boards have the headset
mic on IN3.
This commit fixes the original DMIC mapping to correctly have the headset
mic on IN3.
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 initial bytcr_rt5651 machine driver commit mapped IN2 as the headset
mic. In retrospect this is not correct as all known boards have the headset
mic on IN3. To workaround this special IN?_HS_IN3 mappings were added.
This commit fixes the original IN1 mapping to correctly have the headset
mic on IN3, moves all users of the IN1_HS_IN3 mapping over to the fixed
IN1_MAP and drops the now no longer needed IN1_HS_IN3 mapping.
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>
BYT_RT5651_IN2_MAP was introduced in commit 39712db878 ("SoC: intel: byt:
Introduce new custom IN2 map"), uses in commit 2fe30129b0 ("ASoC: intel:
byt: Enable IN2 map quirk for a KIANO laptop"), only to be replaced by a
new BYT_RT5651_IN1_IN2_MAP quirk in commit ea261bd02a ("ASoC: intel:
byt: Introduce new map for dual mics") quickly afterwards, because the
KIANO laptop has 2 internal mics on IN1 and IN2 and the headset mic is
not in IN1 where the BYT_RT5651_IN2_MAP maps it, but on IN3.
Now that the KIANO quirk entry uses BYT_RT5651_IN1_IN2_MAP, there are no
users of BYT_RT5651_IN2_MAP left. This makes sense since the headset mic
seems to always be connected to IN3, so BYT_RT5651_IN2_MAP is not useful.
To deal with BYT_RT5651_IN2_MAP wrongly mapping the headset mic to IN1,
BYT_RT5651_IN2_HS_IN3_MAP was added in commit f026e06317 ("ASoC: Intel:
bytcr_rt5651: Add new IN2_HS_IN3 input map and a quirk using it"). This
was based on the assumption then some devices have the internal mic
connected to IN2 only. Further testing has shown that this is wrong and the
internal mic is always connected to IN1 and sometimes to both IN1 and IN2.
TL;DR: Both BYT_RT5651_IN2_MAP and BYT_RT5651_IN2_HS_IN3_MAP are based on
on wrong assumptions from the past and are no longer useful now, so they
can both be removed.
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>
Fix the quirk logging code not logging the IN1_IN2_MAP quirk.
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>
Further testing on all 6 model x86 tablets with a rt5651 which I have
access to for testing has shown that their single (mono) microphone is
connected to both IN1 *and* IN2.
The previous default mapping of IN2 was based on testing on the same 6
tablets, where the internal mic works fine with a mapping of IN2. But it
works fine too with a mapping of IN1.
This commit changes the default input mapping to to use IN1 instead of
IN2, to match the mapping used for the other mono devices in the DMI quirk
table. So that we need less different mappings.
The same change is made to the Chuwi Vi8 Plus quirks, which is one of the
6 models tested.
This is a preparation patch for simplifying the maps in a follow-up commit.
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>
