On Fri, 2008-01-25 at 10:18 -0500, Mark Lord wrote: > James Bottomley wrote: > > On Thu, 2008-01-24 at 23:29 -0500, Mark Lord wrote: > >> Tejun Heo wrote: > >>> Mark Lord wrote: > >>> .. > >>>> Super! You've done a great job with this stuff, Tejun! > >>> Thanks but I can't really say nice things about how sata_sil24's > >>> qc_defer() is implemented or how we generally handle command deferring. > >>> We really need the control at the higher level - request_queue group. > >>> Oh well... I guess you guys will be talking about it over beer again > >>> soon. :-) > >> .. > >> > >> You too? > >> > >> Another one for those beers, is a way to tell the IOMMU code about > >> physical segment limitations -- so we can stop having to allocate > >> PRD tables 2X as big as necessary in drivers like sata_mv. > > > > If the IOMMU would observe the queue dma_boundary parameter, is that > > enough? (it is for the 64k PRD limit). If so, there are already > > patches in the works to solve this permanently. If not, could we get > > the requirements to see how it might be done? > .. > > That sounds like the right thing. > > We just have ensure that: > > 1. single SG/PRD entries never cross a 64KB address boundary. > > and these two then naturally follow for free: > > 2. single SG/PRD entries never exceed 64KB. > 3. single SG/PRD entries never cross a 32-bit address boundary. > > Are the patches going into 2.6.25 ? Tomo can answer that one ... they're in his patch series > How do we take advantage of them ? you need to set the dma_boundary in the host template for the driver. ATA already provides a ATA_DMA_BOUNDARY constant for the 64k case. James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
