>[...]
> The argument for supplying this functionality in the PCI DMA code
> would be that if it was done there it could be done once, and in a
> sophisticated and efficient (and SMP-safe :) fashion, rather than
> ad-hoc in each driver.
This is exactly the kind of thinking that brought us pci_pool.
With all due respect to David-B, it was totally unnecessary,
in my view. However, attempts to make it "pretty" resulted in
something that cannot be implemented right. Just think if
pci_pool_free can be entered from an interrupt. If you allow
that, you cannot free full pages (because some broken architectures
implement pci_alloc_consistent with vmalloc, and vfree is not
interrupt safe). The root of the problem is an attempt to specify
variable sized pools.
I am afraid that if we start adding first class citizen APIs
in the area of pci_alloc_something, it's going to be more and
more interdependent and will place very strong constraints
on what architectures can and cannot do. For example, already
pci_alloc_consistent _cannot_ be implemented on some HP machines
(and, by extension, pci_pool).
> It may also be possible for the PCI DMA code to take advantage of its
> knowledge of a particular platform, for example if the platform only
> has a small range of possible DMA addresses then it could use a simple
> and fast lookup table. Or it may be possible to read the IOMMU tables
> on some platforms and do the reverse mapping quickly that way - this
> would certainly be the case for the IBM RS/6000 machines since the
> IOMMU tables are in system RAM.
And it neither of these is possible, then what? Then you fall
back on the most generic code, which is the worst case of
all possible partial implementations in drivers.
-- Pete
-
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 : Sun Oct 07 2001 - 21:00:42 EST