[Question] about patch: don't use [delayed_]work_pending()
From: qiaozhou
Date: Thu Sep 01 2016 - 05:25:59 EST
Hi Tejun,
I have a question related with below patch, and need your suggestion.
In our system, we do cpu clock init in of_clk_init path, and use pm qos
to maintain cpu/cci clock. Firstly we init a CCI_CLK_QOS and set a
default value, then update CCI_CLK_QOS to limit CCI min frequency
according to current cpu frequency. Before calling
pm_qos_update_request, irq is disabled, but after the calling, irq is
enabled in cancel_delayed_work_sync, which causes some inconvenience
before Before this patch is applied, it checks pending work and won't do
cancel_delayed_work_sync in this boot up phase.
The simple calling sequence is like this:
start_kernel -> of_clk_init -> cpu_clk_init -> pm_qos_add_request(xx,
default_value),
then pm_qos_update_request.
I don't know whether it's meaningful to still check pending work here,
or it's not suggested to use pm_qos_update_request in this early boot up
phase. Could you help to share some opinions? (I can fix this issue by
adding the current qos value directly instead of default value, though.)
Thanks a lot.
commit ed1ac6e91a3ff7c561008ba57747cd6cbc49385e
Author: Tejun Heo <tj@xxxxxxxxxx>
Date: Fri Jan 11 13:37:33 2013 +0100
PM: don't use [delayed_]work_pending()
There's no need to test whether a (delayed) work item is pending
before queueing, flushing or cancelling it, so remove work_pending()
tests used in those cases.
Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
...
@@ -359,8 +359,7 @@ void pm_qos_update_request(struct pm_qos_request *req,
return;
}
- if (delayed_work_pending(&req->work))
- cancel_delayed_work_sync(&req->work);
+ cancel_delayed_work_sync(&req->work);
...
Best Regards
Qiao