IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner. Also remove the manual sequencing back
to SND_SOC_BIAS_ON in resume as this is already handled by the ASoC core.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to its documentation the is_powered_on_standby field of the
uda134x platform data is supposed to prevent the the driver from shutting
down the ADC and DAC in standby mode. This behavior was broken in commit
commit f0fba2ad1b6b ("ASoC: multi-component - ASoC Multi-Component Support")
almost 5 years ago and all the flag does now is cause the driver to go to
SND_SOC_BIAS_ON in probe, just for the ASoC core to put it back into
SND_SOC_BIAS_STANDBY right after probe.
Apparently the intended behavior has not been missed, so just remove
is_powered_on_standby from the platform data struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is right not left sidetone which goes to "DACR".
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 5fe5b767dc6f ("ASoC: dapm: Do not pretend to support controls for non
mixer/mux widgets") revealed ill-defined control in a route between
"STENL Mux" and DACs in max98090.c:
max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACL
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACL
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACL
max98090 i2c-193C9890:00: Control not supported for path STENL Mux -> [NULL] -> DACR
max98090 i2c-193C9890:00: ASoC: no dapm match for STENL Mux --> NULL --> DACR
max98090 i2c-193C9890:00: ASoC: Failed to add route STENL Mux -> NULL -> DACR
Since there is no control between "STENL Mux" and DACs the control name must
be NULL not "NULL".
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Commit e409dfbfccf9 ("ASoC: dapm: Add a few supply widget sanity checks")
broke digital microphone support in max98090.c:
max98090 i2c-193C9890:00: Conditional paths are not supported for supply widgets (DMICL_ENA -> [DMIC] -> DMIC Mux)
max98090 i2c-193C9890:00: ASoC: no dapm match for DMICL_ENA --> DMIC --> DMIC Mux
max98090 i2c-193C9890:00: ASoC: Failed to add route DMICL_ENA -> DMIC -> DMIC Mux
max98090 i2c-193C9890:00: Conditional paths are not supported for supply widgets (DMICR_ENA -> [DMIC] -> DMIC Mux)
max98090 i2c-193C9890:00: ASoC: no dapm match for DMICR_ENA --> DMIC --> DMIC Mux
max98090 i2c-193C9890:00: ASoC: Failed to add route DMICR_ENA -> DMIC -> DMIC Mux
Problem is partially caused by commit f69e3caa9e18 ("ASoC: max98090: Enable
both DMIC channels also when using mono configuration") which connects
"DMICL_ENA" and "DMICR_ENA" supply widgets to "DMIC Mux".
Fix the breakage by reverting f69e3caa9e18 and then by adding additional
"DMICR_ENA" to "DMICL" and "DMICL_ENA" to "DMICR" cross-connections. This
disconnects these supply widgets from the mux and makes sure that both DMIC
data channels are still enabled together.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
sound/soc/intel/sst/sst_acpi.c:135:26: sparse: symbol 'chv_platform_data' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Skip dpcm path checking for playback or capture, if corresponding FE
doesn't support playback or capture, or currently is not ready. It
can reduce the unnecessary cost to search connected widgets.
[Tweaked comments for clarity -- broonie]
Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch add ACPI device ID and platform data for two Cherryview-based
platforms, Cherrytrail and Braswell. Also reuse mfld driver ops in sst driver.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add machine driver for two Intel Cherryview-based platforms, Cherrytrail and
Braswell, with RT5672 codec.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the device tree binding for the WM8960 codec, and modify the
driver to extract the platform data from device tree, if present.
Signed-off-by: Zidan Wang <b50113@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure to always convert the firmware data to local endianness before
using it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: a35daac77a03 ("ASoC: sigmadsp: Add support for fw v2")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
To be able to read back data from the DSP parameter memory the register
range needs to be marked as readable. At the same time we do not want them
to e.g. appear in debugfs output so mark them as precious as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The codec field of the snd_soc_widget struct is eventually going to be
removed, use snd_soc_dapm_to_codec(w->dapm) instead.
While we are at it also replace dev_get_drvdata() with snd_soc_codec_get_drvdata().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
In the i2s_set_sysclk() callback we are currently clearing all bits
of the IISMOD register in i2s_set_sysclk. It's due to an incorrect
mask used for the AND operation which is introduced in commit
a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung:
add support for exynos7 I2S controller) and also adds the missing
break statement.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
sound/soc/intel/sst/sst_acpi.c:124:26: sparse: symbol 'byt_rvp_platform_data' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The safeload feature allows to load up to 5 parameter memory registers
atomically. This is helpful for switching between e.g. filter settings
without causing any glitches.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for the v2 version of the SigmaDSP firmware file
format. The new format has support for having different program and
parameter settings for different samplerates. In addition it stores metadata
describing the firmware. This metadata includes the set of supported
samplerates which will be used to restrict the samplerates that can be
selected by userspace. Also included is information about the modifiable
parameters. Those will be exposed as ALSA controls so they can be changed at
runtime.
The new format is based on a binary type-length-value structure that makes
it both forward and backwards compatible.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The v2 file format of the SigmaDSP takes a more declarative style compared
to the imperative style of the v1 format. In addition some features that are
supported with v2 require the driver to keep state around for the firmware.
This requires a bit of restructuring of both the firmware loader itself and
the drivers making use of the firmware loader.
Instead of loading and executing the firmware in place when the DSP is
configured the firmware is now loaded at driver probe time. This is required
since the new firmware format will in addition to the firmware data itself
contain meta information describing the firmware and its requirements and
capabilities. Those will for example be used to restrict the supported
samplerates advertised by the driver to userspace to the list of samplerates
supported for the firmware.
This only does the restructuring required by the v2 format, but does not
yet add support for the new format itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The official firmware generation tool never emitted any SIGMA_ACTION_DELAY
instructions. Keeping support for it with the new restructured loader that
also supports v2 will be difficult, so drop support for it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure to check the version field of the firmware header to make sure to
not accidentally try to parse a firmware file with a different layout.
Trying to do so can result in loading invalid firmware code to the device.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For ACPI we missed to pm_runtime_enable() call which is required to tell PM
core that runtime on this device is enabled now. Since this is common to
both PCI and APCI move it out. Also for ACPI we do not require
pm_runtime_allow() call, so remove that
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the regmap conversion ac97_read/ac97_write are just simple wrappers
around snd_soc_read/snd_soc_write. Use those instead directly and remove the
wrappers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch converts the ad1980 driver to use regmap for its IO.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some drivers (most notably the AC'97 drivers) do not have access to their
regmap struct when the component/codec is registered. For those drivers the
automatic regmap setup will not work and needs to be done manually,
typically from the component/CODEC drivers probe callback.
This patch adds a set of helper function to handle deferred regmap
initialization as well as early regmap tear-down.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the slow charge of the vref in the end of the power sequences
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Follow the gpio naming rule to rename the irq function.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Many firmwares do not wait for the start bit before they begin
processing audio, whilst this is a bug on the firmware side there are
too many such firmwares in the wild to ignore the situation. This patch
moves the core enable to happen at same time as the start, the firmware
looses the ability to overlap its own startup with the audio path bring
up but we ensure that all firmwares behave.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: JS Park <aitdark.park@samsung.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
while building we were getting the following build warning:
Section mismatch in reference from the function rt286_i2c_probe()
to the variable .init.data:force_combo_jack_table
The function rt286_i2c_probe() references
the variable __initdata force_combo_jack_table.
This is often because rt286_i2c_probe lacks a __initdata
annotation or the annotation of force_combo_jack_table is wrong.
we were getting the warning as force_combo_jack_table was marked
with __initdata
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that the ASoC core no longer needs a handle to the AC'97 device that is
associated with a CODEC we can remove it from the snd_soc_codec struct and
push it into the individual driver state structs like we do for other
communication buses. Doing so creates a clean separation between the AC'97
bus support and the ASoC core.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Setting the ac97_control field on a CPU DAI tells the ASoC core that this
DAI in addition to audio data also transports control data to the CODEC.
This causes the core to suspend the DAI after the CODEC and resume it before
the CODEC so communication to the CODEC is still possible. This is not
necessarily something that is specific to AC'97 and can be used by other
buses with the same requirement. This patch renames the flag from
ac97_control to bus_control to make this explicit.
While we are at it also change the type from int to bool.
The following semantich patch was used for automatic conversion of the
drivers:
// <smpl>
@@
identifier drv;
@@
struct snd_soc_dai_driver drv = {
- .ac97_control
+ .bus_control
=
- 1
+ true
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is no longer necessary as there is no code anymore that uses this for
CODEC DAIs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We have all the information and dependencies we need to initialize and
register the device available in snd_soc_new_ac97_codec(). So there is no
need to delay the device registration until after the card itself as been
registered.
This makes the code significantly simpler and also makes it possible to use
the AC'97 device in the CODECs probe function. The later will be required to
be able to convert the AC'97 CODEC drivers to regmap.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
This has no users since commit f0fba2ad1b6b ("ASoC: multi-component - ASoC
Multi-Component Support") which was almost 5 years ago. Given that this runs
after CODEC probe functions have been run it also doesn't seem to be that
useful.
So drop it altogether to make the code simpler.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_{un,}register_ac97_codec() is just a simple wrapper around
soc_ac97_dev_{un,}register(). There is no need to split these up into two
different sets of functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
We always pass soc_ac97_ops to snd_soc_new_ac97_codec(). So instead of
allocating a snd_ac97_bus in snd_soc_new_ac97_codec() just use a static one
that gets initialized when snd_soc_set_ac97_ops() is called.
Also drop the device number parameter from snd_soc_new_ac97_codec(). We
currently only support one device per bus and all drivers pass 0 for the
device number. And if we should ever support multiple devices per bus it
wouldn't be up to individual AC'97 device drivers to pick their number, but
rather either the AC'97 adapter driver or the core code will assign them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the AC'97 support is splattered all throughout soc-core.c. Some
parts are #ifdef'd some parts are not. This patch moves the AC'97 support to
its own file, this should make the code a bit more clearer and also makes it
possible to easily not compile it into the kernel when not needed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The memory that a struct device is contained in must not be freed except
from within the device's release callback. The ASoC code currently does not
adhere to this rule for the AC'97 device. This patch fixes it by moving the
freeing of the AC'97 to the release callback and splitting up the
registration and unregistration of the device into separate steps for
getting/putting the reference to the device and adding/removing it to the
device hierarchy.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The mpc5200_dma overwrites the private_data field of the CODEC's AC'97
device with the DMA drivers private data, but never actually reads it again.
Given that the private_data field is supposed to be owned by the AC'97
driver, overwriting it may cause undefined behavior. This patch removes the
code that overwrites the field from the driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
