On Fri, 20 Jul 2007 [email protected] wrote:
> > How would you prevent tasks from being scheduled? How would you
> > prevent drivers from deadlocking because in order to put their device
> > in a low-power state they need to acquire a lock which is held by a
> > user task?
>
> you give up on the suspend becouse you have no way of getting the user
> task to give up the lock.
Once the deadlock has occurred it's too late. You can't give up; in
fact you can't do anything at all. The system has hung.
> however, kernel locks should not be held by user tasks, user tasks are not
> expected to behave in rational ways, allowing them to compete with kernel
> tasks for locks is a sure way to get a deadlock or indefinate stall.
What on Earth are you talking about? "Kernel locks should not be held
by user tasks"? Then who _should_ hold them? You are aware, I hope,
that down() and mutex_lock() can be called only in process context?
> what locks are accessed this way?
Lots of them. For example, most drivers won't want a suspend to occur
right in the middle of an I/O transfer. To prevent this, the driver
might use a mutex. The task doing the I/O (which will be a user task)
acquires the mutex during a transfer and the suspend routine acquires
the mutex while quiescing the device.
> >> Does it really (fundamentally) require scheduling tasks, particularly in
> >> the case that the devices have already been put in the "quiesced" state?
> >
> > I can't say for sure. That's the way we have been doing it. It
> > wouldn't be easy to change, because the driver would have to busy-wait
> > during delays -- which would mean it would need to use different code
> > for system-wide suspend and runtime suspend.
>
> please define terms so that we are all on the same page
Please read Documentation/power/devices.txt.
> what do you mean by
> system-wide suspend
That's what you would call standby, suspend-to-RAM, or hibernate. The
entire system goes to sleep.
> runtime suspend
That's when an individual device is placed in a low-power state to
save energy while it isn't being used. The system as a whole remains
awake and the device will be resumed the next time it is needed for
anything.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
