Cache routines working with a processor set?

Daniel Hellstrom daniel at gaisler.com
Fri Dec 21 13:55:40 UTC 2018


Hi Sebastian,

I missed to respond to this email.. It is not currently used by our 
drivers currently, I think the original use case here is when 
L3/L2/L1-cache is not updated after DMA. For example, the GR740 can be 
configured to make DMA directly to SDRAM memory, "behind" the L2-cache. 
In this mode the system is not coherent. To avoid the L2 cache 
containing incorrect data, one approach is to use a "DMA address region" 
and configure a L2-cache MTR regions. However, the L1-cache would still 
not be updated since it L1 D-cache is not snooping the memory bus but 
only the CPU bus which the DMA master is not writing to in this 
configuration. Using the MMU and marking pages non-cacheable could 
resolve this to a cost. Another approach would be to flush those lines 
or the whole D-cache instead of using the MMU. At that time, it was 
under consideration to add line/page flushing to the GR740 L1-cache.

For the I-cache we need to flush when modifying instructions, like the 
trap vector. But this patch seems to only involve d-cache.

Regards, Daniel

Daniel Hellstrom
Software Section Head
Cobham Gaisler
T : +46 (0) 31 775 8657
F : +46 (0) 31 421407
daniel.hellstrom at gaisler.com

Cobham Gaisler AB, Kungsgatan 12, SE-411 19, GÖTEBORG, Sweden.
+46 (0) 31 775 8650, www.cobham.com/gaisler

Please consider the environment before printing this email

This e-mail and any files transmitted with it ("E-mail") is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure,
reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail.

Neither the company nor any subsidiary or affiliate or associated company nor any individual sending this Email accepts any liability in respect of the content (including errors and omissions) nor shall this e-mail be deemed to enter the company or any subsidiary or affiliate or associated company into a contract or to create any legally binding obligations unless expressly agreed to in writing under separate cover and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version from the sender.

On 2018-11-14 07:21, Sebastian Huber wrote:
> Hello,
>
> are the following cache manager routines used in an application or 
> device driver code?
>
> /**
>  * @brief Flushes multiple data cache lines for a set of processors
>  *
>  * Dirty cache lines covering the area are transferred to memory.
>  * Depending on the cache implementation this may mark the lines as 
> invalid.
>  *
>  * This operation should not be called from interrupt context.
>  *
>  * @param[in] addr The start address of the area to flush.
>  * @param[in] size The size in bytes of the area to flush.
>  * @param[in] setsize The size of the processor set.
>  * @param[in] set The target processor set.
>  */
> void rtems_cache_flush_multiple_data_lines_processor_set(
>   const void *addr,
>   size_t size,
>   const size_t setsize,
>   const cpu_set_t *set
> );
>
> /**
>  * @brief Invalidates multiple data cache lines for a set of processors
>  *
>  * The cache lines covering the area are marked as invalid.  A later read
>  * access in the area will load the data from memory.
>  *
>  * In case the area is not aligned on cache line boundaries, then this
>  * operation may destroy unrelated data.
>  *
>  * This operation should not be called from interrupt context.
>  *
>  * @param[in] addr The start address of the area to invalidate.
>  * @param[in] size The size in bytes of the area to invalidate.
>  * @param[in] setsize The size of the processor set.
>  * @param[in] set The target processor set.
>  */
> void rtems_cache_invalidate_multiple_data_lines_processor_set(
>   const void *addr,
>   size_t size,
>   const size_t setsize,
>   const cpu_set_t *set
> );
>
> /**
>  * @brief Flushes the entire data cache for a set of processors
>  *
>  * This operation should not be called from interrupt context.
>  *
>  * @see rtems_cache_flush_multiple_data_lines().
>  *
>  * @param[in] setsize The size of the processor set.
>  * @param[in] set The target processor set.
>  */
> void rtems_cache_flush_entire_data_processor_set(
>   const size_t setsize,
>   const cpu_set_t *set
> );
>
> /**
>  * @brief Invalidates the entire cache for a set of processors
>  *
>  * This function is responsible for performing a data cache
>  * invalidate. It invalidates the entire cache for a set of
>  * processors.
>  *
>  * This operation should not be called from interrupt context.
>  *
>  * @param[in] setsize The size of the processor set.
>  * @param[in] set The target processor set.
>  */
> void rtems_cache_invalidate_entire_data_processor_set(
>   const size_t setsize,
>   const cpu_set_t *set
> );
>
> I would like to remove these exotic, complex and very hard to use 
> correctly functions.
>


More information about the users mailing list