This patch refines the comments by:
1) Removing all out-of-date comments
2) Removing all not-so-useful comments
3) Unifying the styles of all comments
4) Shortening comments to be more conise
5) Adding comments to improve code readablity
6) Moving all register related comments to fsl_ssi.h
7) Adding comments to all register and field defines
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Tested-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NTimur Tabi <timur@tabi.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

There should be no trouble to understand dev = pdev->dev.
This can save some space to have more print info or save
some wrapped lines.
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Tested-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NTimur Tabi <timur@tabi.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Shorten the private data structure to save some wrapped lines.
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Tested-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NTimur Tabi <timur@tabi.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

When testing AC'97 capture on UDOO board (currently the only user of
fsl_ssi driver in the AC'97 mode) it become obvious that there is a massive
distortion above certain, small input signal.

This problem has been traced to silicon errata ERR003778:
"In AC97, 16-bit mode, received data is shifted by 4-bit locations" that
has "No fix scheduled".
This errata suggests a workaround of doing a 4-bit shift back in SDMA
script for this specific operation mode, however our SDMA scripts are
shared between various SoC peripherals so we can't really modify them.

There is a simple way to avoid this problem, however, that is to disallow
recording in 16-bit mode and only support it in AC'97-native 20-bit mode.
We have to use a 4-byte format for this since SSI FIFOs do not allow 3-byte
accesses (and these aren't supported by imx-sdma driver anyway).
With this change the capture distortion is gone.

We can also add this format as an additional one supported for playback,
using this opportunity to make sure that we use CPU-endian-native formats
in AC'97 mode as we already do in I2S mode.

There is no problem in using different bit widths in playback and capture
in AC'97 mode so allow this, too.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NMark Brown <broonie@kernel.org>

We need to make sure that only proper channel slots (in SACCST register)
are enabled at playback start time since some AC'97 CODECs (like VT1613 on
UDOO board) were observed requesting via SLOTREQ spurious ones just after
an AC'97 link is started but before the CODEC is configured by its driver.
When a bit for some channel slot is set in a SLOTREQ request then SSI sets
the relevant bit in SACCST automatically, which then 'sticks' until it is
manually unset.
The SACCST register is not writable directly, we have to use SACCDIS and
SACCEN registers to configure it instead (these aren't normal registers:
writing a '1' bit at some position in SACCEN sets the relevant bit in
SACCST; SACCDIS operates in a similar way but allows unsetting bits in
SACCST).

Theoretically, this should be necessary only for the very first playback
but since some CODECs are so untrustworthy and extra channel slots enabled
mean ruined playback let's play safe here and make sure that no extra
slots are enabled in SACCST every time a playback is started.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In AC'97 mode we configure and start SSI RX / TX on probe path via
a call to _fsl_ssi_set_dai_fmt() function.
We don't need to call this function again later and in fact don't want to
do it since this function temporarily sets STCR, SRCR and SCR to some
intermediate values.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We don't need to set CCSR_SSI_SIER_RFF0_EN / CCSR_SSI_SIER_TFE0_EN bits
in reg->rx.sier / reg->tx.sier variables in a non-AC'97 mode considering we
had just initialized these variables to these very values unconditionally a
few lines earlier.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

AC'97 register access operations (both read and write) on SSI use a one,
shared set of SSI registers for AC'97 register address and data.
This means that only one such access is possible at a time and so all these
operations need to be serialized.

Since an AC'97 register access operation in this driver takes 100us+ let's
use a mutex for this.

Use this opportunity to also change a default value returned from AC'97
register read function from -1 to 0, since that's what AC'97 specs require
to be returned when unknown / undefined registers are read.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: NMark Brown <broonie@kernel.org>

AC'97 ops (register read / write) need SSI regmap and clock, so they have
to be set after them.

We also need to set these ops back to NULL if we fail the probe.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Symbol SND_SOC_INTEL_SST_TOPLEVEL is user selectable so add the
help text for this symbol.
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

DSP modes and left/right justified modes can be supported
on bcm2835 by configuring the frame sync polarity and
frame sync length registers and by adjusting the
channel data position registers.

Clock and frame sync polarity handling in hw_params has
been refactored to make the interaction between logical
rising/falling edge frame start and physical configuration
(changed by normal/inverted polarity modes) clearer.

Modes where the first active data bit is transmitted immediately
after frame start (eg DSP mode B with slot 0 active)
only work reliable if bcm2835 is configured as frame master.
In frame slave mode channel swap (or shift, this isn't quite
clear yet) can occur.

Currently the driver only warns if an unstable configuration
is detected but doensn't prevent using them.
Signed-off-by: NMatthias Reichl <hias@horus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

bcm2835's configuration registers can't be changed when a stream
is running, which means asymmetric configurations aren't supported.

Channel and rate symmetry are already enforced by constraints
but samplebits had been missed.

As hw_params doesn't check for symmetry constraints by itself
and just returns success if a stream is running this led to
situations where asymmetric configurations were seeming to
succeed but of course didn't work because the hardware wasn't
configured at all.

Fix this by adding the missing samplerate symmetry constraint.
Signed-off-by: NMatthias Reichl <hias@horus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Sample rates are only restricted by the capabilities of the
clock driver, so use SNDRV_PCM_RATE_CONTINUOUS instead of
SNDRV_PCM_RATE_8000_192000.

Tests (eg with pcm5122) have shown that bcm2835 works fine
in 384kHz/32bit stereo mode, so change the maximum allowed
rate from 192kHz to 384kHz.
Signed-off-by: NMatthias Reichl <hias@horus.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NMark Brown <broonie@kernel.org>

bcm2835 supports arbitrary positioning of channel data within
a frame and thus is capable of supporting TDM modes. Since
the driver is limited to 2-channel operations only TDM setups
with exactly 2 active slots are supported.

Logical TDM slot numbering follows the usual convention:

For I2S-like modes, with a 50% duty-cycle frame clock,
slots 0, 2, ... are transmitted in the first half of a frame,
slots 1, 3, ... are transmitted in the second half.

For DSP modes slot numbering is ascending: 0, 1, 2, 3, ...

Channel position calculation has been refactored to use
TDM info and moved out of hw_params.

set_tdm_slot, set_bclk_ratio and hw_params now check more
strictly if the configuration is valid. Illegal configurations
like odd number of slots in I2S mode, data lengths exceeding
slot width or frame sizes larger than the hardware limit of
1024 are rejected. Also hw_params now properly checks for
errors from clk_set_rate.

Allowed PCM formats are already guarded by stream constraints,
thus the formats check in hw_params has been removed and
data_length is now retrieved via params_width().

Also standard functions like snd_soc_params_to_bclk are now
being used instead of manual calculations to make the code
more readable.

Special care has been taken to ensure that set_bclk_ratio works
as before. The bclk ratio is mapped to a 2-channel TDM config
with a slot width of half the ratio. In order to support odd ratios,
which can't be expressed via a TDM config, the ratio (frame length)
is stored and used by hw_params.
Signed-off-by: NMatthias Reichl <hias@horus.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add mclk-fs support to audio graph card
as it was previously implemented in simple card.
Signed-off-by: NOlivier Moysan <olivier.moysan@st.com>
Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The main rt5514 driver optionally calls into the SPI back-end to load
the firmware. This causes a link error when one driver selects rt5514
as built-in and another driver selects rt5514-spi as a loadable module:

sound/soc/codecs/rt5514.o: In function `rt5514_dsp_voice_wake_up_put':
rt5514.c:(.text+0xac8): undefined reference to `rt5514_spi_burst_write'

As a workaround, this adds another silent symbol, to force rt5514-spi
to be built-in for that configuration. I'm not overly happy with
that solution, but couldn't come up with anything better. Using
'IS_REACHABLE()' would break the case that relies on the loadable
module, and all other ideas would result in more complexity.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The new functions are only used when CONFIG_PM is enabled,
leading to a harmless warning:

sound/soc/codecs/rt5514-spi.c:474:12: error: 'rt5514_resume' defined but not used [-Werror=unused-function]
sound/soc/codecs/rt5514-spi.c:464:12: error: 'rt5514_suspend' defined but not used [-Werror=unused-function]

This marks them as __maybe_unused to make the build silent
again.

Fixes: 58f1c07d ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Check the JD status in the button pushing to prevent the IRQ that is locked
by button pushing event while the jack unpluging.
Signed-off-by: NOder Chiou <oder_chiou@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Before rendering starts, DMA driver copies full buffer valid data
to ACP SRAM for the first time, after that ACP SRAM to I2S
FIFO DMA will be initiated. After rendering first half of ACP SRAM,
IOC will be raised then Audio data will be copied from first half of
System Memory to first half of ACP SRAM. Similarly after rendering
second half of ACP SRAM, IOC will be raised then Audio Data will be
copied from second half of the System Memory to second half of the
ACP SRAM in ping-pong way till rendering stops.

Old design introducing latency issues resulting stutter sound observed
during playback.
Signed-off-by: NVijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: NAkshu Agrawal <Akshu.Agrawal@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait that long
before reading the value.

TEST=Cold boot the device and check for sound device.
Signed-off-by: NAkshu Agrawal <akshu.agrawal@amd.com>
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

32bit and 24bit audio capture formats for H3/H2+ are broken because the
RX_SAMPLE_BITS and the RX_FIFO_MODE bits of AC_ADC_FIFOC register of the audio
codec are not set to operate in 24bit mode but in 16bit mode only.
The following patch sets the H3 audio codec registers and the DMA bus width
properly when a 24/32bit capture is requested.
Signed-off-by: NAndrea Bondavalli <andrea.bondavalli74@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

DSP modes are documented in the data sheet but not enabled in the driver.
The work-around already implemented for DA7218/9 is also required to
make sure the bit clock handling in DSP modes follows ASoC conventions.

Tested with ARD-AUDIO-DA7212 and Minnowmax Turbot boards
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: NAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The current code might be a bit intriguing without having experienced the
issue before, and might come up as a mistake.

Make explicit what's going on by adding a comment.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

While the current code was reporting to be able to work in master mode, it
failed to do so because the BCLK divider wasn't programmed, meaning that
the BCLK would run at the PLL's frequency no matter the sample rate.

It was obviously a bit too fast.

Add support to retrieve the divider to use, and set it. Since our PLL is
not always able to generate a perfect multiple of the sample rate, we'll
have to choose the closest divider that matches our setup.

Fixes: 36c68493 ("ASoC: Add sun8i digital audio codec")
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

In the probe, the codec may not be ready for I2C reading or there are some
glitches on the i2c line. So if the i2c reading value is incorrect, it will
read again after delay. This issue is similar the patch
https://patchwork.kernel.org/patch/9681421/. In current project, these 2
devices were connected to the same i2c line, and they met the same problem.
Signed-off-by: NOder Chiou <oder_chiou@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

[Reword the commit message to make it clearer - Alex]

fixes: 61add814 (ASoC: amd: Report accurate hw_ptr during dma)
Signed-off-by: NGuenter Roeck <groeck@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678919Reviewed-by: NJason Clinton <jclinton@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/681618Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

For wake on voice use case, we need to copy data from DSP buffer
to PCM stream when system wakes up by voice. However the edge
triggered IRQ could be missed when system wakes up, in that case
the irq function will not be called. If the substream was constructed
beforce suspend, we will schedule data copy in resume function.
Signed-off-by: NOder Chiou <oder_chiou@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

If the rt5514 Wake on Voice device is opened while suspended, it will
be able to wake up the system when a voice command is detected.
This patch also supports user-space policy to override wakeup behavior
by /sys/bus/spi/drivers/rt5514/spi2.0/power/wakeup.
Signed-off-by: NChinyue Chen <chinyue@chromium.org>
Signed-off-by: NOder Chiou <oder_chiou@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 402005
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 115168
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 146568
Addresses-Coverity-ID: 146569
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 115164
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1195220
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 146566
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1397957
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Current codec drivers are using snd_soc_read(). It will be replaced
into snd_soc_component_read(), but these 2 are using different style.
For example, it will be

	- val = snd_soc_read(xxx, reg);
	+ ret = snd_soc_component_read(xxx, reg, &val);
	+ if (ret < 0) {
	+	...
	+ }

To more smooth replace, let's add snd_soc_component_read32
which is copied from snd_soc_read()

	- val = snd_soc_read(xxx, reg);
	+ val = snd_soc_component_read32(xxx, reg);
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

During failure, widgets in cvt_list and pin_list are not freed. So fix
the possible memory leak by freeing them when failure occurs.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com>
Acked-By: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Pointers hdac_hdmi_pcm and hda_device_id can be NULL, so add check for
valid pointer to avoid NULL pointer dereference.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com>
Acked-By: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use snprintf instead of sprintf to shut the warning.
Signed-off-by: NSubhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com>
Acked-By: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Module id is a property of firmware manifest and can vary between
platforms so use the uuid instead of module id for pins.
Signed-off-by: NSriram Periyasamy <sriramx.periyasamy@intel.com>
Signed-off-by: NGuneshwor Singh <guneshwor.o.singh@intel.com>
Acked-By: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>