* RE: [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq() sometimes can't get correct CPU frequency
@ 2015-11-30 8:04 ` Zhang, Lin-Bao (Linux Kernel R&D)
0 siblings, 0 replies; 3+ messages in thread
From: Zhang, Lin-Bao (Linux Kernel R&D) @ 2015-11-30 8:04 UTC (permalink / raw)
To: rjw, viresh.kumar, linux-pm, linux-kernel; +Cc: Knippers, Linda, Pearson, Greg
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 3530 bytes --]
Hi all,
About this patch , do you have any comments ?
Thanks for your any comments , corrections and etc.
Thanks very much!
Followings are last emails :
https://lkml.org/lkml/2015/11/16/132
https://lkml.org/lkml/2015/11/16/133
https://lkml.org/lkml/2015/11/16/140
-Bob
> -----Original Message-----
> From: Zhang, Lin-Bao (Linux Kernel R&D)
> Sent: 2015Äê11ÔÂ16ÈÕ 18:36
> To: 'rjw@rjwysocki.net'; 'viresh.kumar@linaro.org'; 'linux-pm@vger.kernel.org';
> 'linux-kernel@vger.kernel.org'
> Subject: [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq()
> sometimes can't get correct CPU frequency
>
>
> Summary :
>
> These 2 patches are developed for drivers/cpufreq/pcc-cpufreq.c's
> pcc_get_freq() function.
> The pcc-cpufreq driver's function pcc_get_freq() sometimes returns invalid
> frequency information.
> Without the these 2 patches , it can be reproduced on booting Linux Kernel with
> loading pcc-cpufreq.ko and loop unloading/loading pcc-cpufreq.ko.
> This problem has been reported on ProLiant systems, primarily 4-socket systems,
> for example DL580Gen8.
>
> Generally speaking, as PCC spec,patch 1 can ideally ensure to get correct cpu
> freqency if FW works well.
> if it fails, patch 2 can be run to retry 2 times to get cpu freq as workaround.
>
> These 2 patches are written by HP's greg.pearson@hpe.com , enhanced/verified
> by Linbao.zhang@hpe.com
>
> PATCH 1/2:
> in Processor Clocking Control specification v1.0 ,there are 2 limitations :
> 2.1.8 Minimum Time Between Commands
> 2.1.9 Maximum Time Between Commands
> that means 2 commands' interval should be located between Minimum Time
> Between Commands and Maximum
>
> Time Between Commands.
> this patch implements this feature,while old pcc-cpufreq.c didn't strictly follow
> the spec.
> ideally , this patch ensure pcc_get_freq() return valid freq based on the fact FW
> is working well.
>
> PATCH 2/2:
> if pcc_get_freq() returns 0, we will retry 2 times at most. This is a workaround
> patch, although it is 100% perfect.This works around a firmware/timing issue. In
> very rare case , it also will fail after retrying 2 times due to firmware issue. Based
> on current pcc cpufreq design , this workaround would be the best solution by
> confirmation with FW guys. patch 2 has been adoted by sles11sp4.
>
> Detailed testing data can be found as following :
>
> our testing result on DL580Gen8 with upstream kernel:
> a) loop unloading/loading pcc driver within 14 hours , pcc_get_freq() always
> succeed , the patch always succeeded, don't need the second patch to
> workaround
> b) loop rebooting DL580Gen8 with git kernel: by writting a shell script, found
> about rebooting 200+ times, patch 1 and patch 2 may both failed once, means
> pcc_get_freq() returns 0 frequency,although its possibility is very very low.
> pcc_get_freq() doesn't affect pcc-cpufreq driver loading ,because they are
> running different path.
> in this loop rebooting test , pcc-cpufreq can always be loaded successfully.
>
> We can say ,patch 1 and patch 2 would be the best solution for this issue.
>
> Zhang Lin-Bao (2):
> enforce max/min time between commands
> retry 2 times when getting cpu frequency is zero
>
> drivers/cpufreq/pcc-cpufreq.c | 51
> ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> --
> 1.8.5.2
>
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq() sometimes can't get correct CPU frequency
@ 2015-11-30 8:04 ` Zhang, Lin-Bao (Linux Kernel R&D)
0 siblings, 0 replies; 3+ messages in thread
From: Zhang, Lin-Bao (Linux Kernel R&D) @ 2015-11-30 8:04 UTC (permalink / raw)
To: rjw, viresh.kumar, linux-pm, linux-kernel; +Cc: Knippers, Linda, Pearson, Greg
Hi all,
About this patch , do you have any comments ?
Thanks for your any comments , corrections and etc.
Thanks very much!
Followings are last emails :
https://lkml.org/lkml/2015/11/16/132
https://lkml.org/lkml/2015/11/16/133
https://lkml.org/lkml/2015/11/16/140
-Bob
> -----Original Message-----
> From: Zhang, Lin-Bao (Linux Kernel R&D)
> Sent: 2015年11月16日 18:36
> To: 'rjw@rjwysocki.net'; 'viresh.kumar@linaro.org'; 'linux-pm@vger.kernel.org';
> 'linux-kernel@vger.kernel.org'
> Subject: [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq()
> sometimes can't get correct CPU frequency
>
>
> Summary :
>
> These 2 patches are developed for drivers/cpufreq/pcc-cpufreq.c's
> pcc_get_freq() function.
> The pcc-cpufreq driver's function pcc_get_freq() sometimes returns invalid
> frequency information.
> Without the these 2 patches , it can be reproduced on booting Linux Kernel with
> loading pcc-cpufreq.ko and loop unloading/loading pcc-cpufreq.ko.
> This problem has been reported on ProLiant systems, primarily 4-socket systems,
> for example DL580Gen8.
>
> Generally speaking, as PCC spec,patch 1 can ideally ensure to get correct cpu
> freqency if FW works well.
> if it fails, patch 2 can be run to retry 2 times to get cpu freq as workaround.
>
> These 2 patches are written by HP's greg.pearson@hpe.com , enhanced/verified
> by Linbao.zhang@hpe.com
>
> PATCH 1/2:
> in Processor Clocking Control specification v1.0 ,there are 2 limitations :
> 2.1.8 Minimum Time Between Commands
> 2.1.9 Maximum Time Between Commands
> that means 2 commands' interval should be located between Minimum Time
> Between Commands and Maximum
>
> Time Between Commands.
> this patch implements this feature,while old pcc-cpufreq.c didn't strictly follow
> the spec.
> ideally , this patch ensure pcc_get_freq() return valid freq based on the fact FW
> is working well.
>
> PATCH 2/2:
> if pcc_get_freq() returns 0, we will retry 2 times at most. This is a workaround
> patch, although it is 100% perfect.This works around a firmware/timing issue. In
> very rare case , it also will fail after retrying 2 times due to firmware issue. Based
> on current pcc cpufreq design , this workaround would be the best solution by
> confirmation with FW guys. patch 2 has been adoted by sles11sp4.
>
> Detailed testing data can be found as following :
>
> our testing result on DL580Gen8 with upstream kernel:
> a) loop unloading/loading pcc driver within 14 hours , pcc_get_freq() always
> succeed , the patch always succeeded, don't need the second patch to
> workaround
> b) loop rebooting DL580Gen8 with git kernel: by writting a shell script, found
> about rebooting 200+ times, patch 1 and patch 2 may both failed once, means
> pcc_get_freq() returns 0 frequency,although its possibility is very very low.
> pcc_get_freq() doesn't affect pcc-cpufreq driver loading ,because they are
> running different path.
> in this loop rebooting test , pcc-cpufreq can always be loaded successfully.
>
> We can say ,patch 1 and patch 2 would be the best solution for this issue.
>
> Zhang Lin-Bao (2):
> enforce max/min time between commands
> retry 2 times when getting cpu frequency is zero
>
> drivers/cpufreq/pcc-cpufreq.c | 51
> ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 50 insertions(+), 1 deletion(-)
>
> --
> 1.8.5.2
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq() sometimes can't get correct CPU frequency
@ 2015-11-16 10:35 Zhang, Lin-Bao (Linux Kernel R&D)
0 siblings, 0 replies; 3+ messages in thread
From: Zhang, Lin-Bao (Linux Kernel R&D) @ 2015-11-16 10:35 UTC (permalink / raw)
To: rjw, viresh.kumar, linux-pm, linux-kernel
Summary :
These 2 patches are developed for drivers/cpufreq/pcc-cpufreq.c's pcc_get_freq() function.
The pcc-cpufreq driver's function pcc_get_freq() sometimes returns invalid frequency information.
Without the these 2 patches , it can be reproduced on booting Linux Kernel with loading pcc-cpufreq.ko and loop unloading/loading pcc-cpufreq.ko.
This problem has been reported on ProLiant systems, primarily 4-socket systems, for example DL580Gen8.
Generally speaking, as PCC spec,patch 1 can ideally ensure to get correct cpu freqency if FW works well.
if it fails, patch 2 can be run to retry 2 times to get cpu freq as workaround.
These 2 patches are written by HP's greg.pearson@hpe.com , enhanced/verified by Linbao.zhang@hpe.com
PATCH 1/2:
in Processor Clocking Control specification v1.0 ,there are 2 limitations :
2.1.8 Minimum Time Between Commands
2.1.9 Maximum Time Between Commands
that means 2 commands' interval should be located between Minimum Time Between Commands and Maximum
Time Between Commands.
this patch implements this feature,while old pcc-cpufreq.c didn't strictly follow the spec.
ideally , this patch ensure pcc_get_freq() return valid freq based on the fact FW is working well.
PATCH 2/2:
if pcc_get_freq() returns 0, we will retry 2 times at most. This is a workaround patch, although it is 100% perfect.This works around a firmware/timing issue. In very rare case , it also will fail after retrying 2 times due to firmware issue. Based on current pcc cpufreq design , this workaround would be the best solution by confirmation with FW guys. patch 2 has been adoted by sles11sp4.
Detailed testing data can be found as following :
our testing result on DL580Gen8 with upstream kernel:
a) loop unloading/loading pcc driver within 14 hours , pcc_get_freq() always succeed , the patch always succeeded, don't need the second patch to workaround
b) loop rebooting DL580Gen8 with git kernel: by writting a shell script, found about rebooting 200+ times, patch 1 and patch 2 may both failed once, means pcc_get_freq() returns 0 frequency,although its possibility is very very low.
pcc_get_freq() doesn't affect pcc-cpufreq driver loading ,because they are running different path.
in this loop rebooting test , pcc-cpufreq can always be loaded successfully.
We can say ,patch 1 and patch 2 would be the best solution for this issue.
Zhang Lin-Bao (2):
enforce max/min time between commands
retry 2 times when getting cpu frequency is zero
drivers/cpufreq/pcc-cpufreq.c | 51 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
--
1.8.5.2
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-30 8:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-30 8:04 [PATCH v1 0/2] fix the defect that pcc-cpufreq's pcc_get_freq() sometimes can't get correct CPU frequency Zhang, Lin-Bao (Linux Kernel R&D)
2015-11-30 8:04 ` Zhang, Lin-Bao (Linux Kernel R&D)
-- strict thread matches above, loose matches on Subject: below --
2015-11-16 10:35 Zhang, Lin-Bao (Linux Kernel R&D)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.