consistent_alloc() on 82xx

Alex Zeffertt ajz at cambridgebroadband.com
Thu Jun 9 19:04:37 EST 2005


On Wed, 8 Jun 2005 12:12:01 -0400
Dan Malek <dan at embeddededge.com> wrote:

> 
> On Jun 8, 2005, at 5:29 AM, Alex Zeffertt wrote:
> 
> > Does anybody know why it isn't built for 6xx cores?
> 
> Because 6xx cores are cache coherent and there shouldn't
> be any need for "uncached" memory regions.
> 
> > I'm working on the ATM driver and it seems that certain external
> > memory areas accessed by the PQII CPM by-pass the cache.
> 
> That's news to me, and I've written lots of CPM drivers, including
> ATM. Do you have a specific example?
> 

Hi Dan,

An example of non-cache coherency in the CPM2: In the ATM chapter of
the 8260 UM it says that the CPM will only assert GBL and "snoop"
buffers, Buffer Descriptors, and interrupt queues if you set TCT[GBL]
and RCT[GBL].  Presumably this means that it *does not* by-pass the
cache if this flag is not set.  More seriously, for address compression
tables, and external connection tables there is no way of specifying
that it *should* snoop - (which I assume means "use the cache").

I have seen this causing problems.  When I map a VPI/VCI to a connection
table using the address compression table, the first few cells received
do NOT get mapped.  I thought this might be a result of the CPM
by-passing the cache so I added a "flush_dcache_range" after writing to
the address compression tables.  When I did this the problem went away.

With external connection tables the problem is more severe.  During
frame transmission, the core is constantly having to read and write to
the Transmit Connection Table in order to use Auto-VC-ofF.  I couldn't
get this to work until I added lots of "invalidate_dcache_range" and
"flush_dcache_range" calls.  However, doing this is (i) inefficient, and
(ii) *very* error prone.

Alex



More information about the Linuxppc-embedded mailing list