Subject: Re: Rev 1.19 of busdma.doc
To: None <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 11/09/1996 18:54:36
>From Chris_G_Demetriou@ux2.sp.cs.cmu.edu Sat Nov 9 18:46:25 1996
>> Presumably the return value is in units that can get
>> plugged into a DMA engine, right? If so, then you'd
>> better make this a quad_t (to allow for physical addresses
>> for large systems to get passed).
>The return value is a mapped KVA which is at least the specified
>'size' number of bytes in length.
>It can be mapped by (whatever the mapping function is called today)
>with the properties requested by the arguments.
So, you cannot perform DMA on memory you can't get a KVA to then.
Spock to Captain: Is this wise? :-)
I can think of many reasons for and devices that move data where
a KVA is neither easy (or even possible) or desirable. Also, for
performance reasons it would nice in some architectures to
move data around where there *is* no cpu mapping of the buffer,
or you don't have to tie down the mappings (the frame grabber
is one case that comes to mind...)
Case in point: I do the I/O hose support on the Alpha. This means
that every data movement will have to go onto the turbolaser
bus to memory- it cannot simply be routed from one PCI card
Well- Hmm.. maybe I'm putting my old Sun hat on here, and should
just leave it be- If I run into this kind of case in actuality, I'll
bring up the issue again.