Hi On Sun, 24 Apr 2005, James Bottomley wrote: > On Sun, 2005-04-24 at 02:22 +0200, Guennadi Liakhovetski wrote: > > But, I hope, > > the .page, .length, and .offset elements stayed unchanged, so, one can > > still walk elements 0 and 1, calculating a sum of sg[i].length and thus > > arrive to the required page, right? > > This, I'm not entirely sure about. There are some weird iommu mapping > implementations out there. The only absolute requirement is that the > map_sg unmap_sg map_sg actually work. There was some debate over > whether unmap_sg was supposed to return the sg list to its original > form, but x86_64 got beaten up in the argument, so this is true too. > > So ... I think the answer to your question is "yes", at least for all > the iommu implementations I know about. However, nothing in the > published API actually requires this. > > What I think all this means is that you can get away with what you're > proposing. However, the proper route would be to unmap the sglist > before you start feeding the leftovers via pio. Hmm, does anyone already on "CC" know the exact answer? Shall I forward it to LKML? It'd be nice to know the answer exactly. I'm not quite sure if unmapping sg would be always feasible / at all doable. E.g., in tmscsim (AFAIR, in dc395x too) PIO is done in ISR. Would it be too limiting / impossible to actually require that .page, .length and .offset stay unchanged over map_sg? Ok, I actually looked through alpha ia64 parisc ppc64 sparc64 x86_64 - AFAICS, none of them ever modifies those sg members on sg_(un)map. Did I miss anybody with an IOMMU? Thanks Guennadi --- Guennadi Liakhovetski - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
