Move gpio to gpio_desc and use gpiod APIs in codec driver.
Signed-off-by: NBard Liao <bardliao@realtek.com>
Signed-off-by: NOder Chiou <oder_chiou@realtek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Make sure userspace can define TLV controls for topology using the correct
type numbers and channel mappings.
Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark 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: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark 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: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark 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: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: NKeita Kobayashi <keita.kobayashi.ym@renesas.com>
Signed-off-by: NMark 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark 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: NBard Liao <bardliao@realtek.com>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Commit 57295073 ("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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NPeter Zubaj <pzubaj@marticonet.sk>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi 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: NRajeev Kumar <rajeevkumar.linux@gmail.com>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark 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: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark 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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark 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: NJie Yang <yang.jie@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Although some races in runtime PM refcount was fixed by the commit
[664c7155: 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: NTakashi 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark 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=96271Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use const to reduce data by ~3Kb.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTakashi 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: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi 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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMark 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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark 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: NTakashi 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: NTakashi 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: NTakashi 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: NTakashi 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: NTakashi 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: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

This will be used by the regmap support.
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

This patch changes the sysfs files assigned to the codec device on the
bus which were formerly identical with hwdep sysfs files.  Now it
shows only a few core parameter, vendor_id, subsystem_id, revision_id,
afg, mfg, vendor_name and chip_name.

In addition, now a widget tree is added to the bus device sysfs
directory for showing the widget topology and attributes.  It's just a
flat tree consisting of subdirectories named as the widget NID
including various attributes like widget capability bits.  The AFG
(usually NID 0x01) is always found there, and it contains always
amp_in_caps, amp_out_caps and power_caps files.  Each of these
attributes show a single value.  The rest are the widget nodes
belonging to that AFG.  Note that the child node might not start from
0x02 but from another value like 0x0a.

Each child node may contain caps, pin_caps, amp_in_caps, amp_out_caps,
power_caps and connections files.  The caps (representing the widget
capability bits) always contain a value.  The rest may contain
value(s) if the attribute exists on the node.  Only connections file
show multiple values while other attributes have zero or one single
value.

An example of ls -R output is like below:
% ls -R /sys/bus/hdaudio/devices/hdaudioC0D0/
/sys/bus/hdaudio/devices/hdaudioC0D0/widgets/:
01/  04/  07/  0a/  0d/  10/  13/  16/  19/  1c/  1f/  22/
02/  05/  08/  0b/  0e/  11/  14/  17/  1a/  1d/  20/  23/
03/  06/  09/  0c/  0f/  12/  15/  18/  1b/  1e/  21/

/sys/bus/hdaudio/devices/hdaudioC0D0/widgets/01:
amp_in_caps  amp_out_caps  power_caps

/sys/bus/hdaudio/devices/hdaudioC0D0/widgets/02:
amp_in_caps  amp_out_caps  caps  connections  pin_caps  pin_cfg
power_caps

/sys/bus/hdaudio/devices/hdaudioC0D0/widgets/03:
.....
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now some codes and functionalities of hda_codec struct are moved to
hdac_device struct.  A few basic attributes like the codec address,
vendor ID number, FG numbers, etc are moved to hdac_device, and they
are accessed like codec->core.addr.  The basic verb exec functions are
moved, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A few basic codes for communicating over HD-audio bus are moved to
struct hdac_bus now.  It has only command and get_response ops in
addition to the unsolicited event handling.

Note that the codec-side tracing support is disabled temporarily
during this transition due to the code shuffling.  It will be
re-enabled later once when all pieces are settled down.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Define the common hd-audio driver and device types to bind over
snd_hda_bus_type publicly.  This allows to implement other type of
device and driver code over hd-audio bus.

Now both struct hda_codec and struct hda_codec_driver inherit these
new struct hdac_device and struct hdac_driver, respectively.

The bus registration is done in subsys_initcall() to assure it
before any other driver registrations.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

dai-link params for codec-codec links were fixed. The fixed
link between codec and another chip which may be another codec,
baseband, bluetooth codec etc may require run time configuaration
changes. This change provides an optional alsa control to select
one of the params from a list of params.
Signed-off-by: NNikesh Oswal <nikesh@opensource.wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@kernel.org>