The cpufreq core now supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis <[email protected]>
---
drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 7694e07..b11fdd6 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -1734,18 +1734,17 @@ static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
static long round_armss_rate(unsigned long rate)
{
+ struct cpufreq_frequency_table *pos;
long freq = 0;
- int i = 0;
/* cpufreq table frequencies is in KHz. */
rate = rate / 1000;
/* Find the corresponding arm opp from the cpufreq table. */
- while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
- freq = db8500_cpufreq_table[i].frequency;
+ cpufreq_for_each_entry(pos, db8500_cpufreq_table) {
+ freq = pos->frequency;
if (freq == rate)
break;
- i++;
}
/* Return the last valid value, even if a match was not found. */
@@ -1886,23 +1885,21 @@ static void set_clock_rate(u8 clock, unsigned long rate)
static int set_armss_rate(unsigned long rate)
{
- int i = 0;
+ struct cpufreq_frequency_table *pos;
/* cpufreq table frequencies is in KHz. */
rate = rate / 1000;
/* Find the corresponding arm opp from the cpufreq table. */
- while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
- if (db8500_cpufreq_table[i].frequency == rate)
+ cpufreq_for_each_entry(pos, db8500_cpufreq_table)
+ if (pos->frequency == rate)
break;
- i++;
- }
- if (db8500_cpufreq_table[i].frequency != rate)
+ if (pos->frequency != rate)
return -EINVAL;
/* Set the new arm opp. */
- return db8500_prcmu_set_arm_opp(db8500_cpufreq_table[i].driver_data);
+ return db8500_prcmu_set_arm_opp(pos->driver_data);
}
static int set_plldsi_rate(unsigned long rate)
--
1.9.0
> The cpufreq core now supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis <[email protected]>
> ---
> drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
Applied untested by me.
Linus if you could find the time to do the honours I'd me much obliged.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 16 April 2014 16:21, Lee Jones <[email protected]> wrote:
>> The cpufreq core now supports the cpufreq_for_each_entry macro helper
>> for iteration over the cpufreq_frequency_table, so use it.
>>
>> It should have no functional changes.
>>
>> Signed-off-by: Stratos Karafotis <[email protected]>
>> ---
>> drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
>> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> Applied untested by me.
Wouldn't build. Let it go via Rafael.
> >> The cpufreq core now supports the cpufreq_for_each_entry macro helper
> >> for iteration over the cpufreq_frequency_table, so use it.
> >>
> >> It should have no functional changes.
> >>
> >> Signed-off-by: Stratos Karafotis <[email protected]>
> >> ---
> >> drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> >> 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> > Applied untested by me.
>
> Wouldn't build. Let it go via Rafael.
Rafael, would you mind creating a branch from this patch set that we
can both pull from please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
The cpufreq core now supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis <[email protected]>
---
drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 7694e07..b11fdd6 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -1734,18 +1734,17 @@ static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
static long round_armss_rate(unsigned long rate)
{
+ struct cpufreq_frequency_table *pos;
long freq = 0;
- int i = 0;
/* cpufreq table frequencies is in KHz. */
rate = rate / 1000;
/* Find the corresponding arm opp from the cpufreq table. */
- while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
- freq = db8500_cpufreq_table[i].frequency;
+ cpufreq_for_each_entry(pos, db8500_cpufreq_table) {
+ freq = pos->frequency;
if (freq == rate)
break;
- i++;
}
/* Return the last valid value, even if a match was not found. */
@@ -1886,23 +1885,21 @@ static void set_clock_rate(u8 clock, unsigned long rate)
static int set_armss_rate(unsigned long rate)
{
- int i = 0;
+ struct cpufreq_frequency_table *pos;
/* cpufreq table frequencies is in KHz. */
rate = rate / 1000;
/* Find the corresponding arm opp from the cpufreq table. */
- while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
- if (db8500_cpufreq_table[i].frequency == rate)
+ cpufreq_for_each_entry(pos, db8500_cpufreq_table)
+ if (pos->frequency == rate)
break;
- i++;
- }
- if (db8500_cpufreq_table[i].frequency != rate)
+ if (pos->frequency != rate)
return -EINVAL;
/* Set the new arm opp. */
- return db8500_prcmu_set_arm_opp(db8500_cpufreq_table[i].driver_data);
+ return db8500_prcmu_set_arm_opp(pos->driver_data);
}
static int set_plldsi_rate(unsigned long rate)
--
1.9.0
> The cpufreq core now supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
> Signed-off-by: Stratos Karafotis <[email protected]>
> ---
It would be good to have a changelog which describes the differences
between the versions, so we can keep track.
> drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
So it looks like I already applied v2 of this patch to my tree. What
changed in v3 and v4? Should I remove that patch from MFD and apply
this one instead?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tuesday, April 22, 2014 08:15:41 AM Lee Jones wrote:
> > The cpufreq core now supports the cpufreq_for_each_entry macro helper
> > for iteration over the cpufreq_frequency_table, so use it.
> >
> > It should have no functional changes.
>
> > Signed-off-by: Stratos Karafotis <[email protected]>
> > ---
>
> It would be good to have a changelog which describes the differences
> between the versions, so we can keep track.
>
> > drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> > 1 file changed, 8 insertions(+), 11 deletions(-)
>
> So it looks like I already applied v2 of this patch to my tree. What
> changed in v3 and v4? Should I remove that patch from MFD and apply
> this one instead?
The reason why v4 was sent is because I asked for it.
And if you applied [5/8] without [1/8], it won't work, because the macro is
introduced by that patch.
If that's the case, please drop [5/8] and let me handle the entire series.
Kind regards,
Rafael
On Tue, 22 Apr 2014, Rafael J. Wysocki wrote:
> On Tuesday, April 22, 2014 08:15:41 AM Lee Jones wrote:
> > > The cpufreq core now supports the cpufreq_for_each_entry macro helper
> > > for iteration over the cpufreq_frequency_table, so use it.
> > >
> > > It should have no functional changes.
> >
> > > Signed-off-by: Stratos Karafotis <[email protected]>
> > > ---
> >
> > It would be good to have a changelog which describes the differences
> > between the versions, so we can keep track.
> >
> > > drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> > > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> > So it looks like I already applied v2 of this patch to my tree. What
> > changed in v3 and v4? Should I remove that patch from MFD and apply
> > this one instead?
>
> The reason why v4 was sent is because I asked for it.
>
> And if you applied [5/8] without [1/8], it won't work, because the macro is
> introduced by that patch.
That's right, which is why I mailed you about it:
> > > Applied untested by me.
> >
> > Wouldn't build. Let it go via Rafael.
>
> Rafael, would you mind creating a branch from this patch set that we
> can both pull from please?
> If that's the case, please drop [5/8] and let me handle the entire series.
I'm happy for you to apply the series and send me a pull-request for
either a) the entire series or b) just the patches which touch MFD and
any subsequent decencies. Or I can apply them and send you one.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> > > The cpufreq core now supports the cpufreq_for_each_entry macro helper
> > > for iteration over the cpufreq_frequency_table, so use it.
> > >
> > > It should have no functional changes.
> >
> > > Signed-off-by: Stratos Karafotis <[email protected]>
> > > ---
> >
> > It would be good to have a changelog which describes the differences
> > between the versions, so we can keep track.
> >
> > > drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> > > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> > So it looks like I already applied v2 of this patch to my tree. What
> > changed in v3 and v4? Should I remove that patch from MFD and apply
> > this one instead?
>
> I'm sorry for the confusion.
> I sent v3 only for patches 1/8 and 3/8.
> So, I was asked by Rafael to resend the entire series as v4
> in order to be clear which is the latest version in each patch.
> Unfortunately, I omit the change log :(
>
> The specific patch (5/8) is unchanged since v2.
>
> I'm sorry for the inconvenience.
That's okay, thanks for clarifying.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tuesday, April 22, 2014 12:27:17 PM Lee Jones wrote:
> On Tue, 22 Apr 2014, Rafael J. Wysocki wrote:
>
> > On Tuesday, April 22, 2014 08:15:41 AM Lee Jones wrote:
> > > > The cpufreq core now supports the cpufreq_for_each_entry macro helper
> > > > for iteration over the cpufreq_frequency_table, so use it.
> > > >
> > > > It should have no functional changes.
> > >
> > > > Signed-off-by: Stratos Karafotis <[email protected]>
> > > > ---
> > >
> > > It would be good to have a changelog which describes the differences
> > > between the versions, so we can keep track.
> > >
> > > > drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> > > > 1 file changed, 8 insertions(+), 11 deletions(-)
> > >
> > > So it looks like I already applied v2 of this patch to my tree. What
> > > changed in v3 and v4? Should I remove that patch from MFD and apply
> > > this one instead?
> >
> > The reason why v4 was sent is because I asked for it.
> >
> > And if you applied [5/8] without [1/8], it won't work, because the macro is
> > introduced by that patch.
>
> That's right, which is why I mailed you about it:
>
> > > > Applied untested by me.
> > >
> > > Wouldn't build. Let it go via Rafael.
> >
> > Rafael, would you mind creating a branch from this patch set that we
> > can both pull from please?
>
> > If that's the case, please drop [5/8] and let me handle the entire series.
>
> I'm happy for you to apply the series and send me a pull-request for
> either a) the entire series or b) just the patches which touch MFD and
> any subsequent decencies. Or I can apply them and send you one.
OK, I'll create a separate branch with those patches and will let you know
where it is.
Kind regards,
Rafael
On Tuesday, April 22, 2014 01:49:31 PM Rafael J. Wysocki wrote:
> On Tuesday, April 22, 2014 12:27:17 PM Lee Jones wrote:
> > On Tue, 22 Apr 2014, Rafael J. Wysocki wrote:
> >
> > > On Tuesday, April 22, 2014 08:15:41 AM Lee Jones wrote:
> > > > > The cpufreq core now supports the cpufreq_for_each_entry macro helper
> > > > > for iteration over the cpufreq_frequency_table, so use it.
> > > > >
> > > > > It should have no functional changes.
> > > >
> > > > > Signed-off-by: Stratos Karafotis <[email protected]>
> > > > > ---
> > > >
> > > > It would be good to have a changelog which describes the differences
> > > > between the versions, so we can keep track.
> > > >
> > > > > drivers/mfd/db8500-prcmu.c | 19 ++++++++-----------
> > > > > 1 file changed, 8 insertions(+), 11 deletions(-)
> > > >
> > > > So it looks like I already applied v2 of this patch to my tree. What
> > > > changed in v3 and v4? Should I remove that patch from MFD and apply
> > > > this one instead?
> > >
> > > The reason why v4 was sent is because I asked for it.
> > >
> > > And if you applied [5/8] without [1/8], it won't work, because the macro is
> > > introduced by that patch.
> >
> > That's right, which is why I mailed you about it:
> >
> > > > > Applied untested by me.
> > > >
> > > > Wouldn't build. Let it go via Rafael.
> > >
> > > Rafael, would you mind creating a branch from this patch set that we
> > > can both pull from please?
> >
> > > If that's the case, please drop [5/8] and let me handle the entire series.
> >
> > I'm happy for you to apply the series and send me a pull-request for
> > either a) the entire series or b) just the patches which touch MFD and
> > any subsequent decencies. Or I can apply them and send you one.
>
> OK, I'll create a separate branch with those patches and will let you know
> where it is.
This material is on the cpufreq-macros branch of the linux-pm.git tree now, so
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git cpufreq-macros
will be safe to pull from going forward.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.