31 Jan, 2011

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
    ALSA: HDA: Fix automute on Thinkpad L412/L512
    ALSA: HDA: Fix dmesg output of HDMI supported bits
    ALSA: fix invalid hardware.h include in ac97c for AVR32 architecture
    ASoC: correct link specifications for corgi, poodle and spitz
    ASoC: Samsung: Fix outdated cpu_dai_name for s3c24xx i2s
    ASoC: Fix codec device id format used by some dai_links
    ALSA: azt3328 - fix broken AZF_FMT_XLATE macro
    ALSA: Xonar, CS43xx: Don't overrun static array
    ASoC: Handle low measured DC offsets for wm_hubs devices
    ASoC: da8xx/omap-l1xx: match codec_name with i2c ids
    ASoC: WM8994: fix wrong value in tristate function
    ASoC: WM8995: Fix incorrect use of snd_soc_update_bits()

    Linus Torvalds
     

28 Jan, 2011

1 commit


26 Jan, 2011

5 commits


25 Jan, 2011

4 commits

  • ASoC DAI link descriptions for Corgi, Poodle and Spitz platforms
    contained incorrect names for cpu_dai and codec, which effectievly disabled sound
    on theese platforms. Fix that errors.

    Signed-off-by: Dmitry Eremin-Solenikov
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Dmitry Eremin-Solenikov
     
  • During the multi-component patch the s3c24xx i2s driver was renamed from
    "s3c24xx-i2s" to "s3c24xx-iis", while the sound board drivers were not
    updated to reflect this change as well.

    As a result there is no match between the dai_link and the i2s driver and no
    sound card is instantiated.

    This patch fixes the problem by updating the sound board drivers to use
    "s3c24xx-iis" for the cpu_dai_name.

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Jassi Brar
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Lars-Peter Clausen
     
  • The id part of an I2C device name is created with the "%d-%04x" format string.

    So for example for an I2C device which is connected to the adapter with the id 0
    and has its address set to 0x1a the id part of the devices name would be
    "0-001a".

    Currently some sound board drivers have the id part the codec_name field of
    their dai_link structures set as if it had been created by a "%d-0x%x" format
    string. For example "0-0x1a" instead of "0-001a".

    As a result there is no match between the codec device and the dai_link and no
    sound card is instantiated.

    This patch fixes it.

    Signed-off-by: Lars-Peter Clausen
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Lars-Peter Clausen
     
  • Cleanly revert to non-macro implementation of
    snd_azf3328_codec_setfmt(), to fix last-minute functionality breakage
    induced by following checkpatch.pl recommendations without giving them
    their due full share of thought ("revolting computer, ensuing PEBKAC").

    I would like to thank Jiri Slaby for his very timely (in -rc1 even)
    and unexpected (uncommon hardware) "recognition of the dangerous situation"
    due to his very commendable static parser use. :)

    Reported-by: Jiri Slaby
    Signed-off-by: Andreas Mohr
    Signed-off-by: Takashi Iwai

    Andreas Mohr
     

23 Jan, 2011

1 commit

  • 'cs4398_regs' in 'struct xonar_cs43xx' is an array of 'u8' with a size of
    8. So, this code in sound/pci/oxygen/xonar_cs43xx.c::dump_d1_registers()

    for (i = 2; i cs4398_regs[i]);

    will overrun the array when 'i == 8'.

    I guess that what's needed to fix it is the trivial patch below, but I
    must admit that I have no idea about this code, so I may very well be
    wrong. Additionally, I have no way to actually test this, so all I know is
    that the below compiles. Someone who actually knows this code should take
    a look before anything is comitted - consider the below (not much more
    than) a bug report.

    Signed-off-by: Jesper Juhl
    Acked-by: Clemens Ladisch

    Jesper Juhl
     

22 Jan, 2011

2 commits


21 Jan, 2011

2 commits


20 Jan, 2011

4 commits


19 Jan, 2011

11 commits


18 Jan, 2011

7 commits


17 Jan, 2011

2 commits

  • Changelog:
    1. I2S module of EP93xx should be feed by 32bit DMA transfers. This is
    hardware limitation and that's the way original Cirrus's driver worked.
    This will fix distorted sound playback and make capture actually work in
    present ep93xx drivers.

    I've found, that author of code, on which modern ep93xx-i2s.c and
    ep93xx-pcm.c are based, had faced this problem also in 2007:
    http://blog.gmane.org/gmane.linux.ports.arm.cirrus/month=20070101/page=3

    Now SoC code uses his developments, but not overcomes the hardware
    issues. Some details from EP93xx users guide:

    Both I2S transmitter and receiver have similar 16x32bit FIFO, where they
    store 8 samples for both left and right channels. The FIFO is always
    32bit wide and should be properly aligned if you use samples of other
    width. Transmitter and receiver have configuration registers for
    selection of I2S word length (16, 24, 32). They are I2STXWrdLen and
    I2SRXWrdLen.

    Yes, EP93xx DMA can do byte, word and quad-word transfers. The width for
    transfers to and from peripherals is selected by particular module
    configuration. Lucky AC97 module has such configuration: AC97RXCRx
    registers, bit CM (Compact mode enable) switches between 16 and 32 bit
    samples. AC97TXCRx registers have the same bits for transmitters.
    ep93xx-ac97.c enables this compact mode and so has all the rights to use
    S16_LE format.
    No one has found such a configuration in I2S module until now in any
    Cirrus manuals. I2S module always feeds it's 32bit wide FIFO with 32bit
    samples consecutively for left and right channels. You cannot use 32-bit
    DMA transfers to transfer two 16-bit samples.

    So we can use two formats for AC97, but should remove all but S32_LE for
    I2S. Always using 32 bit chunks is not a problem for I2S, the codec I
    use uses less bits too (24), it's permitted by I2S standard.

    In proposed patch formats list shortened to just S32_LE, this makes all
    the DMA transactions right, while ALSA will do all sample format
    translation for us.

    2. Incorrect setting of LRCLK (2 times slower) in original ep93xx-i2s.c
    masks the first problem.

    DMA takes two 16 bit samples instead of one, overall sound speed seems
    to be normal, but you get actually 4000 sampling rate instead of
    requested 8000 and therefore some noise... This is also the reason why
    the capture function not worked at all in this driver...

    If we take a look into I2S specification, we will figure that LRCLK MUST
    be equal to sample rate, if we are talking about stereo (in mono too,
    but it's not our case at all).

    In proposed patch SCLK and LRCLK rates are corrected, assuming we always
    send 32 bits * 2 channels to codec.

    Signed-off-by: Alexander Sverdlin
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Alexander Sverdlin
     
  • Signed-off-by: Dimitris Papastamos
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Dimitris Papastamos