kbuild: Fix reference to vermagic.h

    It's "include/linux/vermagic.h", not "include/vermagic.h"

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
[PATCH 1/6] ASoC: davinci-pcm: trivial: make ping-pong params setup symmetrical

    The setup of the pong channel uses EDMA_CHAN_SLOT instead of & 0x3f as the
    setup of the ping channel does.

    Make the setup of ping and pong symmetric. There is no functional change
    introduced by this patch.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[PATCH 2/6] ASoC: davinci-pcm: expand the .formats

    Based on the data_type test in ping_pong_dma_setup, davinci-pcm is capable of
    handling data of width up to and including 32bits.

    "
    	if ((data_type == 0) || (data_type > 4)) {
    		printk(KERN_ERR "%s: data_type=%i\n", __func__, data_type);
    		return -EINVAL;
    	}
    "

    Update the .format member of the snd_pcm_hardware instances it registers to
    reflect this capability.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[PATCH 3/6] ASoC: davinci-pcm: increase the maximum channels

    Based on the registration of davinci-mcasp.1 in the davinci-evm platform
    setup for da830 and dm6467, davinci-pcm can handle more than the currently
    reported maximum channels of 2.

    Increase the maximum channels to 384 to match the maximum reported by
    davinci-mcasp.1.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[PATCH 4/6] ASoC: davinci-pcm: fix audible glitch on 2nd ping-pong playback

    The release of the dma channels was being performed in prepare and there was a
    edma_resume call for the asp-channel only being executed on START, RESUME and
    PAUSE_RELEASE.

    The mcasp on da850evm with ping-pong buffers enabled was exhibiting an audible
    glitch on every playback after the first. It was determined through trial and
    error that the following two changes fix this problem:

    1) Move the edma_start calls from prepare to trigger and 2) reverse the order
    of starting the asp and ram channels.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[PATCH 5/6] ASoC: davinci-pcm: extract period elapsed functions

    Extract functions that modify the prtd->period member in preparation for
    conversion to BATCH mode playback.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[PATCH 6/6] ASoC: davinci-pcm: convert to BATCH mode

    The davinci-pcm driver's snd_pcm_ops pointer function currently calls into
    the edma controller driver to read the current positions of the edma channels
    to determine pos to return to the ALSA framework. In particular,
    davinci_pcm_pointer() calls edma_get_position() and the latter has a comment
    indicating that "Its channel should not be active when this is called" whereas
    the channel is surely active when snd_pcm_ops.pointer is called.

    The operation of davinci-pcm in capture and playback appears to follow close
    the other pcm drivers who export SNDRV_PCM_INFO_BATCH except that davinci-pcm
    does not report it's positions from pointer() using the last transferred
    chunk. Instead it peeks directly into the edma controller to determine the
    current position as discussed above.

    Convert the davinci-pcm driver to BATCH mode: count the periods elapsed in the
    prtd->period member and use its value to report the 'pos' to the alsa
    framework in the davinci_pcm_pointer function.

    There is a phase offset of 2 periods between the position used by dma setup
    and the position reported in the pointer function. Either +2 in the dma
    setup or -2 in the pointer function (with wrapping, both) accounts for this
    offset -- I opted for the latter since it makes the first-time setup clearer.

    Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
    Reviewed-by: Steven Faludi <stevenfaludi@nanometrics.ca>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>