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

Olof Johansson olof at lixom.net
Sat Feb 17 01:36:09 EST 2007


On Thu, Feb 15, 2007 at 09:53:10PM +0100, Arnd Bergmann wrote:
> On Thursday 15 February 2007 19:17, Jean-Christophe Dubois wrote:
> > The DDR2 is not cache coherent in the Axon.
> 
> That's exactly the point Christoph was making. The phram driver
> maps the memory cacheable by default, so we need to change the
> driver to use cache-inhibited mode on axon ram.

Looking at the driver that was just posted, it did ioremap_flags(,,0),
which will ioremap the region cacheable. If that's not the
desired/required way to do it, then phram should be right on target. I
didn't look at the driver close enough to see if you're dealing with it
being non-coherent by explicit flusing on writes instead, and keeping
the read side cached. If you're not, then that's likely a bug.

The remaining thing that Christoph mentioned was XIP. I think that might
already be something that the embedded guys are working on, since they
want it for executing right out of flash. But I'm not on top of MTD
enough to know if it's backend driver specific and/or if it's merged. I
just remember seeing it mentioned sometime in the past.

> > 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.
> 
> Having the partition table in nvram sounds wacky, so I wouldn't like
> to see that in a generic driver. However, with the phram driver, it
> is not that unusual, since a lot of embedded systems already have
> MTD with wacky partitioning schemes, and one more probably won't hurt
> much.

Nvram or device tree support for how to partition it would probably work
OK. Device tree plus an of_platform layer for the driver would be a tidy
solution, at least if you expect the layout to stay consistent between
reboots and not needing to be changed from within the OS of the card.


-Olof



More information about the cbe-oss-dev mailing list