Mark Lord wrote:
Jeff Garzik wrote:
Mark Lord wrote:
So therefore, code to manage the dma_boundary is NOT necessary in
sata drivers. Right? Currently we have in sata_mv.c:
MV_DMA_BOUNDARY = 0xffff;
while (sg_len) {
offset = addr & MV_DMA_BOUNDARY;
len = sg_len;
if ((offset + sg_len) > 0x10000)
len = 0x10000 - offset;
...
That whole block should be able to go, then.
Incorrect. :)
The idiot IOMMU layer may merge too aggressively, which is the reason
for this code and similar code in ata_fill_sg(). The IOMMU stuff
always happens at pci_map_sg() time, after the block layer gets out of
the way.
Ahh.. then how does the low-level driver know what to use for
".sg_tablesize"?
It cannot use the real hardware/driver value, because it may need to do
request splitting. I wonder what the worst case number of splits required
is, for each sg[] entry?
To answer that question, you have to take into account the 64k DMA
boundary requirement, the worst case split (==sg_tablesize), and how
many splits required in each s/g entry -- in the case of sata_mv.c and
ata_fill_sg(), worst case is one split per s/g entry.
Jeff
-
: 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
