1. code modifies data in block and this modification ends up in
cache and is not written back to memory
2. right after this code calls bus_dmamap_sync for this buffer
and as a result cache invalidation is performed
3. Cache function operates on cache line
Hi everyone,
It seems like there are starting to be some drivers that need to
allocate large chunks of DMA-able memory, and since bus_dmamem_alloc()
on most architectures is always physically contiguous, it may not work
for them.
It seems like we could use the new sglist routines to help us
On Wednesday 11 June 2008, John-Mark Gurney wrote:
Why not use the SRAM for this? That's what my driver does... w/ 32k
SRAM, it's more than enough for more programs...
The DMA programs (or at least a significant chunk of them) will get stored in
the SRAM, if there's enough room. That's
Hello,
I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards.
Of course the driver uses busdma to be as machine-independent as possible.
One problem I've encountered is that bus_dmamem_alloc is inadequate for my
needs. The CX2388x only understands 32-bit physical
On Monday 24 October 2005 11:27, Søren Schmidt wrote:
On 24/10/2005, at 3:49, Jason Harmening wrote:
Hi,
I have a 2.3G Fujitsu MO drive, and I've gotten tired of using
atapicam to
access it. I'm thinking of writing a native ATAPI driver that
could be added
to the kernel through
(or floppies or tape drives for that matter).
Also, beyond the capabilities page, are there any other special considerations
I'd need to make for an MO driver?
Any answers would be really awesome.
Thanks,
Jason Harmening
___
freebsd-hackers@freebsd.org
6 matches
Mail list logo
