Re: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers

[Sai Prakash Ranjan]

On 2020-09-03 19:16, Doug Anderson wrote:
> Hi,
>
> On Thu, Sep 3, 2020 at 2:58 AM Sai Prakash Ranjan
> <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote:
> > Hi,
> >
> > On 2020-08-18 21:07, Sai Prakash Ranjan wrote:
> > > Hi Doug,
> > >
> > >>
> > >> I guess to start, it wasn't obvious (to me) that there were two
> > >> choices and we were picking one.  Mentioning that the other
> > >> alternative was way-based allocation would help a lot.  Even if you
> > >> can't fully explain the differences between the two, adding something
> > >> to the commit message indicating that this is a policy decision (in
> > >> other words, both work but each have their tradeoffs) would help.
> > >> Something like this, if it's correct:
> > >>
> > >> In general we try to enable capacity based allocation (instead of the
> > >> default way based allocation) since that gives us better performance
> > >> with the current software / hardware configuration.
> > >>
> > >
> > > Thanks, I will add it for next version. Let me also go poke some arch
> > > teams
> > > to understand if we actually do gain something with this selection, who
> > > knows
> > > we might get some additional details as well.
> > >
> >
> > I got some information from arch team today, to quote them exactly:
> >
> > 1) What benefits capacity based allocation brings over the default way
> > based allocation?
> >
> > "Capacity based allows finer grain partition. It is not about improved
> > performance but more flexibility in configuration."
> >
> > 2) Retain through power collapse, doesn’t it burn more power?
> >
> > "This feature is similar to the standard feature of retention. Yes, 
> > when
> > we
> > have cache in retention mode it burns more power but it keeps the 
> > values
> > so
> > that when we wake up we can get more cache hits."
> >
> >
> > If its good enough, then I will add this info to the commit msg and 
> > post
> > next version.
>
> Sounds fine to me.  I was mostly looking for a high level idea of what
> was happening here.  I am at least a little curious about the
> retention bit.  Is that retention during S3, or during some sort of
> Runtime PM?  Any idea how much power is burned?  Unless the power is
> miniscule it seems hard to believe that it would be a net win to keep
> a cache powered up during S3 unless you're planning on waking up a
> lot.

The retention setting is based on sub cache id(SCID), so I think its for
runtime pm, the power numbers weren't provided. But I believe these
decisions are made after solid testing and not some random 
approximations.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation