Messages in this thread |  | | | From | David Mosberger <> | | Date | Tue, 10 Jun 2003 13:24:06 -0700 | | Subject | Re: problem with blk_queue_bounce_limit() |
| |
Christoph,
You wrote:
> imo PCI_DMA_BUS_IS_PHYS should be a propert of each struct device > because a machine might have a iommu for one bus type but not > another, e.g.
> dma_is_phys(dev);
As pointed out by DaveM, this isn't sufficient for the block layer, which needs to know the page size of the I/O MMU so it can make merging decisions about physically discontiguous buffers.
I think we also need:
/* * Returns a mask of bits which need to be 0 in order for * the DMA-mapping interface to be able to remap a buffer. * DMA-mapping implementations for real (hardware) I/O MMUs * will want to return (iommu_page_size - 1) here, if they * support such remapping. DMA-mapping implementations which * do not support remapping must return a mask of all 1s. */ unsigned long dma_merge_mask(dev) Then you can replace:
BIO_VMERGE_BOUNDARY => (dma_merge_mask(dev) + 1)
Of course, this doesn't work literally, because we don't have a device pointer handy in the bio code. Instead, it would probably make the most sense to add a "iommu_merge_mask" member to "struct request_queue" and then do something along the lines of:
#define BIO_VMERGE_BOUNDARY(q) ((q)->iommu_merge_mask + 1)
Note 1: the "+ 1" will get optimized away because the only way BIO_VMERGE_BOUNDARY() is used is in BIOVEC_VIRT_MERGEABLE, which really needs a mask anyhow; this could be cleaned up of course, but that's a separate issue.
Note 2: dma_merge_mask() cannot be used to replace dma_is_phys() (as much as I'd like that), because they issue of (virtual) remapping is really quite distinct from whether a (hardware) I/O MMU is present (not to mention the _other_ reason that a bus may not be "physical").
Note 3: I'm not comfortable hacking the bio code, so if someone would like to prototype this, by all means go ahead... ;-)
Thanks,
--david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |