[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c384c5ea0906031432x2675c5a4xcc940a567ca408b8@mail.gmail.com>
Date: Wed, 3 Jun 2009 23:32:56 +0200
From: Leon Woestenberg <leon.woestenberg@...il.com>
To: Steve Rottinger <steve@...tek.com>
Cc: Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org
Subject: Re: splice methods in character device driver
Hello all,
On Wed, May 13, 2009 at 6:59 PM, Steve Rottinger <steve@...tek.com> wrote:
> is passing in the pages into splice_to_pipe. The pages are associated
> with a PCI BAR, not main memory. I'm wondering if this could be a problem?
>
Good question; my newbie answer would be the pages need to be mapped
in kernel space.
I have a similar use case but with memory being DMA'd to host main
memory (instead of the data sitting in your PCI device) in a character
device driver. The driver is a complete rewrite from scratch from
what's currently sitting-butt-ugly in staging/altpcichdma.c
so-please-don't-look-there.
I have already implemented zero-latency overlapping transfers in the
DMA engine (i.e. it never sits idle if async I/O is performed through
threads), now it would be really cool to add zero-copy.
What is it my driver is expected to do?
.splice_read:
- Allocate a bunch of single pages
- Create a scatter-gather list
- "stuff the data pages in question into a struct page *pages[]." a la
"fs/splice.c:vmsplice_to_pipe()"
- Start the DMA from the device to the pages (i.e. the transfer)
- Return.
.splice_write:
- Create a scatter-gather list
interrupt handler / DMA service routine:
- device book keeping
- wake_up_interruptible(transfer_queue)
.confirm():
"then you need to provide a suitable ->confirm() hook that can wait on
this IO to complete if needed."
- wait_on_event_interruptibe(transfer_queue)
.release():
- release the pages
.steal():
unsure
.map
unsure
Regards,
--
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists