AIF3 has some differences from AIF1 and AIF2:
- It supports one channel only
- It supports master mode only
- It is not directly connected to any of the mixers; instead all audio
goes through a mux with AIF2.
- It does not have its own clock dividers; instead it reuses AIF2 BCLK
and LRCK. This means that when both AIF2 and AIF3 are active, they
must use the same sample rate and total frame width. Since AIF2 and
AIF3 are only used for codec2codec DAI links, constraints are not
applicable here; the only thing we can do when the rates don't match
is report an error.
Make the necessary adjustments to support this AIF.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-18-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds support for AIF2, which is stereo and has fullly independent
clocking capability, making it very similar to AIF1.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-17-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The AIF clock control register has the same layout for all three AIFs.
The only difference between them is that AIF3 is missing some fields. We
can reuse the same register field definitions for all three registers,
and use the DAI ID to select the correct register address.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201014061941.4306-16-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the DAI clock setup is correct for all hardware-supported PCM
formats, we can enable them in the driver. With the appropriate support
in the CPU DAI driver, this allows userspace to access the additional
formats.
Since this codec is connected to the CPU via a DAI, not directly, we do
not care if the CPU DAI is using 3-byte or 4-byte formats, so we can
support them both.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-15-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that we guarantee that SYSCLK is running at the optimal rate when
hw_params succeeds, and that it will continue running at that rate,
SYSCLK will always be an integer multiple of BCLK. So we can always
pick the exact divider, not just the closest divider.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-14-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec's clock input is shared among all AIFs, and shared with other
audio-related hardware in the SoC, including I2S and SPDIF controllers.
To ensure sample rates selected by userspace or by codec2codec DAI links
are maintained, the clock rate must be protected while it is in use.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201014061941.4306-13-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
While another stream is active, only allow userspace to use sample rates
that are compatible with the current SYSCLK frequency. This ensures the
actual sample rate will always match what is given in hw_params.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-12-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The sun8i codec has three clock/sample rate domains:
- The AIF1 domain, with a sample rate equal to AIF1 LRCK
- The AIF2 domain, with a sample rate equal to AIF2 LRCK
- The SYSCLK domain, containing the ADC, DAC, and effects (AGC/DRC),
with a sample rate given by a divisor from SYSCLK. The divisor is
controlled by the AIF1_FS or AIF2_FS field in SYS_SR_CTRL, depending
on if SYSCLK's source is AIF1CLK or AIF2CLK, respectively. The exact
sample rate depends on if SYSCLK is running at 22.6 MHz or 24.6 MHz.
When an AIF (currently only AIF1) is active, the ADC and DAC should run
at that sample rate to avoid artifacting. Sample rate conversion is only
available when multiple AIFs are active and are routed to each other;
this means the sample rate conversion hardware usually cannot be used.
Only attach the event hook to the channel 0 AIF widgets, since we only
need one event when a DAI stream starts or stops. Channel 0 is always
brought up with a DAI stream, regardless of the number of channels in
the stream.
The ADC and DAC (along with their effects blocks) can be used even if
no AIFs are in use. In that case, we should select an appropriate sample
rate divisor, instead of keeping the last-used AIF sample rate.
44.1/48 kHz was chosen to balance audio quality and power consumption.
Since the sample rate is tied to active AIF paths, disabling pmdown_time
allows switching to the optimal sample rate immediately, instead of
after a 5 second delay.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201014061941.4306-11-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The system sample rate programmed into the hardware is really a clock
divider from SYSCLK to the ADC and DAC. Since we support two SYSCLK
frequencies, we can use all sample rates corresponding to one of those
frequencies divided by any available divisor.
This commit enables support for those sample rates. It also stops
advertising support for a 64 kHz sample rate, which is not supported.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-10-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The AIFs have a single register controlling DAI parameters in both
directions, including BCLK/LRCK divisor and word size. The DAIs produce
only noise or silence if any of these parameters is wrong. Therefore, we
need to enforce symmetry for these parameters, so starting a new
substream will not break an existing substream.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-9-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that BCLK and LRCK rate calculations in the driver can handle any
hardware-supported slot width and number of slots, allow overriding
those parameters from the device tree.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-8-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the BCLK divisor calculation assumed zero padding and
exactly two slots. In order to support the TDM slot binding and
20/24-bit word sizes, those assumptions must be removed.
Due to hardware limitations, the BCLK/LRCK ratio is not as simple as
"slot_width * slots". However, the correct value is already calculated
elsewhere in this function, since it must also be programmed into the
hardware. Reuse that value to calculate the correct SYSCLK/BCLK divisor.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-7-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec supports only power-of-two BCLK/LRCK divisors. If either the
slot width or the number of slots is not a power of two, the LRCK
divisor must be rounded up to provide enough space. To do that, use
order_base_2 (instead of ilog2, which rounds down).
Since the rounded divisor is also needed for setting the SYSCLK/BCLK
divisor, return the order base 2 instead of fully calculating the
hardware register encoding.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-6-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The hardware supports 8 to 24-bit word sizes on all three of its DAIs,
only one of which is connected to the CPU DAI. Program the word size
based on the actual selected format, instead of assuming limitations
from another driver (which, incedentally, has patches pending to remove
that limitation).
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-5-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When using the I2S, LEFT_J, or RIGHT_J format, the hardware supports
independent BCLK and LRCK inversion control. When using DSP_A or DSP_B,
LRCK inversion is not supported. The register bit is repurposed to
select between DSP_A and DSP_B. Extend the driver to support this.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201014061941.4306-4-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The LRCK inversion bit has a different meaning in DSP mode: it selects
between the DSP A and DSP B formats. To support this, we need to know if
the selected format is a DSP format. One easy way to do this is to set
the format field before the clock inversion fields.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-3-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In preparation for adding additional DAIs to this component, convert the
DAI driver definition to an array. Since this changes all of the lines
in the definition anyway, let's move it closer to the ops function
definitions, instead of on the far side of the DAPM arrays. And while
moving the DAI driver ops, rename the set_fmt hook to match the usual
naming scheme.
Give the existing DAI an explicit ID and more meaningful stream names,
so it will remain unique as more DAIs are added. The AIF widget streams
must be updated to match.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20201014061941.4306-2-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove a level of indirection by getting the device directly from the
passed-in struct snd_soc_dai, instead of going through its component.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-9-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Each left/right pair of AIF input/output channels can be swapped or
combined. This is useful for sending a mono audio source to both sides
of a stereo sink, or for creating complex mixing scenarios.
Add the support to control this feature from userspace.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-8-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Both the left and right side widgets referenced channel 0. This would
unnecessarily power on the right side widget (and its associated path)
when a mono stream was active.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-7-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Whie the aif_in and aif_out widget types are handled exactly the same in
the core DAPM code, a future widget event hook will need the correct
widget type to derive the associated substream. Clean up the widget type
for that reason, and so these widgets will match newly-added widgets for
the other AIFs.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-6-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This cleans up the mixer widget names. The AIF1 AD0 Mixer names were
previously wrong -- they do not control the digital side of the ADC. The
DAC mixer widgets were not wrong, but they were verbose and did not
match the naming scheme of the other widgets.
The mixer controls are not renamed because they are exposed to
userspace.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-5-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Sort the remaining pieces of the DAPM driver so that they are all in the
same order among controls/widgets/routes, and so they roughly match the
register word and bit order of the hardware. This nicely separates the
AIF-related widgets from the ADC/DAC widgets, which allows the AIF
widgets to stay in a logical order as more AIFs are added to the driver.
No widgets are renamed, to ease verification that this commit makes no
functional change.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-4-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This matches the module power-up/down sequence from the vendor's driver.
While updating these widgets/routes, reorder them to match the register
and bit layout of the hardware. This puts them in the same place in the
widget and route arrays (previously they were at opposite ends), and it
makes it easier to track which parts of which registers are implemented.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-3-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The sun8i codec is effectively an on-die variant of the X-Powers AC100
codec. The AC100 can derive its clocks from either of two I2S master
clocks or an internal PLL. For the on-die variant, Allwinner replaced
the codec's own PLL with a connection to SoC's existing PLL_AUDIO, and
they connected both I2S MCLK inputs to the same source -- which happens
to be an integer divider from the same PLL_AUDIO.
So there's actually no clocking flexibility. To run SYSCLK at the
required rate, it must be run straight from the PLL. The only choice is
whether it goes through AIF1CLK or AIF2CLK. Since both run at the same
rate, the only effect of that choice is which field in SYS_SR_CTRL
(AIF1_FS or AIF2_FS) controls the system sample rate.
Since AIFnCLK is required to bring up the corresponding DAI, and AIF1
(connected to the CPU) is used most often, let's use AIF1CLK as the
SYSCLK parent. That means we no longer need to set AIF2_FS.
Since this clock tree never changes, we can program it from the
component probe function, instead of using DAPM widgets. The DAPM
widgets unnecessarily change clock parents when the codec goes in/out
of idle and the supply widgets are powered up/down.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201001021148.15852-2-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
By representing the module clock as a DAPM widget, we ensure that the
clock is only enabled when the module is actually in use, without
additional code in runtime PM hooks.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200831034852.18841-10-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When attached to the regmap, the bus clock is automatically enabled as
needed to access device registers. This avoids needing code to manage it
separately in the driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200831034852.18841-9-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
All other definitions are sorted from largest to smallest bit number.
This makes the AIF1CLK_CTRL mask constants consistent with them.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200831034852.18841-8-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Several fields have inconsistent indentation, presumably because the
patch "looked correct" due to the additional "+" character at the
beginning of the line.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200831034852.18841-7-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Even though they are for the left channel mixer, they are documented as
"MXR_SRC". This matches the naming scheme used for the main DAC. The "R"
is part of the abbreviation for "mixer", not a reference to the channel.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200831034852.18841-5-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver is for the digital part of the codec only. The analog part,
including the microphone inputs, is managed by a separate driver. These
widgets look like they were copied from sun4i-codec. Since they do not
perform any function in this driver, remove them.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200831034852.18841-2-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Due to a mistake made while reordering patches, commit 90cac93297
("ASoC: sun8i-codec: Fix DAPM to match the hardware topology") added
the sun8i_codec_component_probe function without referencing it from
the component definition. Add the reference so the probe function gets
called as expected.
Fixes: 90cac93297 ("ASoC: sun8i-codec: Fix DAPM to match the hardware topology")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200819034038.46418-1-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
On the A64, as tested using the PinePhone, the current code causes the
left/right channels to be swapped during I2S playback from the CPU on
AIF1, and breaks DSP_A communication with the modem on AIF2. Both of
these are fixed when LRCK is no longer inverted.
Trusting that the comment in the code is correct, the existing behavior
is kept for the A33.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200726012557.38282-5-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The sun8i-codec driver provides ALSA controls for enabling/disabling
each of the inputs to the AIF1 Slot 0 and DAC mixers. For two of these
inputs (ADC->DAC and AIF1 DA0->AIF1 AD0), the audio source is
implemented, so the mixer inputs can be used.
However, because the DAPM routes are missing, these mixer inputs only
work when both the source and the mixer happen to be part of other
active audio paths. Adding the appropriate routes makes these ALSA
controls function all of the time.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200726012557.38282-4-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The A33/A64 digital codec has 4 physical inputs and 4 physical outputs:
3 AIFs/DAIs and one ADC/DAC pair. Internal routing is accomplished by
a 4-channel mixer connected to each output.
The analog and digital sides of the ADC/DAC are in separate ASoC
components, so card-level DAPM routes (provided in the device tree) are
necessary to connect them together. Currently, these routes are wrong.
For AIF1 Playback, the correct topology is:
||<<============ sun8i-codec ===========>>||
|| ||
CPU DAI -> AIF1 DA0 -> DAC Mixer -> DAC (digital) -> DAC (analog)
|| ||
but the driver and device trees currently describe:
|| ||
CPU DAI -> AIF1 DA0 -------------------------------> DAC (analog)
|| \--> DAC Mixer -> ??? [dead end] ||
For AIF1 Capture, there is an additional problem, because the Mixer
route is backward. The topology should be:
|| ||
ADC (analog) -> ADC (digital) -> AIF1 AD0 Mixer -> AIF1 AD0 -> CPU DAI
|| ||
but the driver and device trees currently describe:
|| ||
ADC (analog) -> AIF1 AD0 ------------------------------------> CPU DAI
|| \--> ADC Mixer -> ??? [dead end] ||
The ADC/DAC are only powered because AIF1 AD0 (capture) has supply
routes from the ADC, and AIF1 DA0 (playback) has supply routes from the
DAC. However, neither set of supply routes matches the hardware
topology. Audio can be routed among AIF1/2/3 without using the ADC or
DAC at all; and audio can be routed from the ADC to the DAC without
using any AIFs (via the "ADC Digital DAC Playback Switch"). Because the
DAPM routes are wrong, both of these use cases are currently broken.
This commit adds the necessary widgets and routes to represent the real
hardware topology, with functionality equivalent to the current driver.
For the existing "allwinner,sun8i-a33-codec" compatible, widgets with
the old names are kept as wrappers around the new widgets, so existing
device trees will continue to work. For "allwinner,sun50i-a64-codec",
the old widgets can be omitted, because no device trees yet use that
compatible.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20200726012557.38282-3-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This field is not used anywhere in the driver, so remove it.
Fixes: 36c684936f ("ASoC: Add sun8i digital audio codec")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200217064250.15516-5-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the correct mask for this two-bit field. This fixes setting the DAI
data format to RIGHT_J or DSP_A.
Fixes: 36c684936f ("ASoC: Add sun8i digital audio codec")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20200217064250.15516-7-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190727150738.54764-35-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Based on 3 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [kishon] [vijay] [abraham]
[i] [kishon]@[ti] [com] this program is distributed in the hope that
it will be useful but without any warranty without even the implied
warranty of merchantability or fitness for a particular purpose see
the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [graeme] [gregory]
[gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
[kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
[hk] [hemahk]@[ti] [com] this program is distributed in the hope
that it will be useful but without any warranty without even the
implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1105 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sun8i-codec misses a route from ADC to AIF1 Slot 0 ADC. Add it
to the driver to avoid adding it to every dts.
Fixes: eda85d1fee ("ASoC: sun8i-codec: Add ADC support for a33")
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
drvdata is actually sun8i_codec, not snd_soc_card, so it crashes
when calling snd_soc_card_get_drvdata().
Drop card and scodec vars anyway since we don't need to
disable/unprepare clocks - it's already done by calling
runtime_suspend()
Drop clk_disable_unprepare() calls for the same reason.
Fixes: 36c684936f ("ASoC: Add sun8i digital audio codec")
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
BCLK / LRCK ratio should be sample size * channels, but it was
hardcoded to 32 (0x1 is 32 as per A33 and A64 datasheets).
Calculate it basing on sample size and number of channels.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add ADC support for the sun8i-codec driver.
This driver uses microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Pierre-Louis Bossart