[Cbe-oss-dev] [PATCH] axonram: 1st version

[Jean-Christophe Dubois]

On Thursday 15 February 2007 16:31, Olof Johansson wrote:
> On Wed, Feb 14, 2007 at 12:06:13AM +0100, Maxim Shchetynin wrote:
> > Hello,
> >
> > This patch implements access to Axon's DDR2 memory via character and
> > block devices.
>
> Hi,
>
> This seems generic to me. Have you considered using the MTD subsystem
> instead of doing this specific driver?
>
> phram will do almost what you're looking for, won't it? Main difference
> is that it will ioremap uncachable, so you might want to change that
> (i.e. make a cached ram backend for MTD instead).

The DDR2 is not cache coherent in the Axon.

Now, the Axon is also used in an PCI-E accelerator type board (known as the 
CAB). In this case the DDR is not necessarily dedicated to the Cell. The 
PCI-E host (a normal PC) might manage part of it.

So one thing we would like to do is to define some kind of "partition table" 
and store it in NVRAM. This way the "partition" will be persistent over 
reset/reboot even on the CAB. Remember that on the CAB there is no permanent 
storage (disk or even NFS server) and by default we run an embedded type 
distribution from a Ramdisk (why would you need a full distro for an 
accelerator).

If the "partition table" is in the NVRAM then the host can also read it (or 
write it even if I think we should not allow this) to know what part of the 
DDR is reserved for the Cell and what part it can use for its own purpose.

In the CAB scenario the DDR can be used by as a kind of buffer to stage the 
data to be processed by the Cell/SPUs. Maybe this can also be of some value 
in the blade case to dedicate part of the DDR for "swap" and part of it as a 
working buffer for SPUs or other things.

Maybe the "partitioning" could even merge 2 memory banks into one (with a hole 
in the middle).

Would this way of partitioning the DDR be acceptable to you or do you see 
problems with this approach?

Thanks

JC

> -Olof