Then comes the kernel. :( I started looking that the ILOAD code in mga_state.c. Basically, it looks like everything assume the source buffers are in AGP space. I'm guessing that I could just look at the flags field in the drm_device_dma structure and only set the MGA_SRCACC_AGP bit if _DRM_DMA_USE_AGP bit is set. Is _DRM_DMA_USE_SG *always* set for PCI DMA transfers? I don't want to exclude the possability of sourcing vertex data from on-card memory in the future.
In the DRM, if there's no AGP available, then PCI memory has to be used for DMA. It looks like the setup for that happens in the DDX driver in MGADRIAgpInit (in mga_dri.c). In looking at that routine, it's not immediatly clear what to do. Obviously, DRM_AGP wouldn't be passed to any of the drmAddMap calls. Looking at radeon_dri.c, it looks like RADEONPciInit is the same as RADEONDRIAgpInit except it uses DRM_SCATTER_GATHER instead of DRM_AGP and drmScatterGatherAlloc instead of drmAgpAcquire / drmAgpAlloc / drmAgpBind. Is that right?
If the card has non PCI GART (like ATIs have), you can probably still use the machine's IOMMU to perform like an AGP GART, that is create a mapping of scattered memory pages that is shown as contiguous for your card.
The current PCI interface to the iommu doesn't allow you to explicitely ask an sg list to be force-merged into a single segment though that could be added via some platform hooks. That would probably work if that is the only DMA allocation you do on this TCE table. Those machines have a TCE table per PCI brigde and one bridge per slot, no ?
You lost me at "PCI interface". :) I don't currently know very much about POWER at all, so you're going to have to bear with me a bit. As far as I can tell, the PCI bridge on the card doesn't do anything except convert regular PCI voltage to AGP voltage. I'm not at all familiar with the TCE table, but it sounds like a more general version of an AGP GART table. Is that a fair assessment?
From skimming the kernel source briefly, it looks like this is only supported on PPC64. Is that correct? If so, it sounds like something PPC64-specific could be done to keep the performance up, but I think I want to do something more general as well. I see no reason to exclude support for PCI cards on x86, for example. I now understand why some IHVs have complained that Linux can't allocate large (i.e., more than a page) of physically contiguous memory. Of course, I've always understood why it doesn't. (And never will! Muhahaha!) :)
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
