--- Ian Romanick <[EMAIL PROTECTED]> wrote: > Ville Syrjälä wrote: > > On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote: > > > >>I must say that I am very impressed with how far the MGA driver has > come > >>since you started working on it. Now the only thing that's missing > is > >>support for PCI cards. ;) > > > > A quick fix would be simply enabling PCI cards but keep the agpgart > > restriction. The only change required would be changing the access > type to > > PCI in the DMA registers. I think it should work but I don't have a > PCI > > card to test with so I can't be 100% sure. > > So, I've now been tasked to actually do this. I get to enable > support > for a G450 PCI card that IBM ships in some of its POWER based > systems. > So, not only is it PCI & PPC64, but there is *no* AGP available at > all. > I haven't started actually changing any code as I don't have the > hardware yet, but it's on the way. > > I want to initially support this by just "disabling" AGP texturing. > I > looked in the DRI driver, and it looks like this can be done with > some > trivial changes in mga_xmesa.c. Basically, the code just needs to > handle the case where serverInfo->agpTextureSize is 0. The DDX > driver > needs to be modified to detect PCI cards and do something smart > there. > I haven't looked in that code yet, but I'm guess it should be pretty > trivial. > > 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? > > MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit > because I don't intend to (initially) support PCIGART. Even when > PCIGART is supported, not all chips in the MGA family support it. Is > > the PCI G450 the only one? > > >
There was a website with support for the PCI G450 (for alpha I think): http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ However it seems to be down at the moment. Someone on the ML knew the guy who was doing the work. perhaps they an find out the state of it. As I recall the G450-PCI cards were just AGP chips with an agp to pci bridge. Perhaps you need to hack up an agpgart driver for the bridge? Also, for the pci g450, matrox only supported 3D on motherboards with intel chipsets for whatever reason. Alex __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com ------------------------------------------------------- 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
