On Tuesday 01 February 2005 16:59, Rodolphe Ortalo wrote: > > Personnally, I would suggest: to offer a single simple DMA method, > > probably very simple (start and length or end, nothing more). > > However, I would double check _every_ hardware assumptions that > > could break those of (virtual) memory management in kernels, AGP, > > DRI or software libraries (Mesa?). For example, crossing a page > > boundary is not very affordable if you want to use normal kernel > > virtual memory.
I should mention here that DMA always bypasses virtual memory completely. I should also mention that the days when it was acceptable for DMA hardware to have trouble with physical page boundaries are far behind us. We could possibly be excused for requiring the command DMA to lie within contiguous physical memory. We want the DMA hardware to be capable of addressing 32 bits worth of physical memory or even more. It's a pain to have to worry about whether or not a given physical page is within range of the DMA engine. Virtual memory considerations are handled entirely within the driver. If the DMA hardware is capable of scatter/gather then the driver will use that, but if it's any bother to implement then the driver can take care of breaking up the transfer into as many physically contiguous pieces as necessary. The problem is, a completion interrupt would be needed after each DMA fragment, which is odious. My suggestion here is to send the DMA setup commands through the command ring buffer, that way the card can worry about initiating each successive transfer immediately after the preceding one is finished, and we can dispense with the complexities of scatter-gather. To signal final completion the driver could put an "interrupt me" command in the command buffer, or there could be some logic for generating an interrupt when both DMA is finished and the command buffer is empty. This is a half-formed idea, it obviously has holes in it, but somewhere in there is a nice strategy I think. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
