linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
@ 2021-08-12 14:19 Taniya Das
  2021-08-12 15:53 ` Stephen Boyd
  2021-08-12 20:33 ` Doug Anderson
  0 siblings, 2 replies; 6+ messages in thread
From: Taniya Das @ 2021-08-12 14:19 UTC (permalink / raw)
  To: Rafael J . Wysocki, Viresh Kumar, linux-pm
  Cc: linux-arm-msm, linux-kernel, Douglas Anderson, Rajendra Nayak,
	Stephen Boyd, Taniya Das

As remote cpufreq updates are supported on QCOM platforms, set
dvfs_possible_from_any_cpu cpufreq driver flag.

Signed-off-by: Taniya Das <tdas@codeaurora.org>
---

[v2]
  * update the dvfs_possible_from_any_cpu always.

 drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index f86859b..53d3898 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -223,6 +223,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,

 	table[i].frequency = CPUFREQ_TABLE_END;
 	policy->freq_table = table;
+	policy->dvfs_possible_from_any_cpu = true;
+
 	dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);

 	return 0;
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
  2021-08-12 14:19 [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag Taniya Das
@ 2021-08-12 15:53 ` Stephen Boyd
  2021-08-12 20:33 ` Doug Anderson
  1 sibling, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2021-08-12 15:53 UTC (permalink / raw)
  To: Rafael J . Wysocki, Taniya Das, Viresh Kumar, linux-pm
  Cc: linux-arm-msm, linux-kernel, Douglas Anderson, Rajendra Nayak

Quoting Taniya Das (2021-08-12 07:19:15)
> As remote cpufreq updates are supported on QCOM platforms, set
> dvfs_possible_from_any_cpu cpufreq driver flag.
>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
  2021-08-12 14:19 [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag Taniya Das
  2021-08-12 15:53 ` Stephen Boyd
@ 2021-08-12 20:33 ` Doug Anderson
  2021-08-18 10:03   ` Taniya Das
  1 sibling, 1 reply; 6+ messages in thread
From: Doug Anderson @ 2021-08-12 20:33 UTC (permalink / raw)
  To: Taniya Das
  Cc: Rafael J . Wysocki, Viresh Kumar, Linux PM, linux-arm-msm, LKML,
	Rajendra Nayak, Stephen Boyd

Hi,

On Thu, Aug 12, 2021 at 7:19 AM Taniya Das <tdas@codeaurora.org> wrote:
>
> As remote cpufreq updates are supported on QCOM platforms, set
> dvfs_possible_from_any_cpu cpufreq driver flag.
>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
>
> [v2]
>   * update the dvfs_possible_from_any_cpu always.
>
>  drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index f86859b..53d3898 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -223,6 +223,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>
>         table[i].frequency = CPUFREQ_TABLE_END;
>         policy->freq_table = table;
> +       policy->dvfs_possible_from_any_cpu = true;
> +

Why is this in the qcom_cpufreq_hw_read_lut() function? Shouldn't it
be straight in qcom_cpufreq_hw_cpu_init()?

-Doug

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
  2021-08-12 20:33 ` Doug Anderson
@ 2021-08-18 10:03   ` Taniya Das
  2021-08-18 10:26     ` Viresh Kumar
  0 siblings, 1 reply; 6+ messages in thread
From: Taniya Das @ 2021-08-18 10:03 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Rafael J . Wysocki, Viresh Kumar, Linux PM, linux-arm-msm, LKML,
	Rajendra Nayak, Stephen Boyd

Hi Doug,

Thanks for your review.

On 8/13/2021 2:03 AM, Doug Anderson wrote:
> Hi,
> 
> On Thu, Aug 12, 2021 at 7:19 AM Taniya Das <tdas@codeaurora.org> wrote:
>>
>> As remote cpufreq updates are supported on QCOM platforms, set
>> dvfs_possible_from_any_cpu cpufreq driver flag.
>>
>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
>> ---
>>
>> [v2]
>>    * update the dvfs_possible_from_any_cpu always.
>>
>>   drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
>> index f86859b..53d3898 100644
>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> @@ -223,6 +223,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>>
>>          table[i].frequency = CPUFREQ_TABLE_END;
>>          policy->freq_table = table;
>> +       policy->dvfs_possible_from_any_cpu = true;
>> +
> 
> Why is this in the qcom_cpufreq_hw_read_lut() function? Shouldn't it
> be straight in qcom_cpufreq_hw_cpu_init()?
> 
All CPU policy related data is updated here, thus wanted to keep it 
together.

> -Doug
> 

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

--

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
  2021-08-18 10:03   ` Taniya Das
@ 2021-08-18 10:26     ` Viresh Kumar
  2021-08-23 10:17       ` Taniya Das
  0 siblings, 1 reply; 6+ messages in thread
From: Viresh Kumar @ 2021-08-18 10:26 UTC (permalink / raw)
  To: Taniya Das
  Cc: Doug Anderson, Rafael J . Wysocki, Linux PM, linux-arm-msm, LKML,
	Rajendra Nayak, Stephen Boyd

On 18-08-21, 15:33, Taniya Das wrote:
> Hi Doug,
> 
> Thanks for your review.
> 
> On 8/13/2021 2:03 AM, Doug Anderson wrote:
> > Hi,
> > 
> > On Thu, Aug 12, 2021 at 7:19 AM Taniya Das <tdas@codeaurora.org> wrote:
> > > 
> > > As remote cpufreq updates are supported on QCOM platforms, set
> > > dvfs_possible_from_any_cpu cpufreq driver flag.
> > > 
> > > Signed-off-by: Taniya Das <tdas@codeaurora.org>
> > > ---
> > > 
> > > [v2]
> > >    * update the dvfs_possible_from_any_cpu always.
> > > 
> > >   drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > index f86859b..53d3898 100644
> > > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > @@ -223,6 +223,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
> > > 
> > >          table[i].frequency = CPUFREQ_TABLE_END;
> > >          policy->freq_table = table;
> > > +       policy->dvfs_possible_from_any_cpu = true;
> > > +
> > 
> > Why is this in the qcom_cpufreq_hw_read_lut() function? Shouldn't it
> > be straight in qcom_cpufreq_hw_cpu_init()?
> > 
> All CPU policy related data is updated here, thus wanted to keep it
> together.

This function should only be updating freq table, please do it in
qcom_cpufreq_hw_cpu_init() itself, around where you set
policy->driver_data.

-- 
viresh

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag
  2021-08-18 10:26     ` Viresh Kumar
@ 2021-08-23 10:17       ` Taniya Das
  0 siblings, 0 replies; 6+ messages in thread
From: Taniya Das @ 2021-08-23 10:17 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Doug Anderson, Rafael J . Wysocki, Linux PM, linux-arm-msm, LKML,
	Rajendra Nayak, Stephen Boyd

Hi Viresh,

Thanks for the review.

On 8/18/2021 3:56 PM, Viresh Kumar wrote:
> On 18-08-21, 15:33, Taniya Das wrote:
>> Hi Doug,
>>
>> Thanks for your review.
>>
>> On 8/13/2021 2:03 AM, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, Aug 12, 2021 at 7:19 AM Taniya Das <tdas@codeaurora.org> wrote:
>>>>
>>>> As remote cpufreq updates are supported on QCOM platforms, set
>>>> dvfs_possible_from_any_cpu cpufreq driver flag.
>>>>
>>>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
>>>> ---
>>>>
>>>> [v2]
>>>>     * update the dvfs_possible_from_any_cpu always.
>>>>
>>>>    drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
>>>> index f86859b..53d3898 100644
>>>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>>>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>>>> @@ -223,6 +223,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>>>>
>>>>           table[i].frequency = CPUFREQ_TABLE_END;
>>>>           policy->freq_table = table;
>>>> +       policy->dvfs_possible_from_any_cpu = true;
>>>> +
>>>
>>> Why is this in the qcom_cpufreq_hw_read_lut() function? Shouldn't it
>>> be straight in qcom_cpufreq_hw_cpu_init()?
>>>
>> All CPU policy related data is updated here, thus wanted to keep it
>> together.
> 
> This function should only be updating freq table, please do it in
> qcom_cpufreq_hw_cpu_init() itself, around where you set
> policy->driver_data.
> 

Thanks Viresh, updated the same in the next patch.

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

--

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-08-23 10:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-12 14:19 [PATCH v2] cpufreq: qcom-hw: Set dvfs_possible_from_any_cpu cpufreq driver flag Taniya Das
2021-08-12 15:53 ` Stephen Boyd
2021-08-12 20:33 ` Doug Anderson
2021-08-18 10:03   ` Taniya Das
2021-08-18 10:26     ` Viresh Kumar
2021-08-23 10:17       ` Taniya Das

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).