Re: [PATCH] RFC: kills consistent_dma_mask

[Jes Sorensen]

>>>>> "Krzysztof" == Krzysztof Halasa <khc@xxxxxxxxx> writes:

Krzysztof> "David S. Miller" <davem@xxxxxxxxxx> writes:
>> The ia64 support code to do things with consistent_dma_mask just
>> isn't in the tree yet.

Krzysztof> Ok. Any pointer so I can see how is it used?

drivers/net/tg3.c was the case where we needed it first. If you grab
the official ia64 kernel patch and look in the arch/ia64/sn/io code
you will find places that consider it.

>> Because the other platforms don't to do anything special wrt. this
>> they can just ignore consitent_dma_mask altogether.

Krzysztof> No. The documentation states that consistent_dma_mask (and
Krzysztof> not dma_mask) will be used when doing
Krzysztof> pci_alloc_consistent(). This is, obviously, false on most
Krzysztof> platforms.

It's not being used on those platforms because I couldn't implement it
on all of them - I just don't have the hardware. We implemented it on
ia64 because thats where we needed it, Andi Kleen then implemented it
on x86_64 because he needed it there. If there are PPC boxes out there
with similar issues then I am sure that the PPC maintainers will
implement support for this when they need it.

Krzysztof> It is perfectly reasonable to expect that
Krzysztof> setting consistent_dma_mask to, say, 28 bits will cause
Krzysztof> pci_alloc_consistent to return memory from first 256
Krzysztof> MB. This is not true on most platforms, for example i386
Krzysztof> happily allocs memory near the top in such case.

The default for pci_alloc_consistent() on ia32 is that
pci_dev->consistent_dma_mask == 32 bit. If you need something else for
a reason, please feel free to implement support for it.

Krzysztof> If we really need two masks, they can't be ignored on some
Krzysztof> archs.

So *fix* it! This is Linux, it's Free Software, you have the source,
you have the right to fix bugs!

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/