Merge branch 'for-linus' into for-next

ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec

AD1984A codec has a couple of pins with EAPD controls, and the generic
codec driver tries to turn each of them on/off depending on the pin
active state.  However, Thinkpads seem to use EAPD of the speaker pin
as a master EAPD for controlling the mute of all outputs, including
the headphone.  This results in the dead headphone output via the
headphone plugging because it mutes the speaker and turns off EAPD.

The fix is to simply add spec->gen.keep_on_eapd flag.

[This is a regression fix on 3.12 where we moved the AD codec parser
 to the generic parser.  3.11 and earlier didn't show this problem
 because still static quirks have been used.]

Reported-and-tested-by: Vito Caputo <vcaputo@gnugeneration.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Add missing initial vmaster hook at build_controls callback

The generic parser has a support of vmaster hook, but this is
initialized only in the init callback with the check of the presence
of the corresponding kctl.  However, since kctl is NULL at the very
first init callback that is called before build_controls callback, the
vmaster hook sync is skipped there.  Eventually this leads to the
uninitialized state depending on the hook implementation.

This patch adds a simple workaround, just calling the sync function
explicitly at build_controls callback.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-v3.13' of git://git./linux/kernel/git/broonie/sound into for-next

ASoC: Updates for v3.13

 - Further work on the dmaengine helpers, including support for
   configuring the parameters for DMA by reading the capabilities of the
   DMA controller which removes some guesswork and magic numbers fromm
   drivers.
 - A refresh of the documentation.
 - Conversions of many drivers to direct regmap API usage in order to
   allow the ASoC level register I/O code to be removed, this will
   hopefully be completed by v3.14.
 - Support for using async register I/O in DAPM, reducing the time taken
   to implement power transitions on systems that support it.

ALSA: hda - hdmi: Re-setup pin and infoframe on plug-in on all codecs

hdmi_setup_audio_infoframe() does not set up pin and infoframe if there
is no connected sink. If a sink is connected while audio playback is
already in progress, the pin and infoframe will not be properly set up,
causing no audio or wrongly mapped audio.

On Intel Haswell codecs the hdmi_setup_audio_infoframe() is already
called again from hdmi_present_sense() when an ELD appears because
transcoder:port mapping may have changed.

Make the call non-Haswell-specific so that audio will be properly set up
if the playback was started before a sink was connected.

Tested on non-Haswell Intel HDMI codec by plugging sink in during
playback.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs

Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by
procfs codec#0) have a configurable ramp-up/down functionality.

The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf )
specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for
non-PCM.

Apply the recommended values according to provided S/PDIF AES0 settings
since ramp-up/down does not make sense for non-PCM.

v2: adapted to hdmi_ops infrastructure

* More note from Anssi:
actually, re-reading mails reveals that Olivier didn't find the
expected difference with this setting, except for "maybe slightly
slower startup with AES0=6" (i.e. value 0, which is unexpected).

So maybe
a) it makes too unnoticiable a difference, or
b) only affects certain hardware (card and/or sink), or
c) ramp-up/down is only triggered with the MUTE bit of
   ATI_VERB_SET_MULTICHANNEL_xx which is also rev3+ specific,
   but is not presently used by the driver,
or something else.

So there's a significant chance setting ramp rate is useless for us ATM,
but probably does not do actual harm either.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Olivier Langlois <olivier@trillion01.com> # v1
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs

ATI/AMD HDMI codecs do not include standard HDA HDMI HBR support (which
is required for bitstreaming DTS-HD and Dolby TrueHD), instead they have
custom verbs for checking and enabling it.

Add support for the ATI/AMD HDMI HBR verbs.

The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

v2: adapted to hdmi_ops infrastructure

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v1
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs

ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data)
support.

In place of providing access to an ELD buffer, various vendor-specific
verbs are provided to provide the relevant information. Revision ID 3
and later (0x100300 as reported by procfs codec#X) have support for
providing more information than the previous revisions (but only if
supported by the display driver).

Generate ELD from the information provided by the vendor-specific verbs
on ATI/AMD codecs.

The specification is available at:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

v2: moved code to hda_eld.c and cleaned it up
v3: adapted to hdmi_ops infrastructure

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support

ATI/AMD codecs do not support all the standard HDA HDMI/DP functions,
instead various vendor-specific verbs are provided.

This commit addresses these missing functions:
- standard channel mapping support
- standard infoframe configuration support

ATI/AMD provides their own verbs that allow the following:
- setting CA for infoframe
- setting down-mix information for infoframe
- channel pair remapping
- individual channel remapping (revision ID 3+, 0x100300+)

The documentation for the verbs has now been released by AMD:
http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf

Add support for the ATI/AMD specific verbs and use them instead of the
generic methods on ATI/AMD codecs. This allows multi-channel PCM audio
to work.

Channel remapping is restricted to pairwise mapping on codecs with
revision ID 2 (0x100200 as reported by procfs codec#X) or lower. This
means cards up to Radeon HD7670 as far as I know. This will not affect
standard multi-channel modes since these codecs support automatic
FC-LFE swapping for HDMI.

ATI/AMD codecs do not advertise all of their supported rates, formats
and channel counts, therefore that information is forced accordingly so
that all HDMI 1.x PCM parameters are marked as supported.

Support for multiple ports is also added to patch_atihdmi so that
0x1002aa01 codecs with multiple ports will work properly when switched
back to that patch.

v2: splitted ELD emulation to a separate patch, tlv fixes
v3: adapted to the new hdmi_ops infrastructure, fixed rev3+ vendor id

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2
Tested-by: Olivier Langlois <olivier@trillion01.com> # v2+rev3fix
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - hdmi: Allow HDA patches to customize more operations

Upcoming AMD multichannel support requires many customized operations
(channel mapping, ELD, HBR) but can otherwise share most of its code
with the generic patch.

Add a local struct hdmi_ops containing customizable HDMI-specific
callbacks and move the current code to those callbacks. Functionality is
unaltered.

Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda/realtek - Raise the delay for alc283_shutup

Some machine with 85ms delay might be happen pop noise when codec
enter to D3.  Raise up to 100ms delay will be match for more machine.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: compress: fix drain calls blocking other compress functions

The drain and drain_notify callback were blocked by low level driver untill the
draining was complete. Due to this being invoked with big fat mutex held, others
ops like reading timestamp, calling pause, drop were blocked.

So to fix this we add a new snd_compr_drain_notify() API. This would be required
to be invoked by low level driver when drain or partial drain has been completed
by the DSP. Thus we make the drain and partial_drain callback as non blocking
and driver returns immediately after notifying DSP.
The waiting is done while relasing the lock so that other ops can go ahead.

Signed-off-by: Vinod Koul <vinod.koul@intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: Add ifdef CONFIG_GENERIC_ALLOCATOR for SNDRV_DMA_TYPE_IRAM code

It turned out that we can't use gen_pool_*() functions on archs
without CONFIG_GENERIC_ALLOCATOR (resulting in missing symbols), since
linux/genalloc.h doesn't provide dummy functions for all.  We'd be
able to fix linux/genalloc.h size, but I take an easier path for
now...

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge remote-tracking branch 'asoc/topic/wm8962' into asoc-next

Merge remote-tracking branch 'asoc/topic/wm8400' into asoc-next

Merge remote-tracking branch 'asoc/topic/twl6040' into asoc-next

Merge remote-tracking branch 'asoc/topic/twl4030' into asoc-next

Merge remote-tracking branch 'asoc/topic/tpa6130a2' into asoc-next

Merge remote-tracking branch 'asoc/topic/tlv320aic3x' into asoc-next

Merge remote-tracking branch 'asoc/topic/tlv320aic32x4' into asoc-next

Merge remote-tracking branch 'asoc/topic/tlv320aic26' into asoc-next

Merge remote-tracking branch 'asoc/topic/tlv320aic23' into asoc-next

Merge remote-tracking branch 'asoc/topic/tegra' into asoc-next

Merge remote-tracking branch 'asoc/topic/tas5086' into asoc-next

Merge remote-tracking branch 'asoc/topic/spear' into asoc-next

Merge remote-tracking branch 'asoc/topic/sn95031' into asoc-next

Merge remote-tracking branch 'asoc/topic/simple' into asoc-next

Merge remote-tracking branch 'asoc/topic/si476x' into asoc-next

Merge remote-tracking branch 'asoc/topic/samsung' into asoc-next

Merge remote-tracking branch 'asoc/topic/rt5640' into asoc-next

Merge remote-tracking branch 'asoc/topic/rcar' into asoc-next

Merge remote-tracking branch 'asoc/topic/pxa' into asoc-next

Merge remote-tracking branch 'asoc/topic/pcm1792a' into asoc-next

Merge remote-tracking branch 'asoc/topic/pcm1681' into asoc-next

Merge remote-tracking branch 'asoc/topic/mxs' into asoc-next

Merge remote-tracking branch 'asoc/topic/mc13783' into asoc-next

Merge remote-tracking branch 'asoc/topic/max9850' into asoc-next

Merge remote-tracking branch 'asoc/topic/max98095' into asoc-next

Merge remote-tracking branch 'asoc/topic/max98088' into asoc-next

Merge remote-tracking branch 'asoc/topic/kirkwood' into asoc-next

Merge remote-tracking branch 'asoc/topic/fsl' into asoc-next

Merge remote-tracking branch 'asoc/topic/ep93xx' into asoc-next

Merge remote-tracking branch 'asoc/topic/doc' into asoc-next

Merge remote-tracking branch 'asoc/topic/dma' into asoc-next

Merge remote-tracking branch 'asoc/topic/devm' into asoc-next

Merge remote-tracking branch 'asoc/topic/davinci' into asoc-next

Merge remote-tracking branch 'asoc/topic/dapm' into asoc-next

Merge remote-tracking branch 'asoc/topic/cs42l73' into asoc-next

Merge remote-tracking branch 'asoc/topic/cs4271' into asoc-next

Merge remote-tracking branch 'asoc/topic/cq93vc' into asoc-next

Merge remote-tracking branch 'asoc/topic/core' into asoc-next

Merge remote-tracking branch 'asoc/topic/component' into asoc-next

Merge remote-tracking branch 'asoc/topic/bclk' into asoc-next

Merge remote-tracking branch 'asoc/topic/atmel' into asoc-next

Merge remote-tracking branch 'asoc/topic/arizona' into asoc-next

Merge remote-tracking branch 'asoc/topic/ak4642' into asoc-next

Merge remote-tracking branch 'asoc/topic/ak4104' into asoc-next

Merge remote-tracking branch 'asoc/topic/adav80x' into asoc-next

Merge remote-tracking branch 'asoc/topic/adau1373' into asoc-next

Merge remote-tracking branch 'asoc/topic/ab8500' into asoc-next

Merge remote-tracking branch 'asoc/topic/88pm860x' into asoc-next

Merge remote-tracking branch 'asoc/fix/tlv320aic3x' into asoc-linus

Merge remote-tracking branch 'asoc/fix/rcar' into asoc-linus

Merge remote-tracking branch 'asoc/fix/pcm1792a' into asoc-linus

Merge remote-tracking branch 'asoc/fix/pcm1681' into asoc-linus

Merge remote-tracking branch 'asoc/fix/omap' into asoc-linus

Merge remote-tracking branch 'asoc/fix/fsl' into asoc-linus

ASoC: fsl: Add missing pm to current machine drivers

Add missing pm to current machine drivers so that all of them would
correctly do suspend/resume.

Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: dmaengine: Use filter_data rather than dma_data for compat requests

When using the legacy filter function channel requests we currently pass
the audio specific struct snd_dmaengine_dai_dma_data which isn't likely to
be helpful for actual filtering. Since there's already a field in the
structure called filter_data clearly intended for use here convert the
driver to use that.

All existing users of plain filter functions have been converted to use
an explicit compat function to override this behaviour except i.MX which
is working around this issue in its filter function and is updated to
just use filter_data directly here.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>

ALSA: hda - Fix mute LED on HP laptops in runtime suspend

When HP laptops with mute and mic-record LEDs go to runtime suspend,
these LEDs are turned on forcibly no matter whether GPIO pis are on or
off.  This strange behavior seems triggered by resetting the HD-audio
bus link at azx_rutime_suspend().  So, just add a new hda_bus flag to
avoid the link reset at runtime suspend and set it for these HP
machines.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Add support of ALC285 / ALC293 codecs

Yet another variants of ALC269.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Add support of ALC255 codecs

It's just another variant of ALC269 & co.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - Remove OOM message after input_allocate_device

Emitting an OOM message isn't necessary after input_allocate_device
as there's a generic OOM and a dump_stack already done.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: dmaengine: Support custom channel names

Some devices have more than just simple TX and RX DMA channels, for example
modern Samsung I2S IPs support a secondary transmit DMA stream which is
mixed into the primary stream during playback. Allow such devices to
specify the names of the channels to be requested in their dma_data.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>

ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4

When a machine goes to S3/S4 after power-save is enabled, the runtime
PM refcount might be incorrectly decreased because the power-down
triggered soon after resume assumes that the controller was already
powered up, and issues the pm_notify down.

This patch fixes the incorrect pm_notify call simply by checking the
current value properly.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: Add SoC on-chip internal ram support for DMA buffer allocation

Now it's quite common that an SoC contains its on-chip internal RAM.
By using this RAM space for DMA buffer during audio playback/record,
we can shutdown the voltage for external RAM to save power.

So add new DEV type with iram malloc()/free() and accordingly modify
current default mmap() for the iram circumstance.

Signed-off-by: Nicolin Chen <b42378@freescale.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: tpa6130a2: Add device tree support

Add device tree support to tpa6130a2 driver and document the
bindings.

Signed-off-by: Sebastian Reichel <sre@debian.org>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-evm: Add device tree binding

Device tree support for Davinci Machine driver

When the board boots with device tree, the driver will receive card,
codec, dai interface details (like the card name, DAPM routing map,
phandle for the audio components described in the dts file, codec mclk
speed). The card will be set up based on this information. Since the
routing is provided via DT we can mark the card fully routed so core
can take care of disconnecting the unused pins.

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-mcasp: Remove last reference to num-serializer in DT doc

Remove last reference to num-serializer in davinci-mcasp devicetree
binding document.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci: Add support for AM33xx SoC Audio

AM33xx uses same McASP IP as the Davinci Platform. This patch updates
Kconfig and makefile to enable build for McASP, PCM & Codec drivers.

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: tegra: Remove redundant initialisation of compat_filter_fn

Setting a field in a static struct to NULL has no effect so don't bother
(and don't generate false positives for grep).

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Stephen Warren <swarren@nvidia.com>

ASoC: ep93xx: Open code dma channel request

Currently the ep93xx DMA code is one of the few users relying on the fact
that the compat code uses the dma_data as the filter data for non-DT
channel requests. Since the rest of the core expects this to be a struct
snd_dmaengine_dai_data this isn't terribly helpful this will be changed to
use the already existing filter data so avoid breaking ep93xx by open
coding the current behaviour.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>

ASoC: davinci-mcasp: Remove redundant num-serializer DT parameter

The serial-dir array gives this information so there is no need to have the
num-serializer property in DT description.
Just ignore the property in the driver the DTS files can be updated
separately without regression.
Update the documentation at the same time for davinci-mcasp

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-mcasp: Improve DT bindings document

Makes interrupts property optional as the interrupts are not currently
used by the driver and adds interrupt-names property to name listed
interrupts. Currently know interrupt names are "tx" and "rx".

- Improve tdm-slots propery description

- Improve op-mode property description

- Add pinctrl-names and pinctrl-0 properties

- Remove #address-cells and #size-cells as they are not needed.

- Bracket named interrupts property tuples for uniformity.

- Add missing "for" to serial-dir prop in DT bindings doc.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-mcasp: Change compatible property model to more accurate

Change the model omap2-mcasp-audio in compatible property to
am33xx-mcasp-audio as omap2 does not have mcasp.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-mcasp: Extract DMA channels directly from DT

Extract DMA channels directly from DT as they can not be found from
platform resources anymore. This is a work-around until davinci audio
driver is updated to use dmaengine.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: davinci-mcasp: Add location for data port registers to DT

This patch adds a separate register location for data port registers to
mcasp DT bindings. On am33xx SoCs the McASP registers are mapped
trough L4 interconnect, but data port registers are also mapped trough
L3 bus to a different memory location.

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: kirkwood: add S/PDIF support

This patch adds S/PDIF input/output for mvebu DT boards.

Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mark Brown <broonie@linaro.org>

ASoC: dont call dapm_sync while reporting jack always

While reporting the jack status snd_soc_jack_report() invokes snd_soc_dapm_sync()
always. This should be required when we have pins associated with jack and
reporting enables or disables these.
So add a check for this case

Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'dice-driver-playback-only' of git://git.alsa-project.org/alsa-kprivate into for-next

ALSA: hda - Fix typos in patch_hdmi.c

... which was introduced by the previous commit a4e9a38b, causing
build errors without CONFIG_PROC_FS.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: hda - add codec ID for Valleyview2 display codec

This patch adds codec ID (0x80862882) and module alias for
Valleyview2 display codec.

Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ASoC: si476x: Fix locking of core

The conversion of the si476x to regmap removed locking of the core during
register updates, allowing things like power state changes for the MFD to
happen during a register update. Avoid this by taking the core lock in the
DAI operations (which are the only things that do register updates) as we
used to do in the open coded register I/O functions.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>

ALSA: dice: restrict the driver to playback-only devices

At the moment, this driver supports only playback, while FFADO supports
(only) full-duplex devices.  So, prevent conflicts by not claiming
devices that would be better handled by FFADO.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: fix detection of Weiss devices

While most DICE devices keep TCAT's default category ID of 0x04, Weiss
devices identify themselves with 0x00.

Reported-by: Rolf Anderegg <rolf.anderegg@weiss.ch>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: dice_proc_read: remove wrong typecast

Remove a wrong typecast that resulted from a copy-and-paste error.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: document quadlet alignment

Doing accesses without quadlet alignment is a bad idea because the
firmware's byte-swapping would garble the data; clarify this in the
documentation.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: add a proc file to show device information

For easier debugging, add a proc file to show the device's capabilities
and current status.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: check clock change timeout

Output a warning if the wait for the clock change notification times
out.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>

ALSA: dice: dynamic sample rate selection

Instead of relying of some control panel application to configure some
fixed sample rate, allow applications to set it automatically.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>