From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Christoph Hellwig <hch@caldera.de>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org, sct@redhat.com
Subject: Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6
Date: Mon, 30 Oct 2000 15:08:31 -0500 [thread overview]
Message-ID: <39FDD53F.5AC31232@mandrakesoft.com> (raw)
In-Reply-To: <20001027222143.A8059@caldera.de> <200010272123.OAA21478@penguin.transmeta.com> <20001030124513.A28667@caldera.de> <39FDAD99.47FA6A54@mandrakesoft.com> <20001030191712.B27664@caldera.de> <39FDC447.C5DD7864@mandrakesoft.com> <20001030204403.A1912@caldera.de>
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
Christoph Hellwig wrote:
>
> On Mon, Oct 30, 2000 at 01:56:07PM -0500, Jeff Garzik wrote:
> > My question from above is: how can the via audio mmap in test10-preXX
> > be improved by using kiobufs? I am not a kiobuf expert, but AFAICS a
> > non-kiobuf implementation is better for audio drivers. (and the via
> > audio mmap implementation is what some other audio drivers are about to
> > start using...)
>
> I think the biggest advantage is that you actually get the list of pages
> when you perform the mmap instead of doing virt_to_page on every ->nopage.
> That should speed up the operations on the mmap'ed are a bit.
nopage() is only called when the page is not mapped for the current
process. So it doesn't get called very often. Easy enough to call
virt_to_page at alloc instead of nopage time, though. Patch attached :)
> The other strong argument for the kiobuf solution is code-sharing. Instead
> of having every (sound) driver playing with the vm, there is one central
> place when you use kvmaps.
Actually, I wonder if its even possible for mmap_kiobuf to support audio
-- full duplex requires that both record and playback buffer(s),
theoretically two separate sets of kiobufs, to be presented as one space
(with playback always presented before record). Even if you can do that
with mmap_kiobuf, some audio hardware doesn't support scatter-gather, so
each set of kiobufs must be physically contiguous for each channel.
<thinks> audio drivers' write(2) should be kiobuf'd, but only for
hardware which supports scatter-gather.
I can't think of any other cases where kiobuf would apply to audio.
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
[-- Attachment #2: via.patch --]
[-- Type: text/plain, Size: 1381 bytes --]
Index: drivers/sound/via82cxxx_audio.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/sound/via82cxxx_audio.c,v
retrieving revision 1.1.1.6.4.1
diff -u -r1.1.1.6.4.1 via82cxxx_audio.c
--- drivers/sound/via82cxxx_audio.c 2000/10/27 08:21:41 1.1.1.6.4.1
+++ drivers/sound/via82cxxx_audio.c 2000/10/30 19:57:21
@@ -226,6 +226,7 @@
struct via_sgd_data {
dma_addr_t handle;
void *cpuaddr;
+ struct page *page;
};
@@ -626,6 +627,7 @@
if (!chan->sgbuf[i].cpuaddr)
goto err_out_nomem;
+ chan->sgbuf[i].page = virt_to_page (chan->sgbuf[i].cpuaddr);
if (i < (VIA_DMA_BUFFERS - 1))
chan->sgtable[i].count = cpu_to_le32 (VIA_DMA_BUF_SIZE | VIA_FLAG);
@@ -722,6 +724,7 @@
chan->sgbuf[i].handle);
chan->sgbuf[i].cpuaddr = NULL;
chan->sgbuf[i].handle = 0;
+ chan->sgbuf[i].page = NULL;
}
if (chan->sgtable) {
@@ -1717,9 +1720,11 @@
} else if (!wr)
chan = &card->ch_in;
+ assert (chan->sgbuf[pgoff].cpuaddr != NULL);
+ assert (chan->sgbuf[pgoff].page != NULL);
assert ((((unsigned long)chan->sgbuf[pgoff].cpuaddr) % PAGE_SIZE) == 0);
- dmapage = virt_to_page (chan->sgbuf[pgoff].cpuaddr);
+ dmapage = chan->sgbuf[pgoff].page;
DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
dmapage, (unsigned long) chan->sgbuf[pgoff].cpuaddr);
get_page (dmapage);
next prev parent reply other threads:[~2000-10-30 20:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-27 20:21 [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6 Christoph Hellwig
[not found] ` <200010272123.OAA21478@penguin.transmeta.com>
2000-10-30 11:45 ` Christoph Hellwig
2000-10-30 17:19 ` Jeff Garzik
2000-10-30 18:17 ` Christoph Hellwig
2000-10-30 18:56 ` Jeff Garzik
2000-10-30 19:44 ` Christoph Hellwig
2000-10-30 20:08 ` Jeff Garzik [this message]
2000-10-30 20:32 ` Christoph Hellwig
2000-10-30 21:51 ` Jeff Garzik
2000-11-01 13:32 ` Stephen C. Tweedie
2000-10-31 2:08 ` Andrea Arcangeli
2000-11-01 11:16 ` Christoph Hellwig
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=39FDD53F.5AC31232@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=hch@caldera.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.com \
/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