>> IIRC, there are some funny games you can play with 32bit PCI DMA.
>> You're not necessarily restricted to the bottom 4Gb of phys addr space,
>> you're restricted to a 4Gb window, which you can shift by programming
>> a register on the card. Fixing that register to point to a window for the
>> node in question allows you to allocate from a node's pg_data_t and
>> assure DMAable RAM is returned.
>
> if you've as many windows as the number of nodes than you're just fine
> in all cases. you only need to teach pci_map_single and friends to
> return the right bus address that won't be an identity anymore with the
> phys addr, then you can forget the >4G phys constraint on the pages
> returned by zone_normal :).
I only have third hand information, rather than real experience in
this particular area, but I believe the general idea was to map
the window for any given card onto it's own node's physaddr space.
For a general dirty kludge, we could allocated DMAable memory by
simply doing an alloc_pages_node from node 0 (assuming a max of
4Gb in the first node ... if we really want a bounce buffer *and*
we have more than 4Gb in the first node *and* we have a 32 bit
DMA card, we can always alloc from ZONE_NORMAL on node 0 ... yes,
that's pretty disgusting ... but 99% of things will have 64 bit
DMA).
M.
-
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 : Tue May 07 2002 - 22:00:18 EST