Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-09-02 Thread Viresh Kumar
On 04-08-20, 11:44, Lukasz Luba wrote: > On 8/4/20 11:38 AM, Viresh Kumar wrote: > > I don't think doing it with help of firmware is the right thing to do > > here then. For another platform we may not have a firmware which can > > help us, we need something in the opp core itself for that. Lemme

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-06 Thread Sudeep Holla
On Wed, Aug 05, 2020 at 10:33:02AM -0700, Florian Fainelli wrote: > > > On 8/5/2020 9:03 AM, Sudeep Holla wrote: > > On Wed, Aug 05, 2020 at 06:34:36PM +0530, Viresh Kumar wrote: > >> On 05-08-20, 12:04, Lukasz Luba wrote: > >>> I know that Viresh is going to develop patches and improve these >

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-05 Thread Sudeep Holla
On Wed, Aug 05, 2020 at 06:34:36PM +0530, Viresh Kumar wrote: > On 05-08-20, 12:04, Lukasz Luba wrote: > > I know that Viresh is going to develop patches and improve these > > cpufreq stats framework. Maybe he also had this 'aggregation' in mind. > > I will leave it him. > > I am only going to

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-05 Thread Lukasz Luba
On 8/4/20 6:27 PM, Florian Fainelli wrote: On 7/29/2020 8:12 AM, Lukasz Luba wrote: Hi all, The existing CPUFreq framework does not tracks the statistics when the 'fast switch' is used or when firmware changes the frequency independently due to e.g. thermal reasons. However, the firmware

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-05 Thread Florian Fainelli
On 8/5/2020 9:03 AM, Sudeep Holla wrote: > On Wed, Aug 05, 2020 at 06:34:36PM +0530, Viresh Kumar wrote: >> On 05-08-20, 12:04, Lukasz Luba wrote: >>> I know that Viresh is going to develop patches and improve these >>> cpufreq stats framework. Maybe he also had this 'aggregation' in mind. >>>

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-05 Thread Sudeep Holla
On Tue, Aug 04, 2020 at 10:19:23AM -0700, Florian Fainelli wrote: > > > On 7/31/2020 8:56 AM, Sudeep Holla wrote: > > On Thu, Jul 30, 2020 at 10:36:51AM +0100, Lukasz Luba wrote: > >> > >> In this case I think we would have to create debugfs. > >> Sudeep do you think these debugfs should be

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-05 Thread Viresh Kumar
On 05-08-20, 12:04, Lukasz Luba wrote: > I know that Viresh is going to develop patches and improve these > cpufreq stats framework. Maybe he also had this 'aggregation' in mind. > I will leave it him. I am only going to look at cpufreq's view of stats independently from the firmware. -- viresh

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-04 Thread Florian Fainelli
On 7/29/2020 8:12 AM, Lukasz Luba wrote: > Hi all, > > The existing CPUFreq framework does not tracks the statistics when the > 'fast switch' is used or when firmware changes the frequency independently > due to e.g. thermal reasons. However, the firmware might track the frequency > changes

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-04 Thread Florian Fainelli
On 7/31/2020 8:56 AM, Sudeep Holla wrote: > On Thu, Jul 30, 2020 at 10:36:51AM +0100, Lukasz Luba wrote: >> >> In this case I think we would have to create debugfs. >> Sudeep do you think these debugfs should be exposed from the protocol >> layer: >> drivers/firmware/arm_scmi/perf.c > > I

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-04 Thread Lukasz Luba
On 8/4/20 11:38 AM, Viresh Kumar wrote: On 04-08-20, 11:29, Lukasz Luba wrote: On 8/4/20 6:35 AM, Viresh Kumar wrote: IIUC, the only concern right now is to capture stats with fast switch ? Maybe we can do something else in that case and brainstorm a bit.. Correct, the fast switch is the

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-04 Thread Viresh Kumar
On 04-08-20, 11:29, Lukasz Luba wrote: > On 8/4/20 6:35 AM, Viresh Kumar wrote: > > IIUC, the only concern right now is to capture stats with fast switch ? > > Maybe we > > can do something else in that case and brainstorm a bit.. > > Correct, the fast switch is the only concern right now and

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-04 Thread Lukasz Luba
On 8/4/20 6:35 AM, Viresh Kumar wrote: On 30-07-20, 10:36, Lukasz Luba wrote: On 7/30/20 10:10 AM, Sudeep Holla wrote: On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: On 29-07-20, 16:12, Lukasz Luba wrote: The existing CPUFreq framework does not tracks the statistics when

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-08-03 Thread Viresh Kumar
On 30-07-20, 10:36, Lukasz Luba wrote: > On 7/30/20 10:10 AM, Sudeep Holla wrote: > > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: > > > On 29-07-20, 16:12, Lukasz Luba wrote: > > > > The existing CPUFreq framework does not tracks the statistics when the > > > > 'fast switch' is

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-07-31 Thread Sudeep Holla
On Thu, Jul 30, 2020 at 10:36:51AM +0100, Lukasz Luba wrote: > > In this case I think we would have to create debugfs. > Sudeep do you think these debugfs should be exposed from the protocol > layer: > drivers/firmware/arm_scmi/perf.c I prefer above over cpufreq as we can support for all the

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-07-30 Thread Lukasz Luba
On 7/30/20 10:10 AM, Sudeep Holla wrote: On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: On 29-07-20, 16:12, Lukasz Luba wrote: The existing CPUFreq framework does not tracks the statistics when the 'fast switch' is used or when firmware changes the frequency independently due

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-07-30 Thread Sudeep Holla
On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: > On 29-07-20, 16:12, Lukasz Luba wrote: > > The existing CPUFreq framework does not tracks the statistics when the > > 'fast switch' is used or when firmware changes the frequency independently > > due to e.g. thermal reasons. However,

Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-07-30 Thread Viresh Kumar
On 29-07-20, 16:12, Lukasz Luba wrote: > The existing CPUFreq framework does not tracks the statistics when the > 'fast switch' is used or when firmware changes the frequency independently > due to e.g. thermal reasons. However, the firmware might track the frequency > changes and expose this to

[PATCH 0/4] CPUFreq statistics retrieved by drivers

2020-07-29 Thread Lukasz Luba
Hi all, The existing CPUFreq framework does not tracks the statistics when the 'fast switch' is used or when firmware changes the frequency independently due to e.g. thermal reasons. However, the firmware might track the frequency changes and expose this to the kernel. This patch set aims to