[pvrusb2] pvrusb2 and suspend.
Mike Isely
isely at isely.net
Wed Aug 16 09:26:48 CDT 2006
On Wed, 16 Aug 2006, xavier.gnata at free.fr wrote:
> Well, I think you can do the same job (for suspend) as when the cable is
> unpluged during the streaming. In this case, we close all the stuff correctly
> don't we?
> Xavier
>
"We" don't close everything. The application does. When the cable is
pulled, the driver disassociates itself from the USB port and tears down
any internal connectivity it has with the port. However, all other
connections (i.e. open file handles) are still present - and can't go away
until the referencing entit(ies) close these down. What happens in
reality is that the next time the application tries to do something to the
device it will get an error in response - since the hardware is now gone.
Then the application is supposed to close its connection. If the app was
blocked on a read when the cable is pulled, then the read() will be
satisfied with an error. If an I2C chip-driver module (e.g. tuner.ko,
msp3400.ko, etc) tries to issue an I2C transaction then the transaction
will fail. The pvrusb2 driver at the moment won't disconnect those
modules, but as soon as the last file handle is shut, then the driver will
tear down all the rest of its internal state, which will cause the I2C
adapter to tear down and then the modules will be forced out.
On a suspend obviously we can treat it like the cable was pulled. But it
is not clear to me what has to happen on the other side of the driver.
I'm just not very up-to-speed on how suspend is supposed to work.
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
More information about the pvrusb2
mailing list