lkml.org 
[lkml]   [2001]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [UPDATE] 2.4.10-pre2 PCI64, API changes README
Date
David S. Miller wrote:
>
> Ok, new patch up on kernel.org against 2.4.10-pre2:
>
> ftp.kernel.org:/pub/linux/kernel/davem/PCI64/pci64-2.4.10p2-1.patch.gz
>
> The major change in this release is that the API has been redone.

A maybe related issue:

My current bttv does zerocopy capture if you ask it for a video frame
using read(): locks memory with kiobufs, builds a scatterlist for the
locked pages, asks for bus addresses using pci_map_sg, then kick DMA.

These days I tried what happens if I start a PCI->PCI transfer this way:
Open the framebuffer device, mmap the framebuffer memory, then ask bttv
to blit one video frame to the framebuffer by passing the pointer of the
fb mapping to bttv's read() function.

Didn't work, looks like map_user_buf can deal with main memory only, but
not with I/O memory. It gave me NULL pointers in the iobuf page list.

Is there any way (portable) way to deal with this situation? I'd expect
I can get the physical address for the I/O memory by walking the page
tables, but then I'd have to translate that to a bus address somehow.
How PCI->PCI transfers are handled on architectures with a iommu? Do I
need a iommu entry for them?

Gerd

--
Damn lot people confuse usability and eye-candy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:01    [W:0.075 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site