Make sure userspace can define TLV controls for topology using the correct
type numbers and channel mappings.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The topology core parses the FW topology file for known block types and
instanciates any common ALSA/ASoC objects that it discovers. The core
also passes any block that is does not understand to client component
drivers for enumeration.
The core exports some APIs to client drivers in order to load and unload
firmware topology data as use case require.
Currently the core deals with the following object types :-
o kcontrols. This includes TLV, enumerated and bytes controls.
o DAPM widgets. All types with any associated kcontrol.
o DAPM graph.
o FE PCM. FE PCM capabilities and configuration can be defined.
o BE DAI Link. BE DAI link capabilities and configuration can be defined.
o Codec <-> codec style links capabilities and configuration.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The ASoC topology UAPI header defines the structures
required to define any DSP firmware audio topology and control objects from
userspace.
The following objects are supported :-
o kcontrols including TLV controls.
o DAPM widgets and graph elements
o Vendor bespoke objects.
o Coefficient data
o FE PCM capabilities and config.
o BE link capabilities and config.
o Codec <-> codec link capabilities and config.
o Topology object manifest.
The file format is simple and divided into blocks for each object type and
each block has a header that defines it's size and type. Blocks can be in
any order of type and can either all be in a single file or spread across
more than one file. Blocks also have a group identifier ID so that they can
be loaded and unloaded by ID.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DPCM is caring only FE format. but it will be no sound
if FE/BE was below style, and user selects S24_LE format.
FE: S16_LE/S24_LE
BE: S16_LE
DPCM can rewrite the format, so basically we don't want to
constrain with the BE constraints. But sometimes it will be trouble.
This patch adds new .dpcm_merged_format on struct snd_soc_dai_link.
DPCM will use FE / BE merged format if .struct snd_soc_dai_link
has it. We can have other .dpcm_merged_xxx in the future
.dpcm_merged_foramt
.dpcm_merged_rate
.dpcm_merged_chan
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Keita Kobayashi <keita.kobayashi.ym@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some CODECs have a significant number of DAPM routes and for each route,
when it is added to the card, the entire card widget list must be
searched. When adding routes it is very likely, however, that adjacent
routes will require adjacent widgets. For example all the routes for a
mux are likely added in a block and the sink widget will be the same
each time and it is also quite likely that the source widgets are
sequential located in the widget list.
This patch adds a cache to the DAPM context, this cache will hold the
source and sink widgets from the last call to snd_soc_dapm_add_route for
that context. A small search of the widget list will be made from those
points for both the sink and source. Currently this search only checks
both the last widget and the one adjacent to it.
On wm8280 which has approximately 500 widgets and 30000 routes (one of
the largest CODECs in mainline), the number of paths that hit the cache
is 24000, which significantly improves probe time.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We can know if dmic is used by reading the value of dmic1_data_pin
and dmic2_data_pin. Also IRQ must be used if codec JD or button
detection function is used. So, dmic_en and en_jd_func can be remove
from platform data.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A demux is conceptually similar to a mux. Where a mux has multiple input
and one output and selects one of the inputs to be connected to the output,
the demux has one input and multiple outputs and selects one of the outputs
to which the input gets connected.
This similarity makes it straight forward to support them in DAPM using the
existing mux support, we only need to swap sinks and sources when initially
setting up the paths.
The only slightly tricky part is that there can only be one control per
path. Since mixers/muxes are at the sink of a path and a demux is at the
source and both types want a control it is not possible to directly connect
a demux output to a mixer/mux input. The patch adds some sanity checks to
make sure that this does not happen.
Drivers who want to model hardware which directly connects a demux output
to a mixer/mux input can do this by inserting a dummy widget between the
two. E.g.:
{ "Dummy", "Demux Control", "Demux" },
{ "Mixer", "Mixer Control", "Dummy" },
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 57295073b6 ("ASoC: dapm: Implement mixer input auto-disable")
added support for autodisable controls, controls whose values are only
written to the hardware when their respective widgets are powered up.
But it only added support for controls based on the mixer abstraction.
This patch add support for mux controls (DAPM controls based on the
enum abstraction) to be auto-disabled as well. As each mux can only have
a single control, there is no need to tie the autodisable widget to the
inputs (as is done for the mixer controls) it can be tided directly to
the mux widget itself.
Note that it is assumed that the first entry in a autodisable mux
control will always represent the off state for the mux and is what the
mux will be set to whilst it is disabled.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
xnitmes is clearly intended to be xnitems, but all other macros just
refer to this as xitems, so change it to that.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
A few fixes for v4.1, none earth shattering and mostly driver related
except for one change to fix !PM builds for Intel platforms which is
done by adding stubs in the core so other platforms don't run into the
same issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVQj3nAAoJECTWi3JdVIfQkxYH/R8MhnJl7eQbW88UBcIZiDI+
IeJ239r8AH6HJHA7BFOfG1gUYCmpLsY+1rssyrJXYiKBRNsQ/az7AV1iFx/He7Xg
+NS9wBmLyj4yMF0aHETg5j3qdba+bNJLmNe0hlydXnSk79twgBkTw1YPY2eQ+5xX
DMZaBk2SRnikb8R7vUgCjMfpB5HxcpPAo8z55FRJOAb4yYBERUx82GQ9aGqInQk1
5gbtwBPDQ4kZyJitBA5o9qRV0jcXx75iC/vM4nvwi2Vjp/tLsYlhuk0RuwH1SnJ/
lzjBau7kYo97wxTf4Z903EijkgwYuk9FhRusxNr/FaBZB7pDBAxjzwVWoxJUV3U=
=INCv
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v4.1
A few fixes for v4.1, none earth shattering and mostly driver related
except for one change to fix !PM builds for Intel platforms which is
done by adding stubs in the core so other platforms don't run into the
same issue.
Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two
modes for DMA. Second mode is useful for 64 bit os with more then 2 GB
of ram (fixes problems with big soundfont loading)
1) 32MB from 2 GB address space using 8192 pages (used now as default)
2) 16MB from 4 GB address space using 4096 pages
Mode is set using HCFG_EXPANDED_MEM flag in HCFG register.
Also format of emu10k2 page table is then different.
Signed-off-by: Peter Zubaj <pzubaj@marticonet.sk>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
rajeev-dlh.kumar@st.com email-id doesn't exist anymore as I have left the
company. Replace ST's id with Rajeev Kumar <rajeevkumar.linux@gmail.com>
Signed-off-by: Rajeev Kumar <rajeevkumar.linux@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently drivers are responsible for managing the bias_level field of
their DAPM context. The DAPM state itself is managed by the DAPM core
though and the core has certain expectations on how and when the bias_level
field should be updated. If drivers don't adhere to these undefined
behavior can occur.
This patch adds a few helper functions for manipulating the DAPM context
state, each function with a description on when it should be used and what
its effects are. This will also help us to move more of the bias_level
management from drivers to the DAPM core.
For convenience also add snd_soc_codec_* wrappers around these helpers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The DAPM context in the snd_soc_codec struct is redundant and scheduled to
be replaced by the DAPM context in the snd_soc_component struct. This patch
introduces a new helper function snd_soc_codec_get_dapm() which should be
used for getting the DAPM context for a CODEC rather then directly
accessing the dapm field. Once there are no more direct users of the dapm
field left it is possible to transparently switch all drivers to the
component DAPM context by updating snd_soc_codec_get_dapm() function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current struct snd_soc_dai_link has many members, but definition order
was random. Especially, bool / bit field are defined randomly.
This patch tidyups these definition order to calculate data alignment
easy.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Whether residue can be reported or not is not a property of the audio
controller but of the DMA controller. The FLAG_NO_RESIDUE was initially
added when the DMAengine framework had no support for describing the residue
reporting capabilities of the controller. Support for this was added quite a
while ago and recently the DMAengine framework started to complain if a
driver does not describe its capabilities and a lot of patches have been
merged that add support for this where it was missing. So it should be safe
to assume that driver on actively used platforms properly implement the DMA
capabilities API.
This patch makes the FLAG_NO_RESIDUE internal and no longer allows audio
controller drivers to manually set the flag. If a DMA driver against
expectations does not support reporting its capabilities for now the generic
DMAengine PCM driver will now emit a warning and simply assume that residue
reporting is not supported. In the future this might be changed to aborting
with an error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
When CONFIG_PM_SLEEP is not selected, calling funcs
snd_soc_suspend and _resume will generate a compiling
issue.
Here add static inline stub functions to fix it.
Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
More updates for v4.1, pretty much all drivers:
- Lots of cleanups from Lars, mainly moving things from the CODEC level
to the card level.
- Continuing improvements to rcar from Morimoto-san, pcm512x from
Howard and Peter, the Intel platforms from Vinod, Jie, Jin and Han,
and to rt5670 from Bard.
- Support for some non-DSP Qualcomm platforms, Google's Storm
platform, Maxmim MAX98925 CODECs and the Ingenic JZ4780 SoC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVK7E7AAoJECTWi3JdVIfQeRwH+wZHxh5yXBwSysga6ITc8GzZ
Swy9LCdVr4uDXBrzn6qusfpgyiy6i09aB3tlr02j1gnhaA6tZ52Xi5S5RGds2nQL
Qi+Nmt/7Expys09mJrE1Z8ZBRXnSbKw36odNxHiVVPVSfBGEXeQErDmLzsQ3ccqA
8HDC2TGRjjal9ZVW9kNsi5EkR9z8dRlkymAvzlpozs4aLwaOsH/xiF+4xI3zh0xZ
+rG8HH9w3/yePVKiKZGjToNgzZ2ATLB5s+JZyFiDn0uXMo3UZWnQItPv8KJE0/FR
A7D7XyMN66WSTnWHMIPetrJbgyNP9cM/Wk+prn/PKvObsqYiP7lJikzEAlklfJE=
=LjN/
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v4.1
More updates for v4.1, pretty much all drivers:
- Lots of cleanups from Lars, mainly moving things from the CODEC level
to the card level.
- Continuing improvements to rcar from Morimoto-san, pcm512x from
Howard and Peter, the Intel platforms from Vinod, Jie, Jin and Han,
and to rt5670 from Bard.
- Support for some non-DSP Qualcomm platforms, Google's Storm
platform, Maxmim MAX98925 CODECs and the Ingenic JZ4780 SoC.
Although some races in runtime PM refcount was fixed by the commit
[664c715573c2: ALSA: hda - Work around races of power up/down with
runtime PM], there is still a race in the following case:
CPU0: CPU1 :
runtime suspend:
codec->in_pm = 1
snd_hdac_power_up_pm():
pm_runtime_get_sync() skipped
suspend finished:
codec->in_pm = 0
snd_hdac_power_down_pm():
pm_runtime_put_*() is called!
For avoiding this situation, increment in_pm flag atomically when it's
non-zero, and decrement accordingly, to ensure that in_pm is set
consistently for the whole concurrent operations.
Also, since atomic_inc_not_zero() and atomic_dec_if_positive() are
lengthy inline functions, move snd_hdac_power_up_pm() and _down_pm()
to sound/hda/hdac_device.c as no inline functions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Failing to register the debugfs entries is not fatal and will not affect
normal operation of the sound card. Don't abort the card registration if
soc_dpcm_debugfs_add() fails.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, snd_hdac_power_up()/down() helpers checks whether the codec
is being in pm (suspend/resume), and skips the call of runtime get/put
during it. This is needed as there are lots of power up/down
sequences called in the paths that are also used in the PM itself. An
example is found in hda_codec.c::codec_exec_verb(), where this can
power up the codec while it may be called again in its power up
sequence, too.
The above works in most cases, but sometimes we really want to wait
for the real power up. For example, the control element get/put may
want explicit power up so that the value change is assured to reach to
the hardware. Using the current snd_hdac_power_up(), however,
results in a race, e.g. when it's called during the runtime suspend is
being performed. In the worst case, as found in patch_ca0132.c, it
can even lead to the deadlock because the code assumes the power up
while it was skipped due to the check above.
For dealing with such cases, this patch makes snd_hdac_power_up() and
_down() to two variants: with and without in_pm flag check. The
version with pm flag check is named as snd_hdac_power_up_pm() while
the version without pm flag check is still kept as
snd_hdac_power_up(). (Just because the usage of the former is fewer.)
Then finally, the patch replaces each call potentially done in PM with
the new _pm() variant.
In theory, we can implement a unified version -- if we can distinguish
the current context whether it's in the pm path. But such an
implementation is cumbersome, so leave the code like this a bit messy
way for now...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96271
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far we assumed that the node attributes like amp values remain
during the power state transition of the node itself. While this is
true for IDT/STAC codecs I've tested, but some other codecs don't seem
behaving in that way.
This patch implements a partial sync mechanism specific to the given
widget node. Now we've merged the regmap support, and it can be
easily written with regcache_sync_region().
Tested-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The delayed_work field in the snd_soc_dapm_context struct is now unused and
can be removed. Removing it reduces the size of the snd_soc_dapm_context
struct by ~50% from 100 bytes to 48 bytes.
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>
The only two users of the suspend_bias_level field were two rather old
drivers which weren't exactly doing things by the book. Those drivers have
been updated and field is now unused and can be removed.
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>
Having to set different formats on the CPU side and the CODEC side of a DAI
link is usually indication that something is terribly wrong and in most
cases is a result of a broken driver that implements a set_fmt() callback
which does not follow the specification. In the past this feature has been
used to work around broken drivers, rather than fixing them. We don't really
want to encourage this, so remove support for setting different formats on
both ends of the link.
Along the way switch to static DAI format setup by setting the the dai_fmt
field of the snd_soc_dai_link rather than calling snd_soc_dai_fmt().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The 16bit COEF read/write is pretty standard for many codecs, and they
can be cached in most cases -- more importantly, they need to be
restored at resume. For making this easier, add the cache support to
regmap. If the codec driver wants to cache the COEF access, set
codec->cache_coef flag and issue AC_VERB_GET_PROC_COEF with the coef
index in LSB 8 bits.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HD-audio spec is inconvenient regarding the handling of stereo volume
controls. It can set and get only single channel at once (although
there is a special option to set the same value to both channels).
This patch provides a fake pseudo-register via the regmap access so
that the stereo channels can be read and written by a single call.
It'd be useful, for example, for implementing DAPM widgets.
A stereo amp pseudo register consists of the encoding like the normal
amp verbs but it has both SET_LEFT (bit 13) and SET_RIGHT (bit 12)
bits set. The regmap reads and writes a 16bit value for this pseudo
register where the upper 8bit is for the right chanel and the lower
8bit for the left channel.
Note that the driver doesn't recognize conflicts when both stereo and
mono channel registers are mixed. Mixing them would certainly confuse
the operation. So, use carefully.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Codecs may have own vendor-specific verbs, and we need to allow each
driver to give such verbs for cached accesses. Here a verb can be put
into a single array and looked through it at readable and writeable
callbacks.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The amp hash table was used for recording the cached reads of some
capability values like pin caps or amp caps. Now all these are moved
to regmap as well.
One addition to the regmap helper is codec->caps_overwriting flag.
This is set in snd_hdac_override_parm(), and the regmap helper accepts
any register while this flag is set, so that it can overwrite even the
read-only verb like AC_VERB_PARAMETERS. The flag is cleared
immediately in snd_hdac_override_parm(), as it's a once-off flag.
Along with these changes, the no longer needed amp hash and relevant
fields are removed from hda_codec struct now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sometimes we need the uncached reads, e.g. for refreshing the tree.
This patch provides the helper function for that and uses it for
refreshing widgets, reading subtrees and the whole proc reads.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Let's start converting the access functions to regmap.
The first one is the simplest, just converting the codec parameter
read helper function snd_hda_param_read().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds an infrastructure to support regmap-based verb
accesses. Because o the asymmetric nature of HD-audio verbs,
especially the amp verbs, we need to translate the verbs as a sort of
pseudo registers to be mapped uniquely in regmap.
In this patch, a pseudo register is built from the NID, the
AC_VERB_GET_* and 8bit parameters, i.e. almost in the form to be sent
to HD-audio bus but without codec address field. OTOH, for writing,
the same pseudo register is translated to AC_VERB_SET_* automatically.
The AC_VERB_SET_AMP_* verb is re-encoded from the corresponding
AC_VERB_GET_AMP_* verb and parameter at writing.
Some verbs has a single command for read but multiple for writes. A
write for such a verb is split automatically to multiple verbs.
The patch provides also a few handy helper functions. They are
designed to be accessible even without regmap. When no regmap is set
up (e.g. before the codec device instantiation), the direct hardware
access is used. Also, it tries to avoid the unnecessary power-up.
The power up/down sequence is performed only on demand.
The codec driver needs to call snd_hdac_regmap_exit() and
snd_hdac_regmap_exit() at probe and remove if it wants the regmap
access.
There is one flag added to hdac_device. When the flag lazy_cache is
set, regmap helper ignores a write for a suspended device and returns
as if it was actually written. It reduces the hardware access pretty
much, e.g. when adjusting the mixer volume while in idle. This
assumes that the driver will sync the cache later at resume properly,
so use it carefully.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add an overriding exec_verb op to struct hdac_device so that the call
via snd_hdac_exec_verb() can switch to a different route depending on
the setup. The codec driver sets this field so that it can handle the
errors or applying quirks appropriately. Furthermore, this mechanism
will be used for smooth transition for the regmap support in later
patches.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mark Brown