[Bug 3248] MGA driver fails in unfriendly way on PCI cards
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3248 --- Additional Comments From [EMAIL PROTECTED] 2005-05-09 23:48 --- I've been thinking about this some more. I've decided that I don't like the idea of failing at device open. The problem is that if the MGA DRM is updated to support PCI cards, the device open can't fail. In that case, old versions of the DDX will go back to being broken (i.e., exactly as they are today). After digging a bit deeper, I think a better sollution is to add a device-specific hook in drm_agp_init. At the start of drm_agp_init, dev-driver-agp_preinit(). agp_preinit could then determine if the card was really an AGP card or not. If it's not, it would return false and drm_agp_init would fail. In the case of drivers that require AGP (i.e., the current MGA DRM), this would result in driver failing to initialize. If nothing else, it looks like it should make the drmAgpAcquire call in the DDX fail. That /should/ be good enough for now. In the future, when the DRM and DDX support DRI on PCI cards, the DDX could take a different, non-failure path when drmAgpAcquire fails. I'll code up something in the morning and post a patch. Does this seem like the right approach? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3248] MGA driver fails in unfriendly way on PCI cards
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3248 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #2649 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 07:54 --- Created an attachment (id=2654) -- (https://bugs.freedesktop.org/attachment.cgi?id=2654action=view) Reject PCI G450 cards in drm_agp_init path This patch implements the mechanism that I proposed in my previous post. This patch prevents DRI from begin initialized on PCI G450 with the current DDX even if DRIVER_REQUIRE_AGP is removed from driver_features. This means that old DDX versions will still be fixed even when the DRM is updated to support PCI cards. Unless there are objections, I will commit this on 2005-May-11. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] CFT - broken since merge 21th to 22/23 of April
Textures in gears, ipers, etc. pp.
quake3: black window
/opt/Mesa ut2003_demo
fcntl: Invalid argument
fcntl: Invalid argument
Backtrace:
[ 1] ./Core.so [0x40a0978a]
[ 2] [0xe420]
[ 3] /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_run_pipeline+0x2d)
[0x4505da05]
[ 4] /usr/X11R6/lib/modules/dri/r200_dri.so [0x44fda09f]
[ 5] /usr/X11R6/lib/modules/dri/r200_dri.so [0x450f55e3]
[ 6] /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_DrawRangeElements+0x13d)
[0x450f5a1a]
[ 7] /usr/X11R6/lib/modules/dri/r200_dri.so [0x45057918]
[ 8]
/opt/games/ut2003_demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373)
[0x437ffaeb]
[ 9]
./Engine.so(Render__12FBspDrawListP15FLevelSceneNodeP16FRenderInterface+0x43e)
[0x40357532]
[10] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x229b)
[0x4036aedf]
[11] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2)
[0x4034d38a]
[12] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330)
[0x403524ec]
[13] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x3fe) [0x4028a08a]
[14] /opt/games/ut2003_demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33)
[0x437c093b]
[15] /opt/games/ut2003_demo/System/SDLDrv.so(Tick__10USDLClient+0x85)
[0x437bf365]
[16] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x402912e1]
[17] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d]
[18] ./ut2003-bin(main+0x328c) [0x8058b2c]
[19] /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40bb44a0]
[20] ./ut2003-bin(GetFullName__C7UObjectPw+0x7d) [0x80512d1]
Signal: SIGSEGV [segmentation fault]
Aborting.
Speicherschutzverletzung
/opt/Mesa ut2004demo
Signal: SIGSEGV [segmentation fault]
Aborting.
Crash information will be saved to your logfile.
Developer Backtrace:
Log: [ 1] ./ut2004-bin [0x869e38c]
Log: [ 2] [0xe420]
Log: [ 3] /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_run_pipeline+0x2d
[0x44644a05]
Log: [ 4] /usr/X11R6/lib/modules/dri/r200_dri.so [0x445c109f]
Log: [ 5] /usr/X11R6/lib/modules/dri/r200_dri.so [0x446dc5e3]
Log: [ 6]
/usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_DrawRangeElements+0x13d)
[0x446dca1a]
Log: [ 7] /usr/X11R6/lib/modules/dri/r200_dri.so [0x4463e918]
But quake3-smp, UT2k3/4 didn't even worked with 21th version and before.
-Dieter
diff -r Mesa/src/mesa/tnl/t_array_api.c Mesa-21-04/src/mesa/tnl/t_array_api.c
93a94,96
if (tnl-pipeline.build_state_changes)
_tnl_validate_pipeline( ctx );
104c107,120
tnl-Driver.RunPipeline( ctx );
diff -r Mesa/src/mesa/drivers/dri/r200/r200_tcl.c
Mesa-21-04/src/mesa/drivers/dri/r200/r200_tcl.c
387c387
r200EmitArrays( ctx, tnl-render_inputs );
---
r200EmitArrays( ctx, stage-inputs );
410a411,473
static void r200_check_tcl_render( GLcontext *ctx,
struct tnl_pipeline_stage *stage )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
GLuint inputs = VERT_BIT_POS;
GLuint unit;
/* Validate state:
*/
if (rmesa-NewGLState)
r200ValidateState( ctx );
if (ctx-RenderMode == GL_RENDER) {
/* Make all this event-driven:
*/
if (ctx-Light.Enabled) {
inputs |= VERT_BIT_NORMAL;
if (1 || ctx-Light.ColorMaterialEnabled) {
inputs |= VERT_BIT_COLOR0;
}
}
else {
inputs |= VERT_BIT_COLOR0;
if (ctx-_TriangleCaps DD_SEPARATE_SPECULAR) {
inputs |= VERT_BIT_COLOR1;
}
}
if ( ctx-Fog.FogCoordinateSource == GL_FOG_COORD ) {
inputs |= VERT_BIT_FOG;
}
for (unit = 0 ; unit ctx-Const.MaxTextureUnits; unit++) {
if (ctx-Texture.Unit[unit]._ReallyEnabled) {
if (rmesa-TexGenNeedNormals[unit]) {
inputs |= VERT_BIT_NORMAL;
}
inputs |= VERT_BIT_TEX(unit);
}
}
stage-inputs = inputs;
stage-active = 1;
}
else
stage-active = 0;
}
static void r200_init_tcl_render( GLcontext *ctx,
struct tnl_pipeline_stage *stage )
{
stage-check = r200_check_tcl_render;
stage-check( ctx, stage );
}
static void dtr( struct tnl_pipeline_stage *stage )
{
(void)stage;
}
416,419c479,489
NULL, /* private */
NULL,
NULL,
NULL,
---
(_DD_NEW_SEPARATE_SPECULAR |
_NEW_LIGHT|
_NEW_TEXTURE|
_NEW_FOG|
_NEW_RENDERMODE), /* re-check (new inputs) */
0, /* re-run (always runs) */
GL_TRUE, /* active */
0, 0, /* inputs (set in check_render), outputs */
0, NULL, /* changed_inputs, private */
dtr, /* destructor */
r200_init_tcl_render, /* check - initially set to alloc data */
Binrdateien Mesa/src/mesa/drivers/dri/r200/r200_tcl.o and
Mesa-21-04/src/mesa/drivers/dri/r200/r200_tcl.o sind verschieden.
Binrdateien
[Bug 3248] MGA driver fails in unfriendly way on PCI cards
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3248 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||3259 nThis|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3259] New: MGA: Add support for PCI cards
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3259 Summary: MGA: Add support for PCI cards Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Drivers/DRI/MGA AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] BugsThisDependsOn: 3248 It should be possible, though perhaps with reduced performance, to support PCI G450 and G200 cards. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3263] New: glxgears not updating screen after running for several hours, 915GM h/w
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3263 Summary: glxgears not updating screen after running for several hours, 915GM h/w Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Fedora Core 2, full install X.org 6.8.2, Intel DRI package, Alan's i810_drv.o from April. If I leave glxgears running, it will eventually (12-20 hrs later) stop updating the screen. It is not hung or dead, as it continues to output frame rate to the terminal window and frame rates are not changed. Multiple copies of glxgears running all stop updating at the same time. I have had this on both 915G and 915GM h/w. The X Server itself is fine, I can restart glxgears and it will run normally for another x hrs. I have not tried resizing the glxgears window when it is in this state to see if it starts drawing again, I will try that next. Setting LIBGL_DEBUG to verbose does not output any additional info when the updates stop happening, and system memory seems to be pretty reasonable. If there are any logs, configs, etc that are useful, let me know. Craig -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 3263] New: glxgears not updating screen after running for several hours, 915GM h/w
This is a known bug in glxgears that has been fixed some time ago. Due to limited floating-point precision the gears stopped turning after a fixed number of frames. Philipp --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3263] glxgears not updating screen after running for several hours, 915GM h/w
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3263 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 12:40 --- As per message from dri-devel... This is a known bug in glxgears that has been fixed some time ago. Due to limited floating point precision the gears stopped turning after a fixed number of frames. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3264] New: glxgears not updating screen after running for several hours, 915GM h/w
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3264 Summary: glxgears not updating screen after running for several hours, 915GM h/w Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Fedora Core 2, full install X.org 6.8.2, Intel DRI package, Alan's i810_drv.o from April. If I leave glxgears running, it will eventually (12-20 hrs later) stop updating the screen. It is not hung or dead, as it continues to output frame rate to the terminal window and frame rates are not changed. Multiple copies of glxgears running all stop updating at the same time. I have had this on both 915G and 915GM h/w. The X Server itself is fine, I can restart glxgears and it will run normally for another x hrs. I have not tried resizing the glxgears window when it is in this state to see if it starts drawing again, I will try that next. Setting LIBGL_DEBUG to verbose does not output any additional info when the updates stop happening, and system memory seems to be pretty reasonable. If there are any logs, configs, etc that are useful, let me know. Craig -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3263] glxgears not updating screen after running for several hours, 915GM h/w
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3263 --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 13:12 --- *** Bug 3264 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3264] glxgears not updating screen after running for several hours, 915GM h/w
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3264 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 13:12 --- *** This bug has been marked as a duplicate of 3263 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Getting DRI working on PCI MGA cards
I've started working to get PCI MGA cards, the PCI G450 specifically,
working with DRI. My initial goal is to just get it working with crummy
performance, then improve it by adding support for IOMMUs (to simulate
AGP texturing) on systems like pSeries and AMD64 that have them.
I've started by digging through the DRI init process in the X.org MGA
DDX. As near as I can tell, the driver uses AGP memory for four things.
To make the PCI cards work, I'll need to make it do without AGP for
these things.
1. WARP microcode. This seems *really* odd to me. The DDX carves off a
32KiB chunk of AGP space and gives it to the kernel to use to store the
WARP microcode. Why is the DDX involved in this *at all*? The
microcode exists only in the kernel module. It seems that the DRM could
just as easily drm_pci_alloc a chunk of memory large enough to hold the
microcode for the card (which is different for G400-class cards and
G200-class cards).
2. Primary DMA buffer. The DDX carves of 1MB for the primary DMA
buffer. I don't think that's outside the reasonable realm for
drm_pci_alloc. If it is, can this work with a smaller buffer?
3. Secondary DMA buffers. The DDX carves off room for 128 64KiB DMA
buffers. I haven't dug that deeply, but I seem to recall that the DRI
driver uses these buffers as non-contiguous. That is, it treats them as
128 separate buffers and not a big 8MB buffer that it cards 64KiB chunks
from. If that's the case, then it should be easy enough to modify the
driver the drm_pci_alloc (upto) 128 64KiB chunks for PCI cards. Is
there any actual performance benefit to having this be in AGP space at
all or do they just have to be in the same address space as the
primary DMA buffer?
4. AGP textures. Without an IOMMU, we pretty much have to punt here.
Performance will be bad, but I can live with that.
If these assumptions are at least /mostly/ correct, I think I have a
pretty good idea how I'll change the init process around. I'd like to,
basically, pull most of MGADRIAgpInit into the kernel. There will be a
single device-specific command called something like
DRM_MGA_DMA_BOOTSTRAP. The DDX will pass in the desired AGP mode and
size. The DRM will do some magic and fill in the rest of the structure.
The structure used will probably look something like below. Notice
that the DDX *never* needs to know anything about the WARP microcode in
this arrangement.
struct drm_mga_dma_bootstrap {
/**
* 1MB region of primary DMA space. This is AGP space if
* \c agp_mode is non-zero and PCI space otherwise.
*/
drmRegion primary_dma;
/**
* Region for holding textures. If \c agp_mode is zero and
* there is no IOMMU available, this will be zero size.
*/
drmRegion textures;
/**
* Upto 128 secondary DMA buffers. Each region will be a
* multiple of 64KiB. If \c agp_mode is non-zero, typically
* only the first region will be configured. Otherwise,
* each region will be used and allocated for 64KiB.
*/
drmRegion secondary_dma[128];
u8 agp_size; /** Size of AGP region in MB. */
u8 agp_mode; /** Set AGP mode. 0 for PCI. */
};
Does this look good, or should I try to get more sleep before designing
interfaces like this? ;)
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
On Maw, 2005-05-10 at 22:59, Ian Romanick wrote: 2. Primary DMA buffer. The DDX carves of 1MB for the primary DMA buffer. I don't think that's outside the reasonable realm for drm_pci_alloc. If it is, can this work with a smaller buffer? You'll have trouble grabbing that linearly from main memory, on the other hand I'm assuming most traffic is outgoing so you want the buffer in video card memory if possible and set write combining ? --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
Alan Cox wrote: On Maw, 2005-05-10 at 22:59, Ian Romanick wrote: 2. Primary DMA buffer. The DDX carves of 1MB for the primary DMA buffer. I don't think that's outside the reasonable realm for drm_pci_alloc. If it is, can this work with a smaller buffer? You'll have trouble grabbing that linearly from main memory, on the other hand I'm assuming most traffic is outgoing so you want the buffer in video card memory if possible and set write combining ? I was afraid of that. :( The problem is that the MGA can *only* DMA commands vertex data from PCI memory or AGP. In the case of the G200 (typically only 8MB), you don't want to use 1/8th of your on-card memory for commands either. I'll have to dig deeper and see if there's another way around this. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
On Tue, 2005-05-10 at 14:59 -0700, Ian Romanick wrote: I've started working to get PCI MGA cards, the PCI G450 specifically, working with DRI. My initial goal is to just get it working with crummy performance, then improve it by adding support for IOMMUs (to simulate AGP texturing) on systems like pSeries and AMD64 that have them. I've started by digging through the DRI init process in the X.org MGA DDX. As near as I can tell, the driver uses AGP memory for four things. To make the PCI cards work, I'll need to make it do without AGP for these things. ../.. Note that most of these issues can be more easily dealt with if you assume an iommu. What you basically want to do is create a virtual mapping, build an sglist, and have the iommu coalesce that into a single PCI DMA mapping. Unfortunately, the current iommu API doesn't really have a way to enforce the iommu driver to create a single mapping. It will happen most of the time, but can't be enforced. We may have to add something to the DMA APIs to add this ability, or do a quick hack in the meantime as a proof of concept. I could do something for pSeries if you need that. Ben. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
