[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