consistent_alloc() on 82xx

[Alex Zeffertt]

Hi Dan,


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


Ah, I see.  If the CPM DMA is configured to "snoop" the cache then that
doesn't mean it "uses" the cache - it just tells the cache when data
needs to flush - namely before DMA writes.

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


I've got the VP-level tables in DPRAM (as recommended by the UM) and the
VC-level tables in external memory (as required by UM).  The EVPT bit in
GMODE is cleared to indicate VP tables in DPRAM.

The first few cells received after writing the mapping are
definitely going to the raw cell queue.  This doesn't happen if I flush
the cache line following core writes to the VC-level table.  This
suggests to me that the CPM DMA is not employing the cache coherency
protocol when accessing the address compression tables.  This is not a
surprise since the UM only claims to be able to do "snooping" for
buffers, BDs, and interrupt tables.



> > 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 :-)


The UM definitely claims you can have a mixture of internal channels and
external channels.  If you want a lot of simultaneous channels open you
are forced to use both since the number of internal channels is limited
by (a) the amount of DPRAM available, and (b) the design limit of 256.

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

Well it looks to me that for address compression tables and external
connection tables the CPM DMA is not employing it's cache coherency
mechanisms.  This mechanism probably just boils down to the CPM saying
to the cache "I want to write to ptr, please flush any pending writes
then invalidate the line".  By adding calls to
flush/invalidate_dcache_range in my code I am doing the cache coherency
mechanism in software instead.  It would be a lot easier though if I
could just allocate uncached memory....


Thanks for your help,

Alex