Shortens the variable name to save space, useful for dev_err outputs.
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>

This patches unifies the error message in the "failed to xxxx" format.

It also reduces the length of one line and adds spaces to an operator.
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>

This patch just simply unifies the coding style.
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>

This patch renames CCSR_SSI_xxx to REG_SSI_xxx and SSI_xxx_yyy style.
It also slightly reduces the length of them to save some space.
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>

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>

This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
allow 3-byte accesses (including DMA) so a 4-byte (more conventional)
format is needed for it.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

This commit adds PCI ID for Raven platform
Signed-off-by: NVijendar Mukunda <Vijendar.Mukunda@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It maybe the typo for ALC700 support patch.
To fix the bit value on this patch.

Fixes: 6fbae35a ("ALSA: hda/realtek - Add support for new codecs ALC700/ALC701/ALC703")
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The previous fix for addressing the breakage in vmaster slave
initialization, commit a91d6612 ("ALSA: hda - Fix incorrect TLV
callback check introduced during set_fs() removal"), introduced a new
helper to process over each slave kctl.  However, this helper passes
only the original kctl, not the virtual slave kctl.  As a result,
HD-audio driver (which is the only user so far) couldn't initialize
the slave correctly because it's trying to update the value directly
with the original kctl, not with the mapped kctl.

This patch fixes the situation again by passing both the mapped slaved
and original slave kctls to the function.  Luckily there is a single
caller as of now, so changing the call signature is no big matter.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197959
Fixes: a91d6612 ("ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With all callbacks converted, and the timer callback prototype
switched over, the TIMER_FUNC_TYPE cast is no longer needed,
so remove it. Conversion was done with the following scripts:

    perl -pi -e 's|\(TIMER_FUNC_TYPE\)||g' \
        $(git grep TIMER_FUNC_TYPE | cut -d: -f1 | sort -u)

    perl -pi -e 's|\(TIMER_DATA_TYPE\)||g' \
        $(git grep TIMER_DATA_TYPE | cut -d: -f1 | sort -u)

The now unused macros are also dropped from include/linux/timer.h.
Signed-off-by: NKees Cook <keescook@chromium.org>

The helper functions to parse and look for the clock source, selector
and multiplier unit may return the descriptor with a too short length
than required, while there is no sanity check in the caller side.
Add some sanity checks in the parsers, at least, to guarantee the
given descriptor size, for avoiding the potential crashes.

Fixes: 79f920fb ("ALSA: usb-audio: parse clock topology of UAC2 devices")
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

parse_audio_feature_unit() contains a code dividing potentially with
zero when a malformed FU descriptor is passed.  Although there is
already a sanity check, it checks only the value zero, hence it can
still lead to a zero-division when a value 1 is passed there.

Fix it by correcting the sanity check (and the error message
thereof).

Fixes: 23caaf19 ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The usb-audio driver may trigger an out-of-bound access at parsing a
malformed selector unit, as it checks the header length only after
evaluating bNrInPins field, which can be already above the given
length.  Fix it by adding the length check beforehand.

Fixes: 99fc8645 ("ALSA: usb-mixer: parse descriptors with structs")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the usb-audio descriptor contains the malformed feature unit
description with a too short length, the driver may access
out-of-bounds.  Add a sanity check of the header size at the beginning
of parse_audio_feature_unit().

Fixes: 23caaf19 ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some timer compat ioctls have NULL checks of timer instance with
snd_BUG_ON() that bring up WARN_ON() when the debug option is set.
Actually the condition can be met in the normal situation and it's
confusing and bad to spew kernel warnings with stack trace there.
Let's remove snd_BUG_ON() invocation and replace with the simple
checks.  Also, correct the error code to EBADFD to follow the native
ioctl error handling.
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

commit 3179f620 ("ALSA: core: add .get_time_info") had a side effect
of changing the behaviour of the PCM runtime tstamp.  Prior to this
change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
hw_ptr had moved, after this change tstamp was always updated.

For an application using alsa-lib, doing snd_pcm_readi() followed by
snd_pcm_status() to estimate the age of the read samples by subtracting
status->avail * [sample rate] from status->tstamp this change degraded
the accuracy of the estimate on devices where the pcm hw does not
provide a granular hw_ptr, e.g., devices using
soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
DMA_RESIDUE_GRANULARITY_DESCRIPTOR.  The accuracy of the estimate
depended on the latency between the PCM hw completing a period and the
driver called snd_pcm_period_elapsed() to notify ALSA core, typically
determined by interrupt handling latency.  After the change the accuracy
of the estimate depended on the latency between the PCM hw completing a
period and the application calling snd_pcm_status(), determined by the
scheduling of the application process.  The maximum error of the
estimate is one period length in both cases, but the error average and
variance is smaller when it depends on interrupt latency.

Instead of always updating tstamp, update it only if audio_tstamp
changed.

Fixes: 3179f620 ("ALSA: core: add .get_time_info")
Suggested-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NHenrik Eriksson <henrik.eriksson@axis.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Users have been using knob "model=dell-headset-multi" on Intel Skull
Canyon for a while.

Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
Canyon.

BugLink: https://bugs.launchpad.net/bugs/1732034Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We got a regression report about the HD-audio HDMI chmap, where some
surround channels are reported as UNKNOWN.  The git bisection pointed
the culprit at the commit 9b3dc8aa ("ALSA: hda - Register chmap
obj as priv data instead of codec").  The story behind scene is like
this:

- While moving the code out of the legacy HDA to the HDA common place,
  the patch modifies the code to obtain the chmap array indirectly in
  a byte array, and it expands it to kctl value array.
- At the latter operation, the size of the array is wrongly passed by
  sizeof() to the pointer.
- It can be 4 on 32bit arch, thus too short for 6+ channels.
  (And that's the reason why it didn't hit other persons; it's 8 on
  64bit arch, thus it's usually enough.)

The code was further changed meanwhile, but the problem persisted.
Let's fix it by correctly evaluating the array size.

Fixes: 9b3dc8aa ("ALSA: hda - Register chmap obj as priv data instead of codec")
Reported-by: NVDR User <user.vdr@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When an interrupt occurs, the value of at least one of the belonging
controls should have changed. To make sure they get re-read from device
on the next read, invalidate the cache. This was correctly implemented
for uac2 already, but missing for uac1.
Signed-off-by: NJulian Scheel <julian@jusst.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Sound works after a cold boot but not after a reboot from windows.
This patch will solve this issue. This is relation with Class-D power control.

[ The bug was reported in Bugzilla below for Sony VAIO SVS13A1C5E
  -- tiwai]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197737
Cc: <stable@vger.kernel.org>
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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>