Re: [PATCH 3/3] [BFIN] Blackfin documents and MAINTAINER patch

From: Robin Getz
Date: Mon Sep 25 2006 - 01:53:09 EST

Paul indicated:
> +cache-lock.txt
> + - HOWTO for blackfin cache locking.
> +

This is a generic enough of a feature that I suspect we should hash out a common API for it rather than having people roll their own.

That sounds like a good idea. From the few people that use this, I think a much simpler interface would be desirable.

For data, it is easy - something similar to the processor specific xx_flush_range(start,end) - have a xxx_lock_range(start,end) would be good, and easy to implement.

The only thing I am not sure of - is how to force things into cache. For data - it is easy - do a read, and then lock it. For instruction - for those architectures which have separate instruction cache (like Blackfin) it is much harder. The only way to get code into cache is to execute it. (ergo the existing interface).

Normally - what we do when locking things in cache is specific to the hardware.
- to prevent isr polluting cache, we disable interrupts
- If the code to be locked has a possibility of already being in the instruction cache, we invalidate the entire cache first
- we locks 3/4 of the cache - forcing any code to be put into a specific location.
- execute the code of interest (once)
- unlock the 3/4 of cache, and lock the 1/4 where the code of interest is located.
- turn back on interrupts.

Because the algorithm is so specific to the hardware - I am not sure how to make instruction as generic as data could be.

How does SH cache handle things like this?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at