lkml.org 
[lkml]   [1999]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > 1GB on alpha. Patch to 1TB?
On 15 Mar 1999, James H. Cloos Jr. wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "Jay" == Jay Estabrook <Jay.Estabrook@digital.com> writes:
>
> Jay> On Alpha, in addition to the direct-map DMA windows which are currently
> Jay> used, one can define what we call "scatter-gather" DMA windows. The range of
> Jay> PCI addresses that fall into one of these windows are re-directed to host
> Jay> memory via a page table, where the address in a PTE can be *any* page in the
> Jay> possible installed memory - no bounce buffers needed... :-)
>
> I suspect this is what the original poster was referring to. In any
> case, for 2.3 at least, this would be the best target to shoot for, IMO.
>
> How much effort would be required to implement this scheme? If the
> `scatter-gather' were set up at device resolution, rather than page
> resolution, would the drivers even require modification?

Yes. It still requires that a driver allocate a section of memory that it
is going to be using for PCI communication. There's no way around this.

I (the original poster) don't know if a scatter-gather solution is required
(it is supported by alpha hardware, I don't know about others). It may be
possible to do it without scatter-gather support in hardware. At any rate,
it looks like all device drivers that are going to be using PCI transfers
will have to do something like:

bus_alloc(<buffer address>, <size>);
out(virt_to_bus(<buffer address>), HARDWARE_DO_SOMETHING_PORT);
[...]
bus_dealloc(<buffer address>);

virt_to_bus is currently implemented, but cannot on the fly determine how to
reallocate mappings so as to not clobber another device, unless it is told
(via my bus_alloc or something similar) who is using what regions of the PCI
address space.

Note that using this bus_alloc/bus_dealloc implementation allows the driver
to keep several buffers. Also note that giving the hardware a different
address within the buffer should work fine too. (out(virt_to_bus(<buffer
address> + 0x4000), HARDWARE_DO_SOMETHING_PORT) etc.)

On alpha scatter-gather is simply an address translation scheme that allows
small granularity (8kb). I don't know how much kernel support beyond
bus_alloc/virt_to_bus/bus_dealloc would be required to implement bounce
buffers using the scatter-gather mappings. Perhaps someone who understands
bounce buffers would care to comment? (I'm still not sure what they are...)

I wonder if it would be possible to take a poll of hardware owners to
determine which chipsets support scatter-gather. I don't know if this is
part of the PCI spec, or a hack implemented by Digital and Sun. Will Merced
chipsets support scatter-gather? At any rate, a generic
bus_alloc/bus_dealloc should be able to hide whatever memory->bus remapping
the hardware supports...whether scatter-gather exists on all chipsets or
not.

Most importantly: if bounce buffers are required to access memory >1GB from
PCI, can it be done with a simple bus_alloc/virt_to_bus/bus_dealloc? Or
must we implement a more complex solution that can handle both cases?

-- Bob

Bob McElrath (rsmcelrath@students.wisc.edu) Univ. of Wisconsin at Madison



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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.027 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site