Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Takashi Iwai]

At Mon, 12 Jun 2006 16:42:54 +0200,
Gerhard Pircher wrote:
> 
> > > But as far as I understand this would require a rewrite of all the
> > > ALSA drivers (or at least a rewrite of the ALSA's DMA helper
> > > functions).
> > 
> > Yes.  The change of ALSA side has been also on my tree.  But it was
> > still pending since I'm not satisfied with the design yet.
> > If you're interested in it, let me know.  I'll post the patch.
> 
> Yes, please! Then I can test, if the dma_mmap_coherent() patch works on
> my non cache coherent powerpc machine.

For using dma_mmap_coherent(), the patch below should suffice.
(Also you need to enable HAVE_DMA_MMAP_COHERENT there not only for
 ARM.)

> Do you think the DMA Layer/ALSA patches will go upstream in one of
> the next ALSA/Linux kernel versions? 

Definitely no 2.6.18 material yet.


Takashi


diff -r 08577d0b45ef sound/core/pcm_native.c
--- a/sound/core/pcm_native.c	Tue Jun 13 12:01:14 2006 +0200
+++ b/sound/core/pcm_native.c	Wed Jun 14 16:40:32 2006 +0200
@@ -3123,6 +3123,10 @@ static int snd_pcm_mmap_control(struct s
 }
 #endif /* coherent mmap */
 
+#if defined(CONFIG_ARM)
+#define HAVE_DMA_MMAP_COHERENT
+#endif
+
 /*
  * nopage callback for mmapping a RAM page
  */
@@ -3166,6 +3170,14 @@ static struct vm_operations_struct snd_p
 	.nopage =	snd_pcm_mmap_data_nopage,
 };
 
+#ifdef HAVE_DMA_MMAP_COHERENT
+static struct vm_operations_struct snd_pcm_vm_ops_data_one_map =
+{
+	.open =		snd_pcm_mmap_data_open,
+	.close =	snd_pcm_mmap_data_close,
+};
+#endif
+
 /*
  * mmap the DMA buffer on RAM
  */
@@ -3175,6 +3187,16 @@ static int snd_pcm_default_mmap(struct s
 	area->vm_ops = &snd_pcm_vm_ops_data;
 	area->vm_private_data = substream;
 	area->vm_flags |= VM_RESERVED;
+#ifdef HAVE_DMA_MMAP_COHERENT
+	if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV) {
+		area->vm_ops = &snd_pcm_vm_ops_data_one_map;
+		if (dma_mmap_coherent(substream->dma_buffer.dev.dev, area,
+				      substream->runtime->dma_area,
+				      substream->runtime->dma_addr,
+				      area->vm_end - area->vm_start))
+			return -EAGAIN;
+	}
+#endif
 	atomic_inc(&substream->mmap_count);
 	return 0;
 }

Re: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Gerhard Pircher]

Hi,

It took a little bit longer to integrate the patch, as I didn't figure out  first how to implement the __dma_mmap_coherent() function for PPC systems with CONFIG_NOT_COHERENT_CACHE defined. :)

Unfortunately my system still crashes within snd_pcm_mmap_data_nopage() 
(sound/core/pcm_native.c), as you can see below. I guess it tries to remap 
a DMA buffer allocated by the not cache coherent DMA memory allocation 
function in arch/ppc/kernel/dma-mapping.c.

Jun 28 21:59:30 localhost kernel: [  199.869609] Using dma_mmap_coherent for mmaping DMA buffer!
Jun 28 21:59:30 localhost kernel: [  199.925075] Oops: kernel access of bad area, sig: 11 [#1]
Jun 28 21:59:30 localhost kernel: [  199.925106] NIP: E226FF44 LR: E226FF94 CTR: E226FEA4
Jun 28 21:59:30 localhost kernel: [  199.925116] REGS: d2577d30 TRAP: 0600   Not tainted  (2.6.16.16-a1-2)
Jun 28 21:59:30 localhost kernel: [  199.925121] MSR: 00009032 <EE,ME,IR,DR>  CR: 44048444  XER: 00000000
Jun 28 21:59:30 localhost kernel: [  199.925134] DAR: 99A9999D, DSISR: 00000120
Jun 28 21:59:30 localhost kernel: [  199.925140] TASK = d242cd10[4338] 'totem' THREAD: d2576000
Jun 28 21:59:30 localhost kernel: [  199.925144] GPR00: 99A9999D D2577DE0 D242CD10 C0C826A0 00000000 D2577E08 D275F000 D36DC328
Jun 28 21:59:30 localhost kernel: [  199.925158] GPR08: 02000000 00004000 00000000 99A99999 84048444 10054698 00000000 10196A58
Jun 28 21:59:30 localhost kernel: [  199.925172] GPR16: 00000000 00000000 00000000 D36DC328 02000000 329FE000 00000000 00000000
Jun 28 21:59:30 localhost kernel: [  199.925184] GPR24: DE5A6B20 DFA63C80 329FE000 DFA63C80 D20AD804 D275F7F8 D2576000 D2577E08
Jun 28 21:59:30 localhost kernel: [  199.925199] NIP [E226FF44] snd_pcm_mmap_data_nopage+0xa0/0x12c [snd_pcm]
Jun 28 21:59:30 localhost kernel: [  199.925300] LR [E226FF94] snd_pcm_mmap_data_nopage+0xf0/0x12c [snd_pcm]
Jun 28 21:59:30 localhost kernel: [  199.925325] Call Trace:
Jun 28 21:59:30 localhost kernel: [  199.925330] [D2577DE0] [C0010050] update_mmu_cache+0xe4/0xf4 (unreliable)
Jun 28 21:59:30 localhost kernel: [  199.925361] [D2577E00] [C004F1D8] do_no_page+0xa4/0x6a4
Jun 28 21:59:30 localhost kernel: [  199.925387] [D2577E60] [C004FA24] __handle_mm_fault+0x12c/0x328
Jun 28 21:59:30 localhost kernel: [  199.925398] [D2577E90] [C000F740] do_page_fault+0x140/0x384
Jun 28 21:59:30 localhost kernel: [  199.925407] [D2577F40] [C0004AC0] handle_page_fault+0xc/0x80
Jun 28 21:59:30 localhost kernel: [  199.925423] Instruction dump:
Jun 28 21:59:30 localhost kernel: [  199.925427] 812a0218 3d60c038 800b938c 7d292214 3d294000 5529c9f4 7c604a14 80030000
Jun 28 21:59:30 localhost kernel: [  199.925441] 7c6b1b78 70094000 40820044 380b0004 <7d200028> 31290001 7d20012d 40a2fff4

Comments?

Thanks!

Gerhard

-------- Original-Nachricht --------
Datum: Wed, 14 Jun 2006 16:42:48 +0200
Von: Takashi Iwai <tiwai@suse.de>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
Betreff: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

> At Mon, 12 Jun 2006 16:42:54 +0200,
> Gerhard Pircher wrote:
> > 
> > > > But as far as I understand this would require a rewrite of all the
> > > > ALSA drivers (or at least a rewrite of the ALSA's DMA helper
> > > > functions).
> > > 
> > > Yes.  The change of ALSA side has been also on my tree.  But it was
> > > still pending since I'm not satisfied with the design yet.
> > > If you're interested in it, let me know.  I'll post the patch.
> > 
> > Yes, please! Then I can test, if the dma_mmap_coherent() patch works on
> > my non cache coherent powerpc machine.
> 
> For using dma_mmap_coherent(), the patch below should suffice.
> (Also you need to enable HAVE_DMA_MMAP_COHERENT there not only for
>  ARM.)
> 
> > Do you think the DMA Layer/ALSA patches will go upstream in one of
> > the next ALSA/Linux kernel versions? 
> 
> Definitely no 2.6.18 material yet.
> 
> 
> Takashi

-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Takashi Iwai]

At Wed, 28 Jun 2006 22:27:53 +0200,
Gerhard Pircher wrote:
> 
> Hi,
> 
> It took a little bit longer to integrate the patch, as I didn't figure out  first how to implement the __dma_mmap_coherent() function for PPC systems with CONFIG_NOT_COHERENT_CACHE defined. :)
> 
> Unfortunately my system still crashes within snd_pcm_mmap_data_nopage() 
> (sound/core/pcm_native.c), as you can see below. I guess it tries to remap 
> a DMA buffer allocated by the not cache coherent DMA memory allocation 
> function in arch/ppc/kernel/dma-mapping.c.

Strange, nopage will be never called if you apply my patch and modify
to use dma_mmap_coherent().


Takashi

Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Thu, 29 Jun 2006 11:27:15 +0200
Von: Takashi Iwai <tiwai@suse.de>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
Betreff: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

> At Wed, 28 Jun 2006 22:27:53 +0200,
> Gerhard Pircher wrote:
> > 
> > Hi,
> > 
> > It took a little bit longer to integrate the patch, as I didn't figure
> out  first how to implement the __dma_mmap_coherent() function for PPC
> systems with CONFIG_NOT_COHERENT_CACHE defined. :)
> > 
> > Unfortunately my system still crashes within snd_pcm_mmap_data_nopage() 
> > (sound/core/pcm_native.c), as you can see below. I guess it tries to
> remap 
> > a DMA buffer allocated by the not cache coherent DMA memory allocation 
> > function in arch/ppc/kernel/dma-mapping.c.
> 
> Strange, nopage will be never called if you apply my patch and modify
> to use dma_mmap_coherent().
> 
> 
> Takashi
> 
That's indeed strange! I'm sure that the new code is called by the sound drivers. Should snd_pcm_mmap_data_nopage() not be used at all anymore, or are there any cases that could still trigger a call of snd_pcm_mmap_data_nopage()?

Gerhard

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Takashi Iwai]

At Thu, 29 Jun 2006 23:15:13 +0200,
Gerhard Pircher wrote:
> 
> 
> -------- Original-Nachricht --------
> Datum: Thu, 29 Jun 2006 11:27:15 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Betreff: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
> 
> > At Wed, 28 Jun 2006 22:27:53 +0200,
> > Gerhard Pircher wrote:
> > > 
> > > Hi,
> > > 
> > > It took a little bit longer to integrate the patch, as I didn't figure
> > out  first how to implement the __dma_mmap_coherent() function for PPC
> > systems with CONFIG_NOT_COHERENT_CACHE defined. :)
> > > 
> > > Unfortunately my system still crashes within snd_pcm_mmap_data_nopage() 
> > > (sound/core/pcm_native.c), as you can see below. I guess it tries to
> > remap 
> > > a DMA buffer allocated by the not cache coherent DMA memory allocation 
> > > function in arch/ppc/kernel/dma-mapping.c.
> > 
> > Strange, nopage will be never called if you apply my patch and modify
> > to use dma_mmap_coherent().
> > 
> > 
> > Takashi
> > 
> That's indeed strange! I'm sure that the new code is called by the
> sound drivers. Should snd_pcm_mmap_data_nopage() not be used at all
> anymore, or are there any cases that could still trigger a call of
> snd_pcm_mmap_data_nopage()? 

What is the type of buffer are you using?  If it's a buffer
pre-allocated via snd_pcm_lib_preallocate*() with SNDRV_DMA_TYPE_DEV,
there should be no snd_pcm_mmap_data_nopage call.  For other types,
there can be.  For example, the patch still doesn't solve the problems
with drivers using sg-buffer.


Takashi

Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Fri, 30 Jun 2006 11:12:00 +0200
Von: Takashi Iwai <tiwai@suse.de>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
Betreff: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
> 
> What is the type of buffer are you using?  If it's a buffer
> pre-allocated via snd_pcm_lib_preallocate*() with SNDRV_DMA_TYPE_DEV,
> there should be no snd_pcm_mmap_data_nopage call.  For other types,
> there can be.  For example, the patch still doesn't solve the problems
> with drivers using sg-buffer.
> 
I added a debug output and it shows a buffer of SNDRV_DMA_TYPE_DEV_SG type. Well, then I'll hack the kernel to use the normal DMA allocation functions for ALSA instead of the non cache coherent ones and will wait until the ALSA core has been adapted for dma_mmap_coherent().

Or what would have to be done to get it working for SG buffers?

Thanks!

Gerhard

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

[RFC] Porting AmigaOne platform code from ppc to powerpc

[Gerhard Pircher]

Hi!

I'm working on the AmigaOne Linux kernel port. The AmigaOne is a G3/G4 desktop system and makes use of U-boot v1.1.0 as firmware. I intend to port the current code base of this platform to the powerpc architecture, but I'm not sure how to address this.

The "problem" is the device tree required by the powerpc architecture. The AmigaOne's U-boot version doesn't support the flattened device tree yet and also requires a special flash rom programmer tool (I guess it adds some sort of dongle code to the flash rom content). Otherwise users won't be able to boot AmigaOS4. Thus using a newer U-boot version is not really an option and AFAIK the OS4 developers are not going to update their U-boot version.

Well, some time ago I read about a CUIMAGE target that can be used to get powerpc-arch kernels working on old U-boot versions by using a precompiled/static device tree. I don't think that this approch makes sense for a desktop platform, which uses different CPUs (750FX, 750GX, 7410, 7450, 7455, etc..), PCI/AGP cards, etc.

Any advice for me in this case?

Regards,

Gerhard
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

Re: [RFC] Porting AmigaOne platform code from ppc to powerpc

[Benjamin Herrenschmidt]

On Thu, 2006-10-19 at 15:24 +0200, Gerhard Pircher wrote:
> Hi!
> 
> I'm working on the AmigaOne Linux kernel port. The AmigaOne is a G3/G4 desktop system and makes use of U-boot v1.1.0 as firmware. I intend to port the current code base of this platform to the powerpc architecture, but I'm not sure how to address this.
> 
> The "problem" is the device tree required by the powerpc architecture. The AmigaOne's U-boot version doesn't support the flattened device tree yet and also requires a special flash rom programmer tool (I guess it adds some sort of dongle code to the flash rom content). Otherwise users won't be able to boot AmigaOS4. Thus using a newer U-boot version is not really an option and AFAIK the OS4 developers are not going to update their U-boot version.
> 
> Well, some time ago I read about a CUIMAGE target that can be used to get powerpc-arch kernels working on old U-boot versions by using a precompiled/static device tree. I don't think that this approch makes sense for a desktop platform, which uses different CPUs (750FX, 750GX, 7410, 7450, 7455, etc..), PCI/AGP cards, etc.
> 
> Any advice for me in this case?

You can also look at the rework being done currently on zImage wrappers.
Among others, they have the ability to embed a device-tree.

Ben.

Crash with highmem support enabled

[Gerhard Pircher]

Hi,

I'm trying to get highmem support working on my AmigaOne. The machine is equipped with 1.5G RAM. Unfortunately the kernel crashes early in the boot process, so I couldn't save the crash log. But it seems to crash during the initialization of the radeonfb driver.

I guess this has something to do with the IO block mapping, which is implemented in the amigaone_setup.c file and looks like this:

{
/* Remap ISA/PCI IO space first to get it mapped by BATs. */
io_block_mapping(0xfe000000, 0xfe000000, 0x01000000, _PAGE_IO);
/* Remap ISA memory for framebuffer (U-boot framebuffer). */
io_block_mapping(0xfd000000, 0xfd000000, 0x01000000, _PAGE_IO);
/* Remap PROM I/O space to 0xfc000000, to get a window for non
 * cache coherent DMA support at 0xff100000.
 */
io_block_mapping(0xfc000000, 0xff000000, 0x01000000, _PAGE_IO);
}

The addresses below 0xfc000000 belong to the PCI memory space (0x80000000-0xfbffffff).

Thus I moved the highmem base to 0xfc000000, since the PCI memory is not ioremap'd. But the kernel still crashes.

Can somebody give me a hint how to get highmem working? I'm not sure what the real problem is, as also other platforms (PReP, sandpoint) ioremap the address space from 0xfe000000 to 0xffffffff.

Gerhard

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: Crash with highmem support enabled

[Paul Mackerras]

Gerhard Pircher writes:

> I guess this has something to do with the IO block mapping, which is
> implemented in the amigaone_setup.c file and looks like this:

Why on earth are you still using io_block_mapping?

Paul.

Re: Crash with highmem support enabled

[Gerhard Pircher]

-------- Original-Nachricht --------
Datum: Wed, 25 Oct 2006 15:34:50 +1000
Von: Paul Mackerras <paulus@samba.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
Betreff: Re: Crash with highmem support enabled

> Gerhard Pircher writes:
> 
> > I guess this has something to do with the IO block mapping, which is
> > implemented in the amigaone_setup.c file and looks like this:
> 
> Why on earth are you still using io_block_mapping?

What should be used instead? ioremap()? The io_block_mapping() code was copied over from the PReP platform code in arch/ppc/platforms/.

In the meantime I found out that highmem failed due to the IO block mapping (sometimes it is good to look at the code ;). The mapping is needed for the AmigaOne/U-boot framebuffer to be able to access the ISA memory and I/O. Where and when can I savely remap (no 1:1 remapping) the ISA space so that the framebuffer survives the MMU initialization?

thanks!

Gerhard

-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl