Takashi Iwai wrote: > At Tue, 19 Dec 2006 10:12:54 -0500, > David Cullen wrote: >> In alsa-driver-1.0.13/acore/memalloc.c there is this section of code >> >> /* >> * Hacks >> */ >> >> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0) >> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5) >> >> I am using a patched 2.6.13 kernel. Should I change that last line >> to be KERNEL_VERSION(2, 6, 13)? > > That part is a workaround only for the old 2.6 kernels which cause > Oops when NULL is passed to device pointer. So, it should be > irrelevant. > OK. After more closely examining that code, I see that for my kernel, this code is used #else /* for 2.2/2.4 kernels */ #if defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(__i386__) #define dma_alloc_coherent(dev,size,addr,flags) pci_alloc_consistent((struct pci_dev *)(dev),size,addr) #define dma_free_coherent(dev,size,ptr,addr) pci_free_consistent((struct pci_dev *)(dev),size,ptr,addr) #elif CONFIG_SBUS #define dma_alloc_coherent(dev,size,addr,flags) sbus_alloc_consistent((struct sbus_dev *)(dev),size,addr) #define dma_free_coherent(dev,size,ptr,addr) sbus_free_consistent((struct sbus_dev *)(dev),size,ptr,addr) #else #error "Need a bus for dma_alloc_coherent()" #endif Which means pci_alloc_consistent is called instead of __dma_alloc_coherent. >> Also, could you give me some pointers regarding my previous e-mails >> regarding this issue: >> >> Takashi Iwai wrote: >> > At Mon, 27 Nov 2006 17:01:52 -0500, >> > David Cullen wrote: >> >> >> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC >> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI >> >> card. I am using a patched 2.6.13 kernel that comes with the >> >> board. I built the kernel with the sound core built in and I >> >> used the cross-compiler tools to build the ALSA driver, library, >> >> and utils. When I run "speaker-test", it crashes in the ALSA >> >> library. The problem is that the call to mmap in >> >> >> >> alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367 >> >> >> >> which looks like >> >> >> >> ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, >> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset); >> >> >> >> returns a pointer that appears to be valid (0x3001E000) but >> >> causes a kernel OOPS when accessed. >> >> >> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both >> >> succeed, and the pointers returned can be successfully accessed, >> >> but they use the status and control offsets as parameters to >> >> mmap. >> >> >> >> I haved traced the problem on the target into the ALSA library >> >> using gdb and into the kernel using kgdb and everything looks >> >> like it works properly. If I disable the semaphore acquisition >> >> in do_mmap2, I can print the contents of the address in kgdb >> >> using >> >> >> >> (gdb) print ((char *)vma->vm_start)[0] >> >> >> >> after the call to vm_link in do_mmap_pgoff. However, the board >> >> locks up after the print command. >> >> >> >> Anyone have any experience with this type of problem on PowerPC >> >> systems? >> > >> > Possibly a memory coherency problem. The memory allocated via >> > dma_alloc_coherent() isn't simply mmappable. >> > >> > An essential fix would be to add dma_mmap_coherent() to all >> > architectures and use it for ALSA mmap. I made some patches quite >> > ago, but left it rotten for the time being... >> > >> >> How do I "add dma_mmap_coherent() to all architectures and use it >> for ALSA mmap"? > > Well, for that, we need to patch the kernel itself and add > dma_mmap_coherent() call. The problem is that the memory returned > from dma_alloc_coherent() isn't the address of the really allocated > pages in your case. Since the ALSA mmap mode obtains the page via > virt_to_page(), this doesn't work. Thus, a new function, > dma_mmap_coherent() is required to calculate the real page address and > do the rest of low-level mmap jobs. Where would dma_mmap_coherent be placed? Which specific file? Would I replace all calls to mmap with dma_mmap_coherent? I can probably figure out how to implement it if you can give me an example for another architecture. I tried looking at old patches on the web, but I had difficulty understanding them. I think they were for the ARM architecture. > A simple solution would be simply disable mmap. > In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and > SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and > snd_ca0106_capture_hw structs. > > Also, disable #if defined(CONFIG_PPC) around > snd_pcm_mmap_status_*() in core/pcm_native.c. > > This will reduce the sound system functionality (e.g. no dmix is > available), though. At this point, if we can get speaker-test to work, we will be happy. So dmix is not necessary (I believe...). However, I do not know the complete details of the end user's application, so dmix may be needed eventually. If you can give me a few pointers on how to implement dma_mmap_coherent and sew it into ALSA, that would really help. > BTW, any chance to try a newer version of kernel? > I don't want to debug the issues of old kernels but rather fix the > latest kernel... Unfortunately, we're stuck with the 2.6.13 kernel. We are working with the AMCC Taihu evaluation board, and the kernel source that comes with it has been heavily patched to work with that board. Upgrading the patches to work with a newer kernel is outside the scope of what we agreed to do. If you cannot help us as long as we use the older kernel, I will pass along the information to my manager. -- Thank you, David Cullen Teligy ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
