summaryrefslogtreecommitdiffstats
path: root/sound/pci/hda/hda_beep.h
diff options
context:
space:
mode:
authorMaciej S. Szmigiero <mail@maciej.szmigiero.name>2018-02-14 00:07:58 +0100
committerTakashi Iwai <tiwai@suse.de>2018-02-14 07:46:55 +0100
commit04f8773a3e980f60953e7aeb36ec6c2631e11f10 (patch)
treed6acfcbfd79924f50f46886683ca6c5f391d0b4f /sound/pci/hda/hda_beep.h
parent055e0ae10f509482ca5b140e8e5f4a77e31efdd5 (diff)
downloadlinux-04f8773a3e980f60953e7aeb36ec6c2631e11f10.tar.bz2
ALSA: emu10k1: add a IOMMU workaround
The Audigy 2 CA0102 chip (but most likely others from the emu10k1 family, too) has a problem that from time to time it likes to do few DMA reads a bit beyond its normal allocation and gets very confused if these reads get blocked by a IOMMU. For the first (reserved) page this happens multiple times at every playback, for various synth pages it happens randomly, rarely for PCM playback buffers and the page table memory itself. All these reads seem to follow a similar pattern, observed read offsets beyond the allocation end were 0x00, 0x40, 0x80 and 0xc0 (PCI cache line multiples), so it looks like the device tries to accesses up to 256 extra bytes. As a workaround let's widen these DMA allocations by an extra page if we detect that the device is behind a non-passthrough IOMMU (the DMA memory should be relatively plenty on IOMMU systems). Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'sound/pci/hda/hda_beep.h')
0 files changed, 0 insertions, 0 deletions