Re: [2.5 patch] R5K SC support

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

 



On Sun, Jul 14, 2002 at 11:12:34PM +0200, Vivien Chappelier wrote:

> 
> 	This patch adds support for the secondary cache controller in the
> R5000 processors. It's quite similar to Brian Murphy's patch
> (thanks BTW) except it's based on the current R4K code.
> 	There is code for variants with 16 bytes cache lines if they
> exist.. if they don't just remove :)

They don't exist.

> +static inline void r5k_flush_cache_all_sXXd16i16(void)
> +static void r5k_flush_cache_mm_sXXd16i16(struct mm_struct *mm)

Dead code.

> +static inline void r5k_flush_cache_all_sXXd32i32(void)

> +static void r5k_flush_cache_range_sXXd16i16(struct vm_area_struct *vma,
> +	unsigned long start, unsigned long end)

> +static void r5k_flush_cache_range_sXXd32i32(struct vm_area_struct *vma,
> +	unsigned long start, unsigned long end)
> +static void r5k_flush_cache_mm_sXXd32i32(struct mm_struct *mm)
> +static void r5k_flush_cache_page_sXXd16i16(struct vm_area_struct *vma,
> +					   unsigned long page)
> +static void r5k_flush_cache_page_sXXd32i32(struct vm_area_struct *vma,
> +					   unsigned long page)
> +static void r5k_flush_page_to_ram_sXXd16(struct page *page)
> +static void r5k_flush_page_to_ram_sXXd32(struct page *page)

Flushing the second level cache not required as it's physically indexed
so these are actually indentical to the R4000PC variant flushes.

The second level cache only has to be flushed by sysmips(FLUSH_CACHE, ...),
flushcache(2) and once on bootup on activation.

> +static void r5k_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size)
> +static void r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size)

You can hook the second level cache support into the bcache hook.  That's
working because unlike the R4000SC the R5000's second level cache does not
have the additional constraint of the primary caches always being a subset
of the second level caches.

Arch/mips/sgi-ip22/ip22-sc.c is an example how this can be done.

>  /* If you even _breathe_ on this function, look at the gcc output
>   * and make sure it does not pop things on and off the stack for
>   * the cache sizing loop that executes in KSEG1 space or else
>   * you will crash and burn badly.  You have been warned.
>   */

The R4000SC cache sizing code is bad enough as it is; can you keep it a
separate function from the code for other CPUs?

> +static void __init r5k_setup_scache_funcs(void)

With above changes this function will vaporize as well ...

An additional comment on the Page_Writeback_Inv_S and operations.  They
will only work, if the second level caches uses SRAM with the flash clean
column feature.  If cache SRAMs don't support that feature, things will
blowup.  That's not an uncommon R4k configuration, unfortunately, so we
have to support it and as there is no mechanism for probling provided one
simply has to know what type of memory is in used.  Not sure about
All_Writeback_Inv_S but similar constraints should apply.

  Ralf


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

  Powered by Linux