consistent_alloc() on 82xx

[Dan Malek]

On Jun 9, 2005, at 5:04 AM, Alex Zeffertt wrote:

> 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].

Right.

> ... Presumably this means that it *does not* by-pass the
> cache if this flag is not set.

It means just what it says.  If this flag is set, CPM DMA will
snoop the cache.  If you choose not to do this, you have to
maintain cache coherency through software.

>  ..... 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").

You need to be more clear with your terms.  Only the 60x core
"uses" the cache.  The CPM is a DMA device that can utilize
cache coherency protocols if you enable that with the GBL flags.

> I have seen this causing problems.  When I map a VPI/VCI to a 
> connection
> table using the address compression table,

Where are you placing the VP-level and VC-level tables?  I assume
you are properly configuring the GMODE to indicate their locations?
Does it work properly if the tables are in DP RAM?

> With external connection tables the problem is more severe.

There are some very subtle assumptions made by the ATM
controller regarding all channel data structures.  There aren't
configuration location flags for every level of table, and assumptions
are made that tables for a connection are either internal or
external.  Be careful with that.  I either entirely use DP RAM for
everything or external memory for everything, which seemed
to work for me in the past.  Maybe I was just lucky :-)

> ....  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.

Are you sure this is really a cache problem and not a race condition
with CPM access to the CTs?  The CPM does atomic burst read/write
of the RCT/TCT entries, and buy doing cache flush operations, the
60x core does the same.


Thanks.


	-- Dan