> -----Messaggio originale----- > Da: sibis=codeaurora.org@xxxxxxxxxxxxxxxxx > <sibis=codeaurora.org@xxxxxxxxxxxxxxxxx> Per conto di Sibi Sankar > Inviato: lunedì 31 agosto 2020 07:46 > A: Viresh Kumar <viresh.kumar@xxxxxxxxxx> > Cc: Ansuel Smith <ansuelsmth@xxxxxxxxx>; vincent.guittot@xxxxxxxxxx; > saravanak@xxxxxxxxxx; Sudeep Holla <sudeep.holla@xxxxxxx>; Rafael J. > Wysocki <rjw@xxxxxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; linux- > pm@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx > Oggetto: Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support > > On 2020-08-24 16:10, Viresh Kumar wrote: > > +Vincent/Saravana/Sibi > > > > On 21-08-20, 16:00, Ansuel Smith wrote: > >> This adds Krait Cache scaling support using the cpufreq notifier. > >> I have some doubt about where this should be actually placed (clk or > >> cpufreq)? > >> Also the original idea was to create a dedicated cpufreq driver (like > >> it's done in > >> the codeaurora qcom repo) by copying the cpufreq-dt driver and adding > >> the cache > >> scaling logic but i still don't know what is better. Have a very > >> similar driver or > >> add a dedicated driver only for the cache using the cpufreq notifier > >> and do the > >> scale on every freq transition. > >> Thanks to everyone who will review or answer these questions. > > > > Saravana was doing something with devfreq to solve such issues if I > > wasn't mistaken. > > > > Sibi ? > > IIRC the final plan was to create a devfreq device > and devfreq-cpufreq based governor to scale them, this > way one can switch to a different governor if required. So in this case I should convert this patch to a devfreq driver- Isn't overkill to use a governor for such a task? (3 range based on the cpufreq?) > (I don't see if ^^ applies well for l2 though). In the > interim until such a solution is acked on the list we > just scale the resources directly from the cpufreq In this case for this SoC we can't really scale the L2 freq with the cpu since we observed a bug and we need to switch back to the idle freq sometimes. Also this SoC use the generic cpufreq-dt driver and doesn't have a dedicated driver. So we must use a notifier. > driver. On SDM845/SC7180 SoCs, L3 is modeled as a > interconnect provider and is directly scaled from the > cpufreq-hw driver. > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project.
