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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to