From: David Mosberger <davidm@napali.hpl.hp.com>
Date: Fri, 6 Jun 2003 13:13:38 -0700
Yes, but the comment certainly is confusing. How about something like
this:
No arguments.
David> The whole block layer makes all kinds of assumptions about
David> what physically contiguous addresses mean about how they'll
David> be contiguous in the bus addresses the device will actually
David> use to perform the DMA transfer.
This sounds all very dramatic, but try as I might, all I find is three
places where PCI_DMA_BUS_IS_PHYS is used:
- ide-lib.c: used to disable bounce buffering
- scsi_lib.c: used to disable bounce buffering
Fix your grep,
- tg3.c: what the heck??
In order to workaround a "just below 4GB dma address" bug in the
chip, we have to have a reliable way to "remap" the given networking
buffer to some other DMA address that does not meet the hw bug case.
If we don't have an IOMMU, we have to change the buffer itself and
we accomplish this with SKB copy.
But on an IOMMU system, we could end up mapping to the same bogus
DMA address. So we have to solve this problem by keeping the
existng bad mapping, doing a new DMA mapping, then trowing away
the old one.
Did I get this right (or at least close enough)?
Precisely.
Otherwise, you could just always use the copy-the-entire-buffer
workaround.
The new PCI dma mapping I make could map to the SAME bad DMA
address, that's the problem. I could loop forever making new
DMA mappings on an IOMMU system, each and every one falls into
the hw bug case.
I really dislike PCI_DMA_BUS_IS_PHYS, because it introduces a
discontinuity. I don't think it should be necessary.
I totally disagree.
David> We could convert the few compile time checks of
David> PCI_DMA_BUS_IS_PHYS so that you can set this based upon the
David> configuration of the machine if for some configurations it is
David> true. drivers/net/tg3.c is the only offender, my bad :-)
Yes. Would you mind fixing that?
Sure, no problem.
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:32 EST