| Message ID | 5355A349.50908@semaphore.gr (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
> 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 <stratosk@semaphore.gr> > --- 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?
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 <stratosk@semaphore.gr> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <stratosk@semaphore.gr> > > > --- > > > > 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.
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 <stratosk@semaphore.gr> > > > > --- > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <stratosk@semaphore.gr> > > > > > --- > > > > > > > > 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!
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)
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 <stratosk@semaphore.gr> --- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)