From: Takashi Iwai <tiwai@suse.de>
To: ritsch@iem.at
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Scatter-Gather buffer allocation before running on HDSP-MADI ?
Date: Mon, 06 Oct 2003 19:38:06 +0200 [thread overview]
Message-ID: <s5hvfr2mflt.wl@alsa2.suse.de> (raw)
In-Reply-To: <1065460748.3f81a40c61063@iem.at>
At Mon, 06 Oct 2003 19:19:08 +0200 (CEST),
ritsch@iem.at wrote:
>
> Thanx that cleared a lot.
>
> I thought so,
>
> since I want to allocate once and then leave it, (because I dont want an exlusiv
> use of capture and playback ...)
>
> Please three more questions:
>
> 1) I found also the function:
>
> snd_malloc_sgbuf_pages(hdspm->pci, wanted, dmab)
>
> Can I allocate memory with these before initializing a substream and
> write it to hardware and then set all the buffer data in the
> substream:
>
> runtime->dma_area = hdspm->p_dmab.area;
> runtime->dma_addr = hdspm->p_dmab.addr;
> runtime->dma_private = hdspm->p_dmab.private_data;
> runtime->dma_bytes = hdspm->p_dmab.bytes;
>
> Do I miss something ?
the above is doable, but the preallocation mechanism is exactly what
you want here. i'd recommend to simply pre-allocate the buffers and
use snd_pcm_lib_malloc_pages() and snd_pcm_lib_free_pages() in
hw_params and hw_free callbacks.
>
> 2) If SG_BUF makes continous virtual buffer
>
> why there is a
>
> .pages=snd_pcm_sgbuf_ops_page
^^^^^^
.page (without 's')
>
> function needed ?
> what is the purpose of this ?
this is mandatory to handle nopage callback in the mmap.
check pcm_native.c.
> 3) Just for my understanding:
>
> SG allocates scattered physical memory and maps it to
> continous virtual:
>
> when I allocate via
>
> snd_malloc_sgbuf_pages(hdspm->pci, wanted, dmab)
>
> I test the memory so get a syslog:
>
> hdspm.c:2788: Preallocated 8192 kBytes
> hdspm.c:2831: dmab(d27b7a84): area=e2db1000, addr=0, bytes = 0 (wanted 4194304),
> private=ce4a25c0
>
> hdspm.c:2834: area Start: e2db1000 End:e31b0ffc diff=4194300
> hdspm.c:2839: phys Start: b65b000 End:f6acffc diff=-67444732
> hdspm.c:2845: bus_to_virt Start: cb65b000 End:cf6acffc diff=-67444732
>
> (src of this see at the end)
>
>
> Which tells me
> - virt is ok 4194304
> - phys is scattered so also any diff number is ok.
> - but bus_to_virt of physical adress should make a continous, but it doesnt - Why ?
you cannot calculate the virtual address from the physical address
uniquely. a physical page can be mapped to different multiple virtual
pages. (the ALSA's sg-buffer handler uses the vmap() for the virtual
areas, btw.)
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
next prev parent reply other threads:[~2003-10-06 17:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-04 16:15 Scatter-Gather buffer allocation before running on HDSP-MADI ? Winfried Ritsch
2003-10-05 19:01 ` Jaroslav Kysela
2003-10-06 13:50 ` Takashi Iwai
2003-10-06 17:19 ` ritsch
2003-10-06 17:38 ` Takashi Iwai [this message]
2003-10-07 16:25 ` Winfried Ritsch
2003-10-07 16:43 ` Takashi Iwai
[not found] ` <1065776616.3f8675e8b202e@iem.at>
2003-10-10 11:39 ` Takashi Iwai
2003-10-10 11:57 ` Jaroslav Kysela
2003-10-10 12:06 ` Takashi Iwai
2003-10-10 12:15 ` Jaroslav Kysela
2003-10-10 15:23 ` Winfried Ritsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hvfr2mflt.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=ritsch@iem.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox