[alsa-devel] tascam us122l patch commit
Hi, I have just attempted to install the 3.10.10 realtime kernel and I have discovered that the patch l listed in the following webpage :
http://www.remastersys.com/forums/index.php?topic=3013.60
doesn't seem to have made it 'upstream' (I am not particularly familiar with the terminology).
It's simple to do by hand but I can confirm that I have been using the above patch (VM_IO) on 3.8.13 and 3.10.10 kernels with success - the tascam us122L works fine.
Many thanks
At Sat, 5 Oct 2013 11:35:58 +0100, James Miller wrote:
Hi, I have just attempted to install the 3.10.10 realtime kernel and I have discovered that the patch l listed in the following webpage :
http://www.remastersys.com/forums/index.php?topic=3013.60
doesn't seem to have made it 'upstream' (I am not particularly familiar with the terminology).
It's simple to do by hand but I can confirm that I have been using the above patch (VM_IO) on 3.8.13 and 3.10.10 kernels with success - the tascam us122L works fine.
Hrm, interesting. VM_IO must be incorrect in this case (the allocated buffer is real RAM pages), but it makes the device working by some reason. We can't apply the patch because it's wrong, but need to investigate more why it apparently fixes...
Takashi
At Mon, 07 Oct 2013 10:29:42 +0200, Takashi Iwai wrote:
At Sat, 5 Oct 2013 11:35:58 +0100, James Miller wrote:
Hi, I have just attempted to install the 3.10.10 realtime kernel and I have discovered that the patch l listed in the following webpage :
http://www.remastersys.com/forums/index.php?topic=3013.60
doesn't seem to have made it 'upstream' (I am not particularly familiar with the terminology).
It's simple to do by hand but I can confirm that I have been using the above patch (VM_IO) on 3.8.13 and 3.10.10 kernels with success - the tascam us122L works fine.
Hrm, interesting. VM_IO must be incorrect in this case (the allocated buffer is real RAM pages), but it makes the device working by some reason. We can't apply the patch because it's wrong, but need to investigate more why it apparently fixes...
I think I nailed down. Could you try the patch below?
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: usx2y, us122l: Fix pcm_usb_stream mmapping regression
The pcm_usb_stream plugin requires the mremap explicitly for the read buffer, as it expands itself once after reading the required size. But the commit [314e51b9: mm: kill vma flag VM_RESERVED and mm->reserved_vm counter] converted blindly to a combination of VM_DONTEXPAND | VM_DONTDUMP like other normal drivers, and this resulted in the failure of mremap().
For fixing this regression, we need to remove VM_DONTEXPAND for the read-buffer mmap.
Reported-by: James Miller jamesstewartmiller@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/usb/usx2y/us122l.c | 4 +++- sound/usb/usx2y/usx2yhwdeppcm.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c index d0323a6..999550b 100644 --- a/sound/usb/usx2y/us122l.c +++ b/sound/usb/usx2y/us122l.c @@ -262,7 +262,9 @@ static int usb_stream_hwdep_mmap(struct snd_hwdep *hw, }
area->vm_ops = &usb_stream_hwdep_vm_ops; - area->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; + area->vm_flags |= VM_DONTDUMP; + if (!read) + area->vm_flags |= VM_DONTEXPAND; area->vm_private_data = us122l; atomic_inc(&us122l->mmap_count); out: diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c index 814d0e8..38db444 100644 --- a/sound/usb/usx2y/usx2yhwdeppcm.c +++ b/sound/usb/usx2y/usx2yhwdeppcm.c @@ -717,7 +717,9 @@ static int snd_usX2Y_hwdep_pcm_mmap(struct snd_hwdep * hw, struct file *filp, st return -ENODEV; } area->vm_ops = &snd_usX2Y_hwdep_pcm_vm_ops; - area->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; + area->vm_flags |= VM_DONTDUMP; + if (!read) + area->vm_flags |= VM_DONTEXPAND; area->vm_private_data = hw->private_data; return 0; }
participants (2)
-
James Miller
-
Takashi Iwai