Add support for digital volume control. There is no dedicated register
for volume control but instead there are 4. The values of the registers
are determined with exponential floating point math.
So a table was created with register values for 2dB step increments
from -110dB to 0dB.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200221124151.8774-1-dmurphy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The AIU audio controller on the Meson8 and Meson8b SoC families is
compatible with the one found in the later GXBB family. Add compatible
strings for these two older SoC families so the driver can be loaded for
them.
Instead of using the I2S divider from the AIU_CLK_CTRL_MORE register we
need to use the I2S divider from the AIU_CLK_CTRL register. This older
register is less flexible because it only supports four divider settings
(1, 2, 4, 8) compared to the AIU_CLK_CTRL_MORE register (which supports
dividers in the range 0..64).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200220205711.77953-4-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Introduce a struct aiu_platform_data to make the driver aware of
platform specific information. Convert the existing check for the
internal stereo audio codec (only available on GXL) to this new struct.
Support for the 32-bit SoCs will need this as well because the
AIU_CLK_CTRL_MORE register doesn't have the I2S divider bits (and we
need to use the I2S divider from AIU_CLK_CTRL instead).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200220205711.77953-3-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the tlv320adcx140 codec driver family.
The TLV320ADCx140 is a Burr-Brown™ highperformance, audio analog-to-digital
converter (ADC) that supports simultaneous sampling of up to four analog
channels or eight digital channels for the pulse density modulation (PDM)
microphone input. The device supports line and microphone inputs, and
allows for both single-ended and differential input configurations.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200220210759.31466-3-dmurphy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently it is possible to get the following bad config:
WARNING: unmet direct dependencies detected for SND_SOC_WM5110
Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && MFD_WM5110 [=n]
commit ea00d95200 ("ASoC: Use imply for SND_SOC_ALL_CODECS")
commit d8dd3f92a6 ("ASoC: Fix SND_SOC_ALL_CODECS imply misc fallout")
After these two patches the machine drivers still selects the
SND_SOC_WM5110 symbol which doesn't take account of the dependency
added on the MFD_WM5110 symbol, fix this by also adding a dependency on
MFD_WM5110 itself.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200220125654.7064-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The RK3328 reference design uses an external line driver IC as a buffer
on the analog codec output, enabled by the GPIO_MUTE pin, and such a
configuration is currently assumed in the codec driver's direct poking
of GRF_SOC_CON10 to control the GPIO_MUTE output value. However, some
boards wire up analog audio yet use that pin for some other purpose, so
that assumption doesn't always hold. Update this functionality to rely
on an explicit GPIO descriptor, such that it can be managed at the
board level.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5bc383ed1832f0f5d1dcb3c97ad92fd68e5217e3.1581376744.git.robin.murphy@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Existing RK3328 codec drivers have overloaded the GRF phandle to assume
implicit control of the limited-function GPIO_MUTE pin, which is usually
used to enable an external audio line driver IC. Since this pin has a
proper binding of its own (see gpio/rockchip,rk3328-grf-gpio.txt), make
a GPIO explicit in the codec binding too. This will help avoid ambiguity
on boards that use that pin for some other purpose.
(and while touching the example, enforce the "don't include status" rule)
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5f7a399dea8a9dedef57f6f99f0f6ab1c1fdc56a.1581376744.git.robin.murphy@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add additional support for ISENSE and VSENSE feature for the TAS2562.
This feature monitors the output to the loud speaker attempts to
eliminate IR drop errors due to packaging.
This feature is defined in Section 8.4.5 IV Sense of the data sheet.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200219134622.22066-1-dmurphy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit b2354e4009.
This change might have been desirable to ensure the uniqueness of
the component name. It would have helped to better support linux
devices which register multiple components, something is which more
common than initially thought.
However, some card driver are directly using dev_name() to fill the
component names of the dai_link which is a problem if want to change
the way ASoC generates the component names.
Until we figure out the appropriate way to deal with this, revert the
change and keep the names as they were. There might be a couple of warning
related to debugfs (which were already present before the change) but it
is still better than breaking working audio cards.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200219102526.692126-1-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dpcm_end_walk_at_be() has very duplicate code.
dpcm_end_walk_at_be() {
...
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
(1) /* code for Playback */
} else {
(2) /* code for Capture */
}
}
The difference between Playback (1) and Capture (2) code is pointer only
(= "playback_widget" or "caputre_widget").
OTOH, now we already has dai_get_widget() for it.
This means we can merge (1) and (2).
This patch do it and remove duplicated code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/87eeutboul.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a need to use RT5682 as DAI clock master for other codecs
within a platform, which means that the DAI clocks are required to
remain, regardless of whether the RT5682 is actually running
playback/capture.
The RT5682 CCF basic functions are implemented almost by the existing
internal functions and asoc apis. It needs a clk provider (rt5682 mclk)
to generate the bclk and wclk outputs.
The RT5682 CCF supports and restricts as below:
1. Fmt of DAI-AIF1 must be configured to master before using CCF.
2. Only accept a 48MHz clk as the clk provider.
3. Only provide a 48kHz wclk and a set of multiples of wclk as bclk.
There are some temporary limitations in this patch until a better
implementation.
Signed-off-by: Derek Fang <derek.fang@realtek.com>
Link: https://lore.kernel.org/r/1582033912-6841-1-git-send-email-derek.fang@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Define debugfs subdirectory delegated for IPC communication with DSP.
Input format: uint,uint,(...) which are later translated into DWORDS
sequence and further into instances of struct of interest given the IPC
type.
For Extractor probes, following have been enabled:
- PROBE_POINT_ADD (echo <..> probe_points)
- PROBE_POINT_REMOVE (echo <..> probe_points_remove)
- PROBE_POINT_INFO (cat probe_points)
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200218143924.10565-9-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
