At Thu, 14 Jun 2007 17:47:58 -0500,
Timur Tabi wrote:
>
> The snd_pcm_substream structure has a snd_dma_buffer structure. snd_dma_buffer looks like
> this:
>
> struct snd_dma_buffer {
> struct snd_dma_device dev; /* device type */
> unsigned char *area; /* virtual pointer */
> dma_addr_t addr; /* physical address */
> size_t bytes; /* buffer size in bytes */
> void *private_data; /* private for allocator; don't touch */
> };
>
> snd_pcm_substream also has a snd_pcm_runtime structure, which looks like this:
>
> struct snd_pcm_runtime {
> ...
>
> /* -- DMA -- */
> unsigned char *dma_area; /* DMA area */
> dma_addr_t dma_addr; /* physical bus address (not accessible from main CPU) */
> size_t dma_bytes; /* size of DMA area */
>
> struct snd_dma_buffer *dma_buffer_p; /* allocated buffer */
>
>
> Why the redundancy? Not only does snd_pcm_runtime have dma_area, dma_addr, and dma_bytes,
> but it also has a pointer to a dns_dma_buffer structure, which also has this information!
>
> So given a snd_pcm_substream structure, you can obtain the physical address of the DMA
> buffer three ways:
>
> substream->dma_buffer.addr
> substream->runtime->dma_addr
> substream->runtime->dma_buffer_p->addr
Some historical reasons. The struct snd_dma_buffer was introduced
much later than the definition of struct snd_pcm. Since many drivers
and core parts use runtime->dma_addr and runtime->dma_area, it was
easier to copy the struct dma_buffer members.
> When will these three variable contain different values? If the answer is never, then why
> do they all exist?
substream->dma_buffer is _not_ mandatory to be filled. It's a
field to keep the buffer pool (buffer pre-allocation) information.
But this area isn't necessarily to be the buffer actually used. When
a bigger buffer is required, the PCM core may allocate it dynamically
(and thus runtime->dma_addr points to a different address than
pre-allocated area).
Also, some drivers don't need buffer pre-allocation but rather have
fixed buffers. In such a case, substream->dma_buffer is
uninitialized, and dma_buffer_p is also NULL.
Hence, referring substream->dma_buffer from the driver is wrong in
general. Ditto for runtime->dma_buffer_p. Don't touch / look at them
in the driver code. The driver code needs to take care of only
runtime->dma_addr and runtime->dma_area if needed.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
