Re: problem with blk_queue_bounce_limit()

["David S. Miller" <davem@redhat.com>]

   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.