Cache routines working with a processor set?

[Daniel Hellstrom]

On 2018-12-21 15:06, Sebastian Huber wrote:
> Hello Daniel,
>
> On 21/12/2018 14:55, Daniel Hellstrom wrote:
>>
>> 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.
>
> this sounds like a very specialized use case. I don't think we should 
> provide an architecture-independent API for this. If you really need 
> this for a highly optimized driver on the GR740, you can use a special 
> purpose function.

Makes sense. There may be other ideas behind this them that I can't 
recall. It fine with me to remove them.

>
>>
>> For the I-cache we need to flush when modifying instructions, like 
>> the trap vector. But this patch seems to only involve d-cache. 
>
> The instruction cache software broadcast is still supported.
good.