Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1570998 > unrolled thread
| Started by | Markus Mayer <markus.mayer@broadcom.com> |
|---|---|
| First post | 2017-01-31 20:00 +0100 |
| Last post | 2017-02-02 12:30 +0100 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend Markus Mayer <markus.mayer@broadcom.com> - 2017-01-31 20:00 +0100
Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-02-02 00:50 +0100
Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend Markus Mayer <markus.mayer@broadcom.com> - 2017-02-02 01:00 +0100
Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend Viresh Kumar <viresh.kumar@linaro.org> - 2017-02-02 04:40 +0100
Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend "Rafael J. Wysocki" <rafael@kernel.org> - 2017-02-02 12:30 +0100
| From | Markus Mayer <markus.mayer@broadcom.com> |
|---|---|
| Date | 2017-01-31 20:00 +0100 |
| Subject | Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend |
| Message-ID | <t5LOO-4b0-35@gated-at.bofh.it> |
On 5 January 2017 at 20:11, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 19-12-16, 12:10, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> The AVS GET_PMAP command does return a P-state along with the P-map
>> information. However, that P-state is the initial P-state when the
>> P-map was first downloaded to AVS. It is *not* the current P-state.
>>
>> Therefore, we explicitly retrieve the P-state using the GET_PSTATE
>> command.
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>> drivers/cpufreq/brcmstb-avs-cpufreq.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index 2c6e325..c943606 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -784,8 +784,19 @@ static int brcm_avs_target_index(struct cpufreq_policy *policy,
>> static int brcm_avs_suspend(struct cpufreq_policy *policy)
>> {
>> struct private_data *priv = policy->driver_data;
>> + int ret;
>> +
>> + ret = brcm_avs_get_pmap(priv, &priv->pmap);
>> + if (ret)
>> + return ret;
>>
>> - return brcm_avs_get_pmap(priv, &priv->pmap);
>> + /*
>> + * We can't use the P-state returned by brcm_avs_get_pmap(), since
>> + * that's the initial P-state from when the P-map was downloaded to the
>> + * AVS co-processor, not necessarily the P-state we are running at now.
>> + * So, we get the current P-state explicitly.
>> + */
>> + return brcm_avs_get_pstate(priv, &priv->pmap.state);
>> }
>>
>> static int brcm_avs_resume(struct cpufreq_policy *policy)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Just wanted to follow up to see if this has been or will be picked up
for 4.10? I had a quick poke around some trees and did not see it
there.
Thanks,
-Markus
[toc] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2017-02-02 00:50 +0100 |
| Subject | Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend |
| Message-ID | <t6cOZ-4om-11@gated-at.bofh.it> |
| In reply to | #1570998 |
On Tuesday, January 31, 2017 10:53:01 AM Markus Mayer wrote:
> On 5 January 2017 at 20:11, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 19-12-16, 12:10, Markus Mayer wrote:
> >> From: Markus Mayer <mmayer@broadcom.com>
> >>
> >> The AVS GET_PMAP command does return a P-state along with the P-map
> >> information. However, that P-state is the initial P-state when the
> >> P-map was first downloaded to AVS. It is *not* the current P-state.
> >>
> >> Therefore, we explicitly retrieve the P-state using the GET_PSTATE
> >> command.
> >>
> >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> >> ---
> >> drivers/cpufreq/brcmstb-avs-cpufreq.c | 13 ++++++++++++-
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> >> index 2c6e325..c943606 100644
> >> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> >> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> >> @@ -784,8 +784,19 @@ static int brcm_avs_target_index(struct cpufreq_policy *policy,
> >> static int brcm_avs_suspend(struct cpufreq_policy *policy)
> >> {
> >> struct private_data *priv = policy->driver_data;
> >> + int ret;
> >> +
> >> + ret = brcm_avs_get_pmap(priv, &priv->pmap);
> >> + if (ret)
> >> + return ret;
> >>
> >> - return brcm_avs_get_pmap(priv, &priv->pmap);
> >> + /*
> >> + * We can't use the P-state returned by brcm_avs_get_pmap(), since
> >> + * that's the initial P-state from when the P-map was downloaded to the
> >> + * AVS co-processor, not necessarily the P-state we are running at now.
> >> + * So, we get the current P-state explicitly.
> >> + */
> >> + return brcm_avs_get_pstate(priv, &priv->pmap.state);
> >> }
> >>
> >> static int brcm_avs_resume(struct cpufreq_policy *policy)
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Just wanted to follow up to see if this has been or will be picked up
> for 4.10?
For 4.10? No way.
> I had a quick poke around some trees and did not see it
> there.
I'm not sure which trees you checked, but it is there in my linux-next branch.
Thanks,
Rafael
[toc] | [prev] | [next] | [standalone]
| From | Markus Mayer <markus.mayer@broadcom.com> |
|---|---|
| Date | 2017-02-02 01:00 +0100 |
| Message-ID | <t6cYF-4rB-5@gated-at.bofh.it> |
| In reply to | #1572075 |
On 1 February 2017 at 15:44, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, January 31, 2017 10:53:01 AM Markus Mayer wrote:
>> On 5 January 2017 at 20:11, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > On 19-12-16, 12:10, Markus Mayer wrote:
>> >> From: Markus Mayer <mmayer@broadcom.com>
>> >>
>> >> The AVS GET_PMAP command does return a P-state along with the P-map
>> >> information. However, that P-state is the initial P-state when the
>> >> P-map was first downloaded to AVS. It is *not* the current P-state.
>> >>
>> >> Therefore, we explicitly retrieve the P-state using the GET_PSTATE
>> >> command.
>> >>
>> >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> >> ---
>> >> drivers/cpufreq/brcmstb-avs-cpufreq.c | 13 ++++++++++++-
>> >> 1 file changed, 12 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> >> index 2c6e325..c943606 100644
>> >> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> >> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> >> @@ -784,8 +784,19 @@ static int brcm_avs_target_index(struct cpufreq_policy *policy,
>> >> static int brcm_avs_suspend(struct cpufreq_policy *policy)
>> >> {
>> >> struct private_data *priv = policy->driver_data;
>> >> + int ret;
>> >> +
>> >> + ret = brcm_avs_get_pmap(priv, &priv->pmap);
>> >> + if (ret)
>> >> + return ret;
>> >>
>> >> - return brcm_avs_get_pmap(priv, &priv->pmap);
>> >> + /*
>> >> + * We can't use the P-state returned by brcm_avs_get_pmap(), since
>> >> + * that's the initial P-state from when the P-map was downloaded to the
>> >> + * AVS co-processor, not necessarily the P-state we are running at now.
>> >> + * So, we get the current P-state explicitly.
>> >> + */
>> >> + return brcm_avs_get_pstate(priv, &priv->pmap.state);
>> >> }
>> >>
>> >> static int brcm_avs_resume(struct cpufreq_policy *policy)
>> >
>> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>>
>> Just wanted to follow up to see if this has been or will be picked up
>> for 4.10?
>
> For 4.10? No way.
I was only thinking 4.10, because it's a fix for an existing driver.
But I am not complaining if it goes into 4.11.
>> I had a quick poke around some trees and did not see it
>> there.
>
> I'm not sure which trees you checked, but it is there in my linux-next branch.
Clearly, I didn't check there, my apologies.
Regards,
-Markus
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2017-02-02 04:40 +0100 |
| Message-ID | <t6gpA-6JE-7@gated-at.bofh.it> |
| In reply to | #1572075 |
On 02-02-17, 00:44, Rafael J. Wysocki wrote:
> On Tuesday, January 31, 2017 10:53:01 AM Markus Mayer wrote:
> > On 5 January 2017 at 20:11, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > On 19-12-16, 12:10, Markus Mayer wrote:
> > >> From: Markus Mayer <mmayer@broadcom.com>
> > >>
> > >> The AVS GET_PMAP command does return a P-state along with the P-map
> > >> information. However, that P-state is the initial P-state when the
> > >> P-map was first downloaded to AVS. It is *not* the current P-state.
> > >>
> > >> Therefore, we explicitly retrieve the P-state using the GET_PSTATE
> > >> command.
> > >>
> > >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> > >> ---
> > >> drivers/cpufreq/brcmstb-avs-cpufreq.c | 13 ++++++++++++-
> > >> 1 file changed, 12 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > >> index 2c6e325..c943606 100644
> > >> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > >> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> > >> @@ -784,8 +784,19 @@ static int brcm_avs_target_index(struct cpufreq_policy *policy,
> > >> static int brcm_avs_suspend(struct cpufreq_policy *policy)
> > >> {
> > >> struct private_data *priv = policy->driver_data;
> > >> + int ret;
> > >> +
> > >> + ret = brcm_avs_get_pmap(priv, &priv->pmap);
> > >> + if (ret)
> > >> + return ret;
> > >>
> > >> - return brcm_avs_get_pmap(priv, &priv->pmap);
> > >> + /*
> > >> + * We can't use the P-state returned by brcm_avs_get_pmap(), since
> > >> + * that's the initial P-state from when the P-map was downloaded to the
> > >> + * AVS co-processor, not necessarily the P-state we are running at now.
> > >> + * So, we get the current P-state explicitly.
> > >> + */
> > >> + return brcm_avs_get_pstate(priv, &priv->pmap.state);
> > >> }
> > >>
> > >> static int brcm_avs_resume(struct cpufreq_policy *policy)
> > >
> > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Just wanted to follow up to see if this has been or will be picked up
> > for 4.10?
>
> For 4.10? No way.
I also thought it might get into 4.10 as these were fixes. Else he would be
required to push them via the 4.10 stable kernel.
--
viresh
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2017-02-02 12:30 +0100 |
| Message-ID | <t6nKp-3ij-13@gated-at.bofh.it> |
| In reply to | #1572132 |
On Thu, Feb 2, 2017 at 4:33 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 02-02-17, 00:44, Rafael J. Wysocki wrote:
>> On Tuesday, January 31, 2017 10:53:01 AM Markus Mayer wrote:
>> > On 5 January 2017 at 20:11, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > > On 19-12-16, 12:10, Markus Mayer wrote:
>> > >> From: Markus Mayer <mmayer@broadcom.com>
>> > >>
>> > >> The AVS GET_PMAP command does return a P-state along with the P-map
>> > >> information. However, that P-state is the initial P-state when the
>> > >> P-map was first downloaded to AVS. It is *not* the current P-state.
>> > >>
>> > >> Therefore, we explicitly retrieve the P-state using the GET_PSTATE
>> > >> command.
>> > >>
>> > >> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> > >> ---
>> > >> drivers/cpufreq/brcmstb-avs-cpufreq.c | 13 ++++++++++++-
>> > >> 1 file changed, 12 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> > >> index 2c6e325..c943606 100644
>> > >> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> > >> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> > >> @@ -784,8 +784,19 @@ static int brcm_avs_target_index(struct cpufreq_policy *policy,
>> > >> static int brcm_avs_suspend(struct cpufreq_policy *policy)
>> > >> {
>> > >> struct private_data *priv = policy->driver_data;
>> > >> + int ret;
>> > >> +
>> > >> + ret = brcm_avs_get_pmap(priv, &priv->pmap);
>> > >> + if (ret)
>> > >> + return ret;
>> > >>
>> > >> - return brcm_avs_get_pmap(priv, &priv->pmap);
>> > >> + /*
>> > >> + * We can't use the P-state returned by brcm_avs_get_pmap(), since
>> > >> + * that's the initial P-state from when the P-map was downloaded to the
>> > >> + * AVS co-processor, not necessarily the P-state we are running at now.
>> > >> + * So, we get the current P-state explicitly.
>> > >> + */
>> > >> + return brcm_avs_get_pstate(priv, &priv->pmap.state);
>> > >> }
>> > >>
>> > >> static int brcm_avs_resume(struct cpufreq_policy *policy)
>> > >
>> > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > Just wanted to follow up to see if this has been or will be picked up
>> > for 4.10?
>>
>> For 4.10? No way.
>
> I also thought it might get into 4.10 as these were fixes. Else he would be
> required to push them via the 4.10 stable kernel.
We'll see.
There are other fixes I may want to push for 4.10 and I can bundle
this thing with them if I decide to send one more pull request for
4.10 after all.
Thanks,
Rafael
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web