On Mon, Oct 18, 2010 at 9:20 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > >> On Sun, Oct 17, 2010 at 8:52 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>> On Sunday, October 17, 2010 14:26:18 Hans Verkuil wrote: >>>> - serialize the suspend and resume functions using the global lock. >>>> - do not call usb_autopm_put_interface after a disconnect. >>>> - fix a race when disconnecting the device. >>> >>> Regarding autosuspend: something seems to work since the >>> power/runtime_status >>> attribute goes from 'suspended' to 'active' whenever the radio handle is >>> open. >>> But the suspend and resume functions are never called. I can't figure >>> out >>> why not. I don't see anything strange. >>> >>> The whole autopm stuff is highly suspect anyway on a device like this >>> since >>> it is perfectly reasonable to just set a frequency and exit. The audio >>> is >>> just going to the line-in anyway. In other words: not having the device >>> node >>> open does not mean that the device is idle and can be suspended. >>> >>> My proposal would be to rip out the whole autosuspend business from this >>> driver. I've no idea why it is here at all. >>> >>> Regards, >>> >>> Hans >> >> Hans, I highly agree with that analysis. The original author put that >> code in. But like you, I'm not sure if it was ever really valid. Since >> I didn't have anything to test with, I left it untouched. >> >> Regards, >> >> David Ellingsworth >> >> > > OK, then I'll make a new patch that just rips out autosuspend support. I thought about this a little more. I think this driver could benefit from auto-suspend, but it's current implementation is indeed flawed. The calls to usb_autopm_put/get_interface could occur whenever the device is muted/unmuted respectively after the device has been initialized. Thus, the suspend should not happen while the device is in use per se, but could occur after it's been muted. Regards, David Ellingsworth -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
