Re: [linux-usb-devel] USB deadlock after resume

[Laurent Pinchart <laurent.pinchart@skynet.be>]

On Wednesday 21 November 2007, Oliver Neukum wrote:
> Am Mittwoch 21 November 2007 schrieb Felipe Balbi:
> > > Do you know any good way for performing a softreset within the driver?
> > > The video application should get a continuous datastream after
> > > resuming the notebook, so the driver shouldn't be unloaded.
> > > The driver also keeps a list of previous camera settings which should
> > > be set up again after resuming. Stopping the video application and
> > > reattaching the device using ACPI (this board supports reconnecting
> > > the device using ACPI) should be avoided.
> >
> > When you suspend, you cut off vbus (afaik, correct me if I'm wrong),
> > which means your device will get disconnected. One way to avoid this is
> > enabling CONFIG_USB_PERSIST and trying with that on.
>
> Suspend may or may not cut off power.

I've always been confused by this.

If I'm not mistaken, there are three kind of suspend modes: autosuspend, 
suspend to RAM and suspend to disk. In the first case I expect the USB hub 
(either root hub or external hub) to make the bus idle but not power it down. 
In the last case I suspect the USB bus to be powered down.

What controls the USB bus power on suspended ports ? Is it handled by the 
system (BIOS, ...) ? Is it allowed to power down the ports or keep them 
powered as it chooses ? What are the rules set in stone ?

> If it does cut off power, resume() will never be called, instead either
> disconnect() or reset_resume(). 

What is reset_resume() for ? Which one will be called on resume after a bus 
power down ?

Best regards,

Laurent Pinchart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/