[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACVXFVMFZJioG_vgJ_tx9rA8_=H0HcKZLCyLcTu8oSSSmUoNJg@mail.gmail.com>
Date: Wed, 14 Sep 2011 09:12:35 +0800
From: Ming Lei <tom.leiming@...il.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux-sh list <linux-sh@...r.kernel.org>,
Magnus Damm <magnus.damm@...il.com>,
Kevin Hilman <khilman@...com>, jean.pihet@...oldbits.com
Subject: Re: [PATCH 2/5] PM / Runtime: Do not run callbacks under lock for
power.irq_safe set
Hi,
On Wed, Sep 14, 2011 at 12:06 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> If power.lock is released, the transition states(resuming or suspending)
>> >
>> >> may be observed in rpm_suspend or rpm_resume, then tasks schedule
>> >
>> >> will be produced in these two functions,
>> >
>> > I don't think so, because the interrupts are still off.
>>
>> Yes, the interrupts are still off on local CPU, but the release of spin lock may
>> cause another CPUs to run into rpm_suspend or rpm_resume and produce
>> task schedule inside the two functions.
>
> Not for the same device, though.
I think it is probable to happen on the same device in theory, see below:
- suppose irq_safe is set before calling two pm_runtime_suspend below
- suppose this patch has been applied
CPU0 CPU1
pm_runtime_suspend
acquired power lock
rpm_suspend
pm_runtime_suspend
spining power lock
...
release power lock
acquired power lock
run .runtime_suspend
found the dev suspending
wait for power state and schedule
>
> Also, I'm not quite sure what scenario exactly are you referring to.
> Could you please give an example?
I have no actual examples about it, just a theory analysis.
Also, maybe the patch below can avoid the race above.
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index a6750fc..87c9a37 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -150,6 +150,9 @@ static int rpm_check_suspend_allowed(struct device *dev)
retval = -EAGAIN;
else if (dev->power.runtime_status == RPM_SUSPENDED)
retval = 1;
+ else if (dev->power.runtime_status != RPM_ACTIVE &&
+ dev->power.irq_safe)
+ retval = -EAGAIN;
return retval;
}
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists