Re: [patch] R4k cache code synchronization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10 Jan 2003, Juan Quintela wrote:

> The only thing that could be controversial is the _l1() thing, and as
> current thing is broken, I vote for insclusion.
> 
> maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
> maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c	2002-12-20 03:56:52.000000000 +0000
> maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c	2003-01-09 23:21:39.000000000 +0000
> @@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
>  	unsigned long end, a;
>  
>  	if (size >= scache_size) {
> -		flush_cache_l1();
> +		flush_cache_all();
>  		return;
>  	}
> 
> This one is fixing a bug, we are talking about a chip with Secondary
> cache and don't touch the secondary cache at all :(

 That bug is inactive -- both function pointers are defined to the same
value as surprisinly enough "l1" means "both caches" for the R4k.  Anyway,
I for removing flush_cache_l1() altogether in the next step. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux