On Nov 23, 2009, at 6:38 AM, John Baldwin wrote:
On Sunday 22 November 2009 6:48:18 pm Scott Long wrote:
By definition, PCIe can't transfer across 4GB boundaries. It's not a
bug specific to Broadcom. If you're loading dynamic buffers (i.e.
mbufs), setting an appropriate boundary value in the tag will allow
busdma to take care of this. If you're allocating static buffers,
busdma won't honor this. But what you've done here is best anyways;
control buffers that are going to be frequently transferred are best
kept in the lower 4GB of the address space. It simplifies PCIe
handling, and it's significantly faster on PCI/PCI-X. So I'd suggest
making this the rule rather than the exception in the driver.
Should we enforce an implicit 4GB boundary in bus_dma then? Perhaps
Host-PCI
bridge drivers should create a tag with a 4GB boundary that devices
inherit
via bus_get_dma_tag(). For i386/PAE we might should always enforce
a 4GB
boundary as well?
That was actually the point of creating bus_get_dma_tag(). I don't
recall how complete the back-end work of providing a inheritance tree
for bridges got. Note that having this wouldn't really solve Pyun's
problem, because boundaries aren't honored for static allocations.
There's been plenty of talk about multi-segment static allocations,
but I don't think that that's applicable to this either. As I said
before, it's best to restrict static allocations to the lower 4GB of
memory and not worry about the boundary at all. But having the proper
inheritance would still be nice.
Another thing that I'd like to do is have an alternate for
bus_dma_tag_create() that takes the device_t of the device as the
first argument and figures out the parent tag and inheritance
automatically. That's a job for the mythical /sys/kern/subr_busdma.c.
Scott
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
