> There had better not be any. It is a violation of the PCI
> specification
> to generate a DAC if the address fits in 32 bits.
>
> Then sym53c8xx with Gerard's current scripts code is in violation of
> the PCI specification when the chip is told to use DAC :-)
If you say so. You make it sound like the driver can
compensate for the broken hardware by explicitly telling
it to use SAC for a transfer after checking if the
dma_addr < 4GB. The HW is not in "violation" if it doesn't
generate a DAC < 4GB, and if it takes a driver check to
ensure that, it is the driver's problem: it is trivial to
check the high 32-bits of a 64-bit address for 0.
If the HW generates DAC for addresses < 4GB whenever enabling
support for 64-bit addresses, then that is very broken.
> DAC is a LOT faster and more efficient than a copy (except
> perhaps for the
> very smallest of transfers, which are already very inefficient).
>
> SAC with IOMMU is faster on some platforms.
Okay, so when the driver asks for the physical address, the arch-
specific code maps it with the iommu and returns a 32-bit address.
In that case, the dma_addr_t is 32 bits (unless it can return
64-bit addresses as well).
> There are several other reasons. (Man, people check the archives, I
> feel like I've typed this in like 5 times in linux-kernel postings
> already)
If you send pointer to your previous message I will read it. I am
interested in this subject (and have experience), so I threw in my
2 cents. Please don't complain that I didn't spend hours searching
through the archives looking for a message from months? years? ago
that I didn't know existed.
> Let me list one of them, suppose you have a device for which
> some transfers can happily use DAC addresses, but some others strictly
> need to work with SAC addresses.
What does that have to do with anything? That just means that the
DMA constraints have to be specified on a per-mapping/per-allocation
basis, not a per-device basis. That doesn't mean you need separate
routines for 64-bit PCI addresses and 32-bit PCI addresses. It just
means you need sane DMA constraints handling.
> I think for SAC-only devices, it is just dumb wasted space in the
> driver image.
Perhaps. But the question is whether it is simpler/better to have
HIGHMEM x86 kernels (which by definition have memory to spare) waste
a few bytes to provide "sane" interfaces across all platforms. And
whether the kernel bloat for all the additional functions compensates
for it ;-)
Reasonable people can have different opinions.
Kevin Van Maren
-
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 : Thu Aug 23 2001 - 21:00:53 EST