RE: [Alsa-devel] Dma query
hi, Any insights will be really helpful :) . regards -kshitij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gupta, Kshitij Sent: Wednesday, February 25, 2004 4:59 PM To: 'Jaroslav Kysela' Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] Dma query hi , That's correct the pages will be in whole meory space and I will be using snd_pcm_lib_preallocate_pages_for_all api for allocating the space. There are some DMA apis (for our dma framework) like set_dma_transfer_params(srcaddr, destaddr, mode ...) Now I need to call this API whenever the transmit for one of the buffers is complete. Or is it like, these things should be done just once upfront. But that means we need n channels if we want n buffers to be ring buffers. regards -kshitij -Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 4:05 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Dma query On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). DMA buffer is allocated hw_params callback. It depends, how the DMA pages have to be allocated. You didn't write any details. If pages can be in the whole memory space (from the view of CPU and DMA controller), then we have SNDRV_DMA_TYPE_CONTINUOUS for it (use snd_pcm_lib_preallocate_pages_for_all at init and standard functions like in other drivers in hw_params and hw_free callbacks). Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
On Thu, 26 Feb 2004, Gupta, Kshitij wrote: hi , That's correct the pages will be in whole meory space and I will be using snd_pcm_lib_preallocate_pages_for_all api for allocating the space. There are some DMA apis (for our dma framework) like set_dma_transfer_params(srcaddr, destaddr, mode ...) Now I need to call this API whenever the transmit for one of the buffers is complete. Or is it like, these things should be done just once upfront. But that means we need n channels if we want n buffers to be ring buffers. The ALSA midlevel expects if trigger callback is called, then the data starts the transfer from the allocated ring buffer (which is filled by the ALSA midlevel code or application - mmap mode). It's not necessary that ring buffer is continous from the physical memory perspective, but it must be continuous from the user space perspective (using MMU and page mapping). Then after one period transfer is finished, you need to call period_elapsed() callback from the interrupt to notify ALSA midlevel code about this situation and continue with the DMA transfer (next period). Note that the pointer callback must give the actual pointer in the ring buffer at this point. I hope this helps. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
Hi, So does that mean that the __next period__ DMA transfer parameters should be set in the interrupt routine(end of transfer of one period). But to set the next DMA transfer params we must know the start address of the buffer which the middle layer has filled (and if the middle layer has filled up more than one buffers then this buffer should be at the head of the list). Also one more point is that the hardware provides us the mechanism of linking the DMA channels ( linking means that once one dma channel finishes the transfer other one starts automatically). So this feature provides us the facility of queuing up the DMA transfers. regards -kshitij ps: one more nasty question I wanted to ask on the list was about how much time does it take to write a driver(from scratch) with such a complex framework ;)...probably just sharing experiences regards -kshitij -Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 4:57 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] Dma query On Thu, 26 Feb 2004, Gupta, Kshitij wrote: hi , That's correct the pages will be in whole meory space and I will be using snd_pcm_lib_preallocate_pages_for_all api for allocating the space. There are some DMA apis (for our dma framework) like set_dma_transfer_params(srcaddr, destaddr, mode ...) Now I need to call this API whenever the transmit for one of the buffers is complete. Or is it like, these things should be done just once upfront. But that means we need n channels if we want n buffers to be ring buffers. The ALSA midlevel expects if trigger callback is called, then the data starts the transfer from the allocated ring buffer (which is filled by the ALSA midlevel code or application - mmap mode). It's not necessary that ring buffer is continous from the physical memory perspective, but it must be continuous from the user space perspective (using MMU and page mapping). Then after one period transfer is finished, you need to call period_elapsed() callback from the interrupt to notify ALSA midlevel code about this situation and continue with the DMA transfer (next period). Note that the pointer callback must give the actual pointer in the ring buffer at this point. I hope this helps. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
On Thu, 26 Feb 2004, Gupta, Kshitij wrote: Hi, So does that mean that the __next period__ DMA transfer parameters should be set in the interrupt routine(end of transfer of one period). But to set the next DMA transfer params we must know the start address of the buffer which the middle layer has filled (and if the middle layer has filled up more than one buffers then this buffer should be at the head of the list). Also one more point is that the hardware provides us the mechanism of linking the DMA channels ( linking means that once one dma channel finishes the transfer other one starts automatically). So this feature provides us the facility of queuing up the DMA transfers. regards -kshitij Basically, we only copy the soundcard hardware and old ISA DMA engine which is same as for PCI hardware etc. The buffer size is divided to subblocks (we call them periods). These periods determine spaces between interrupts and it's not necessary that buffer_size == period_size * N (where N is an integer). Some hardware (like ISA DMA controllers) can do any period sizes. So, simply program your DMA controller to runtime-dma_addr + offset for actual period and next periods. If you allow to set any period size, then you need also handle shifts (you can avoid this by settings snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS)) ). ps: one more nasty question I wanted to ask on the list was about how much time does it take to write a driver(from scratch) with such a complex framework ;)...probably just sharing experiences One week with full debugging. And I don't think that coding drivers is complex, but it's required to know what's going on in the midlevel code and you need to know the Linux kernel side memory handling. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Dma query
On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). DMA buffer is allocated hw_params callback. It depends, how the DMA pages have to be allocated. You didn't write any details. If pages can be in the whole memory space (from the view of CPU and DMA controller), then we have SNDRV_DMA_TYPE_CONTINUOUS for it (use snd_pcm_lib_preallocate_pages_for_all at init and standard functions like in other drivers in hw_params and hw_free callbacks). Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Dma query
On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). You should do most of the hw setup in the .hw_params callback. You get pointers to the substream and hw_params structures and you have to setup the hw and the buffer as requested. These macros may be useful params_period_bytes(), params_buffer_bytes(), snd_pcm_substream_sgbuf(), snd_sgbuf_get_addr(). There are many others, look at the sources :) -- Giuliano. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Dma query
Thanx for the detailslet me just figure out the full flow and then come with some more queries ;)... -Original Message- From: Giuliano Pochini [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 4:23 PM To: Gupta, Kshitij Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] Dma query On Wed, 25 Feb 2004, Gupta, Kshitij wrote: hi, I have a very trivial question about the dma transfers with respect to ALSA framework. Let me first explain a scenario We have a Circularly linked Buffer pool buf1buf2buf3 buf4 bufn In very simple terms playing an audio stream is reading from these buffers and continuously dma'ing it to the audio device (let's assume we have a read and write register with the audio device). And in this circulary linked audio buffer the user fills the data and the driver empties it to the device. Now I am not able to fit this scenario in the ALSA framework. I am referrring to alsa-kernel/arm/sa11xx-uda1341.c file as a reference for my driver. And here I don't understand where do we specify the the exact dma parameters (like the start address of buffer and the destination address). You should do most of the hw setup in the .hw_params callback. You get pointers to the substream and hw_params structures and you have to setup the hw and the buffer as requested. These macros may be useful params_period_bytes(), params_buffer_bytes(), snd_pcm_substream_sgbuf(), snd_sgbuf_get_addr(). There are many others, look at the sources :) -- Giuliano. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
