Hi, All
Seems this is MIPS specific, but it's not that easy to move this patch
into the arch/mips part, So, any better solution?
Thanks & Regards,
Wu Zhangjin
------------------------
The user application mmap audio dma regions must be dma-coherent. This
patch fix it.
Without this patch, artsd will fail on boot, and mplayer will exit with
"Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
mini pc with snd_cs5535 audio card)
This is originally from the to-mips branch of
http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
from Lemote Inc.
Reported-by: qiaochong <[email protected]>
Signed-off-by: Wu Zhangjin <[email protected]>
---
sound/core/pcm_native.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ab73edf..2779b9a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3087,7 +3087,11 @@ static int snd_pcm_mmap_data_fault(struct vm_area_struct *area,
return VM_FAULT_SIGBUS;
} else {
vaddr = runtime->dma_area + offset;
+#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT)
+ page = virt_to_page(CAC_ADDR(vaddr));
+#else
page = virt_to_page(vaddr);
+#endif
}
get_page(page);
vmf->page = page;
@@ -3202,6 +3206,11 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area)
if (PCM_RUNTIME_CHECK(substream))
return -ENXIO;
+#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT)
+ /* all mmap using uncached mode */
+ area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
+ area->vm_flags |= (VM_RESERVED | VM_IO);
+#endif
offset = area->vm_pgoff << PAGE_SHIFT;
switch (offset) {
case SNDRV_PCM_MMAP_OFFSET_STATUS:
--
1.6.2.1
On Tue, Nov 17, 2009 at 12:48:14AM +0800, Wu Zhangjin wrote:
> Seems this is MIPS specific, but it's not that easy to move this patch
> into the arch/mips part, So, any better solution?
>
> Thanks & Regards,
> Wu Zhangjin
>
> ------------------------
>
> The user application mmap audio dma regions must be dma-coherent. This
> patch fix it.
>
> Without this patch, artsd will fail on boot, and mplayer will exit with
> "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> mini pc with snd_cs5535 audio card)
>
> This is originally from the to-mips branch of
> http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> from Lemote Inc.
>
> Reported-by: qiaochong <[email protected]>
> Signed-off-by: Wu Zhangjin <[email protected]>
This issue is an old ghost still around, see:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp
which is a superset of your proposed patch and which itself is refering to
an even older posting from 2003:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com
The #ifdef'ed solution doesn't cut it for sure. Let's see what better we
can find ...
Ralf
At Tue, 17 Nov 2009 00:48:14 +0800,
Wu Zhangjin wrote:
>
> Hi, All
>
> Seems this is MIPS specific, but it's not that easy to move this patch
> into the arch/mips part, So, any better solution?
Actually, this has been a looong-standing problem.
I have a series of patches to fix these issues, but it's more
intensively involved with dma_*() functions.
The patches can be found in test/dma-fix branch of sound GIT tree.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
This basically adds dma_mmap_coherent() function to feasible
architectures, which is already implemented for ARM, so far.
thanks,
Takashi
At Mon, 16 Nov 2009 18:06:41 +0100,
Ralf Baechle wrote:
>
> On Tue, Nov 17, 2009 at 12:48:14AM +0800, Wu Zhangjin wrote:
>
> > Seems this is MIPS specific, but it's not that easy to move this patch
> > into the arch/mips part, So, any better solution?
> >
> > Thanks & Regards,
> > Wu Zhangjin
> >
> > ------------------------
> >
> > The user application mmap audio dma regions must be dma-coherent. This
> > patch fix it.
> >
> > Without this patch, artsd will fail on boot, and mplayer will exit with
> > "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> > mini pc with snd_cs5535 audio card)
> >
> > This is originally from the to-mips branch of
> > http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> > from Lemote Inc.
> >
> > Reported-by: qiaochong <[email protected]>
> > Signed-off-by: Wu Zhangjin <[email protected]>
>
> This issue is an old ghost still around, see:
>
> http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp
>
> which is a superset of your proposed patch and which itself is refering to
> an even older posting from 2003:
>
> http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com
>
> The #ifdef'ed solution doesn't cut it for sure. Let's see what better we
> can find ...
Indeed. My preference option is to deploy dma_mmap_coherent() to
possible architectures and use it commonly in the ALSA core code.
But, as a temporary workaround, I'm fine with ifdef until the API is
defined...
thanks,
Takashi
On Mon, Nov 16, 2009 at 06:12:22PM +0100, Takashi Iwai wrote:
> Actually, this has been a looong-standing problem.
> I have a series of patches to fix these issues, but it's more
> intensively involved with dma_*() functions.
>
> The patches can be found in test/dma-fix branch of sound GIT tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
>
> This basically adds dma_mmap_coherent() function to feasible
> architectures, which is already implemented for ARM, so far.
Cool - but needs a little further tweaking to work right. That's a
solution which will use uncached accesses on all MIPS systems.
IP27/IP35-family machines will explode when you try that. Eventually the
cache coherency logic will notice that cache, directory caches and memory
have become inconsistent and bombard the CPU with a bunch of nasty
exceptions.
For cache-coherent machines otoh it's a big waste of performance.
int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t handle, size_t size)
{
struct page *pg;
if (!plat_device_is_coherent(dev))
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
cpu_addr = (void *)dma_addr_to_virt(handle);
pg = virt_to_page(cpu_addr);
return remap_pfn_range(vma, vma->vm_start,
page_to_pfn(pg) + vma->vm_pgoff,
size, vma->vm_page_prot);
}
EXPORT_SYMBOL(dma_mmap_coherent);
Thomas - you're the IP28 specialist. Would the plat_device_is_coherent()
above have to become a cpu_is_noncoherent_r10000() call? Any further
nasties?
Ralf
At Mon, 16 Nov 2009 18:43:24 +0100,
Ralf Baechle wrote:
>
> On Mon, Nov 16, 2009 at 06:12:22PM +0100, Takashi Iwai wrote:
>
> > Actually, this has been a looong-standing problem.
> > I have a series of patches to fix these issues, but it's more
> > intensively involved with dma_*() functions.
> >
> > The patches can be found in test/dma-fix branch of sound GIT tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> >
> > This basically adds dma_mmap_coherent() function to feasible
> > architectures, which is already implemented for ARM, so far.
>
> Cool - but needs a little further tweaking to work right. That's a
> solution which will use uncached accesses on all MIPS systems.
>
> IP27/IP35-family machines will explode when you try that. Eventually the
> cache coherency logic will notice that cache, directory caches and memory
> have become inconsistent and bombard the CPU with a bunch of nasty
> exceptions.
OK, that's really bad.
> For cache-coherent machines otoh it's a big waste of performance.
>
> int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> void *cpu_addr, dma_addr_t handle, size_t size)
> {
> struct page *pg;
>
> if (!plat_device_is_coherent(dev))
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> cpu_addr = (void *)dma_addr_to_virt(handle);
> pg = virt_to_page(cpu_addr);
>
> return remap_pfn_range(vma, vma->vm_start,
> page_to_pfn(pg) + vma->vm_pgoff,
> size, vma->vm_page_prot);
> }
> EXPORT_SYMBOL(dma_mmap_coherent);
>
> Thomas - you're the IP28 specialist. Would the plat_device_is_coherent()
> above have to become a cpu_is_noncoherent_r10000() call? Any further
> nasties?
Thanks for checking!
thanks,
Takashi
On Mon, Nov 16, 2009 at 06:14:14PM +0100, Takashi Iwai wrote:
> > > Seems this is MIPS specific, but it's not that easy to move this patch
> > > into the arch/mips part, So, any better solution?
> > >
> > > Thanks & Regards,
> > > Wu Zhangjin
> > >
> > > ------------------------
> > >
> > > The user application mmap audio dma regions must be dma-coherent. This
> > > patch fix it.
> > >
> > > Without this patch, artsd will fail on boot, and mplayer will exit with
> > > "Segmentation fault". (this happens on YeeLoong netbook, fuloong2f
> > > mini pc with snd_cs5535 audio card)
> > >
> > > This is originally from the to-mips branch of
> > > http://dev.lemote.com/code/linux_loongson, and contributed by Yanhua
> > > from Lemote Inc.
> > >
> > > Reported-by: qiaochong <[email protected]>
> > > Signed-off-by: Wu Zhangjin <[email protected]>
> >
> > This issue is an old ghost still around, see:
> >
> > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20060124.132832.37533152.nemoto%40toshiba-tops.co.jp
> >
> > which is a superset of your proposed patch and which itself is refering to
> > an even older posting from 2003:
> >
> > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20030523215935.71373.qmail%40web11901.mail.yahoo.com
> >
> > The #ifdef'ed solution doesn't cut it for sure. Let's see what better we
> > can find ...
>
> Indeed. My preference option is to deploy dma_mmap_coherent() to
> possible architectures and use it commonly in the ALSA core code.
>
> But, as a temporary workaround, I'm fine with ifdef until the API is
> defined...
There is a MIPS platform which may be based on a variety of system
controllers only one of which supports cache coherency. So we want to
deciede at runtime not at compile time.
Ralf
On Tue, Nov 17, 2009 at 10:29:10AM +0100, Takashi Iwai wrote:
> > > Actually, this has been a looong-standing problem.
> > > I have a series of patches to fix these issues, but it's more
> > > intensively involved with dma_*() functions.
> > >
> > > The patches can be found in test/dma-fix branch of sound GIT tree.
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> > >
> > > This basically adds dma_mmap_coherent() function to feasible
> > > architectures, which is already implemented for ARM, so far.
> >
> > Cool - but needs a little further tweaking to work right. That's a
> > solution which will use uncached accesses on all MIPS systems.
> >
> > IP27/IP35-family machines will explode when you try that. Eventually the
> > cache coherency logic will notice that cache, directory caches and memory
> > have become inconsistent and bombard the CPU with a bunch of nasty
> > exceptions.
>
> OK, that's really bad.
Hardware designers do such things to you. Often even for a reason.
> > For cache-coherent machines otoh it's a big waste of performance.
> >
> > int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> > void *cpu_addr, dma_addr_t handle, size_t size)
> > {
> > struct page *pg;
> >
> > if (!plat_device_is_coherent(dev))
> > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > cpu_addr = (void *)dma_addr_to_virt(handle);
> > pg = virt_to_page(cpu_addr);
> >
> > return remap_pfn_range(vma, vma->vm_start,
> > page_to_pfn(pg) + vma->vm_pgoff,
> > size, vma->vm_page_prot);
> > }
> > EXPORT_SYMBOL(dma_mmap_coherent);
> >
> > Thomas - you're the IP28 specialist. Would the plat_device_is_coherent()
> > above have to become a cpu_is_noncoherent_r10000() call? Any further
> > nasties?
>
> Thanks for checking!
You're welcome!
So basically I'd not mind putting this into the Linux/MIPS tree; we still
can iron out the kinks from there on and probably much better than by
having arch stuff in the ALSA tree.
I recall this new API having been posted for discussion to linux-arch.
What was the outcome? I'd only like to add a new API if the other arch
maintainers see it fit their needs also.
Ralf
At Wed, 18 Nov 2009 15:20:56 +0100,
Ralf Baechle wrote:
>
> On Tue, Nov 17, 2009 at 10:29:10AM +0100, Takashi Iwai wrote:
>
> > > > Actually, this has been a looong-standing problem.
> > > > I have a series of patches to fix these issues, but it's more
> > > > intensively involved with dma_*() functions.
> > > >
> > > > The patches can be found in test/dma-fix branch of sound GIT tree.
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
> > > >
> > > > This basically adds dma_mmap_coherent() function to feasible
> > > > architectures, which is already implemented for ARM, so far.
> > >
> > > Cool - but needs a little further tweaking to work right. That's a
> > > solution which will use uncached accesses on all MIPS systems.
> > >
> > > IP27/IP35-family machines will explode when you try that. Eventually the
> > > cache coherency logic will notice that cache, directory caches and memory
> > > have become inconsistent and bombard the CPU with a bunch of nasty
> > > exceptions.
> >
> > OK, that's really bad.
>
> Hardware designers do such things to you. Often even for a reason.
Heh, not only software engineers are so crazy ;)
> > > For cache-coherent machines otoh it's a big waste of performance.
> > >
> > > int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
> > > void *cpu_addr, dma_addr_t handle, size_t size)
> > > {
> > > struct page *pg;
> > >
> > > if (!plat_device_is_coherent(dev))
> > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > cpu_addr = (void *)dma_addr_to_virt(handle);
> > > pg = virt_to_page(cpu_addr);
> > >
> > > return remap_pfn_range(vma, vma->vm_start,
> > > page_to_pfn(pg) + vma->vm_pgoff,
> > > size, vma->vm_page_prot);
> > > }
> > > EXPORT_SYMBOL(dma_mmap_coherent);
> > >
> > > Thomas - you're the IP28 specialist. Would the plat_device_is_coherent()
> > > above have to become a cpu_is_noncoherent_r10000() call? Any further
> > > nasties?
> >
> > Thanks for checking!
>
> You're welcome!
>
> So basically I'd not mind putting this into the Linux/MIPS tree; we still
> can iron out the kinks from there on and probably much better than by
> having arch stuff in the ALSA tree.
Yes, that's the very purpose of my patchset.
> I recall this new API having been posted for discussion to linux-arch.
> What was the outcome? I'd only like to add a new API if the other arch
> maintainers see it fit their needs also.
Well, we haven't reached the consensus. The discussion faded away
somehow mainly because I had too little time to update and ping people
again.
In Tokyo, I talked with some guys regarding this. Ben agreed to take
this approach for ppc, and David said that he doesn't mind for sparc
part. Fujita-san mentioned it's no big problem to add one op from
the generic dma_ops.
So, maybe somehow need to convince James in the end (and ask Paul to
check SH part, too), then it'll be all up... theoretically :)
Anyway, I'm going to raise the discussion again on linux-arch.
I'm afraid it's a bit too late game for 2.6.33, but starting now is
better than too late again.
thanks,
Takashi
On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
[...]
>
> Well, we haven't reached the consensus. The discussion faded away
> somehow mainly because I had too little time to update and ping people
> again.
>
> In Tokyo, I talked with some guys regarding this. Ben agreed to take
> this approach for ppc, and David said that he doesn't mind for sparc
> part. Fujita-san mentioned it's no big problem to add one op from
> the generic dma_ops.
>
> So, maybe somehow need to convince James in the end (and ask Paul to
> check SH part, too), then it'll be all up... theoretically :)
>
> Anyway, I'm going to raise the discussion again on linux-arch.
> I'm afraid it's a bit too late game for 2.6.33, but starting now is
> better than too late again.
Hi, Takashi Iwai
Before the API stuff going into the mainline(2.6.33), can we apply this
"[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
necessares) as a current fixup. and then we will not get a broken sound
support for MIPS, and also the support to the latest Loongson2F family
machines will benefit from it.
and Ralf, what about your suggestion?
Thanks & Best wishes,
Wu Zhangjin
At Sat, 21 Nov 2009 20:31:41 +0800,
Wu Zhangjin wrote:
>
> On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> [...]
> >
> > Well, we haven't reached the consensus. The discussion faded away
> > somehow mainly because I had too little time to update and ping people
> > again.
> >
> > In Tokyo, I talked with some guys regarding this. Ben agreed to take
> > this approach for ppc, and David said that he doesn't mind for sparc
> > part. Fujita-san mentioned it's no big problem to add one op from
> > the generic dma_ops.
> >
> > So, maybe somehow need to convince James in the end (and ask Paul to
> > check SH part, too), then it'll be all up... theoretically :)
> >
> > Anyway, I'm going to raise the discussion again on linux-arch.
> > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > better than too late again.
>
> Hi, Takashi Iwai
>
> Before the API stuff going into the mainline(2.6.33), can we apply this
> "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> necessares) as a current fixup. and then we will not get a broken sound
> support for MIPS, and also the support to the latest Loongson2F family
> machines will benefit from it.
>
> and Ralf, what about your suggestion?
The question is whether this hack can be safely added for all MIPS
platforms just by checking kconfig. I had an impression that rather
many things have to be checked in the runtime.
As I have really little clue about MIPS architecture, I'd like let
MIPS guys decide about it...
thanks,
Takashi
On Mon, Nov 23, 2009 at 09:56:39AM +0100, Takashi Iwai wrote:
> > On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> > [...]
> > >
> > > Well, we haven't reached the consensus. The discussion faded away
> > > somehow mainly because I had too little time to update and ping people
> > > again.
> > >
> > > In Tokyo, I talked with some guys regarding this. Ben agreed to take
> > > this approach for ppc, and David said that he doesn't mind for sparc
> > > part. Fujita-san mentioned it's no big problem to add one op from
> > > the generic dma_ops.
> > >
> > > So, maybe somehow need to convince James in the end (and ask Paul to
> > > check SH part, too), then it'll be all up... theoretically :)
> > >
> > > Anyway, I'm going to raise the discussion again on linux-arch.
> > > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > > better than too late again.
> >
> > Hi, Takashi Iwai
> >
> > Before the API stuff going into the mainline(2.6.33), can we apply this
> > "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> > necessares) as a current fixup. and then we will not get a broken sound
> > support for MIPS, and also the support to the latest Loongson2F family
> > machines will benefit from it.
> >
> > and Ralf, what about your suggestion?
>
> The question is whether this hack can be safely added for all MIPS
> platforms just by checking kconfig. I had an impression that rather
> many things have to be checked in the runtime.
>
> As I have really little clue about MIPS architecture, I'd like let
> MIPS guys decide about it...
Okay, I'll cook up a nice kludge. It can't cover all cases but it will
be an improvment for most platforms.
Ralf
At Mon, 23 Nov 2009 12:36:15 +0000,
Ralf Baechle wrote:
>
> On Mon, Nov 23, 2009 at 09:56:39AM +0100, Takashi Iwai wrote:
>
> > > On Wed, 2009-11-18 at 18:47 +0100, Takashi Iwai wrote:
> > > [...]
> > > >
> > > > Well, we haven't reached the consensus. The discussion faded away
> > > > somehow mainly because I had too little time to update and ping people
> > > > again.
> > > >
> > > > In Tokyo, I talked with some guys regarding this. Ben agreed to take
> > > > this approach for ppc, and David said that he doesn't mind for sparc
> > > > part. Fujita-san mentioned it's no big problem to add one op from
> > > > the generic dma_ops.
> > > >
> > > > So, maybe somehow need to convince James in the end (and ask Paul to
> > > > check SH part, too), then it'll be all up... theoretically :)
> > > >
> > > > Anyway, I'm going to raise the discussion again on linux-arch.
> > > > I'm afraid it's a bit too late game for 2.6.33, but starting now is
> > > > better than too late again.
> > >
> > > Hi, Takashi Iwai
> > >
> > > Before the API stuff going into the mainline(2.6.33), can we apply this
> > > "[PATCH] MIPS: Fixups of ALSA memory maps"(This is the minimal
> > > necessares) as a current fixup. and then we will not get a broken sound
> > > support for MIPS, and also the support to the latest Loongson2F family
> > > machines will benefit from it.
> > >
> > > and Ralf, what about your suggestion?
> >
> > The question is whether this hack can be safely added for all MIPS
> > platforms just by checking kconfig. I had an impression that rather
> > many things have to be checked in the runtime.
> >
> > As I have really little clue about MIPS architecture, I'd like let
> > MIPS guys decide about it...
>
> Okay, I'll cook up a nice kludge. It can't cover all cases but it will
> be an improvment for most platforms.
OK, but I found that the original patch doesn't work correctly for
some cases, as I mentioned in another thread. I'm going to send a patch
set soon as a new thread.
thanks,
Takashi