Re: [RFC] MIPS: Add cacheinfo support

[Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>]

On 12/13/2016 12:05 PM, Florian Fainelli wrote:
> On 12/13/2016 12:01 PM, Justin Chen wrote:
>> On Tue, Dec 13, 2016 at 11:18 AM, Leonid Yegoshin
>> <Leonid.Yegoshin@imgtec.com> wrote:
>>> On 12/13/2016 03:09 AM, Maciej W. Rozycki wrote:
>>>> On Tue, 13 Dec 2016, Leonid Yegoshin wrote:
>>>>
>>>>> Well, I prefer the collection of 3 flags:
>>>>>
>>>>> flush_required        - or flush to next level is required to force
>>>>> coherency
>>>>> between this level and next after update of this level
>>>>> invalidate_required   - or invalidate is required to force coherency
>>>>> between
>>>>> this level and next after update of next level
>>>>> coherent_to_level     - object is coherent with this level (only one
>>>>> domain of
>>>>> coherency on this level is assumed)
>>>>    A "flush" has always been an ambiguous term -- meaning anything from
>>>> "write-back", through "write-back+invalidate" to "invalidate".  What is
>>>> "flush" is supposed to exactly mean here?  If specifically any of the two
>>>> formers (the latter is obviously the other flag), then I suggest using the
>>>> respective name, or otherwise if it is meant to be generic "do what is
>>>> needed", then perhaps "synchronize" will work, like with the name of the
>>>> SYNCI instruction?
>>>>
>>> Well, I am not expert in choosing names, you know. I just would like to make
>>> a distinguishing between "transfer data from this level to next one" - any
>>> way - writeback or write-back-invalidate, and "clear data in this level to
>>> be pulled on demand from next level".
>>>
>>> This is an information purpose as Florian described, so details can be
>>> skipped. The only useful info here - some efforts are needed after event
>>> (see above) and that efforts are not cheap from performance point of view.
>>>
>>> If we put here details then it is a long way because we need a lot of
>>> details, see my original post. However, I would like to differ "flush" and
>>> "invalidate" because it is triggered by different kind of event (from
>>> upstream or from downstream).
>>>
>>> - Leonid.
>> I can add in the flags mentioned by Leonid. However, I would suggest
>> these flags be added in as a separate patch series as it will require
>> modifications to the cacheinfo code to propagate the information to
>> the sysfs.
>>
>> Would it be ok to accept this patch series as is while I work with the
>> cacheinfo maintainers to include these new flags?
> Seems entirely reasonable to me. You may want to make a new patch
> submission without "RFC", just to make it clear that this is a patch
> ready for review/acceptance.
>
> Thanks!
I agree.

- Leonid.