On 06/14/2012 01:27 AM, Malcolm Priestley wrote:
dvb_usb_v2 [RFC] use delayed work. The problem with an ordinary work queue it executes immediately. changes made 1. Three extra states added DVB_USB_STATE_PROBE, DVB_USB_STATE_COLD and DVB_USB_STATE_WARM. 2. Initialise of priv moved to probe this shouldn't really be done in the work queue. 3. The initial delay 200ms waits for the probe to clear. 4. State DVB_USB_STATE_PROBE checks for interface to be BOUND then calls the identify_state(possibly extra timeout signals needed if binding fails). 5. The next schedule time now increases to 500ms execution following as before with state changing accordingly. 6. DVB_USB_STATE_INIT uses the value of 0x7 so clears the other states. The work queue then dies forever. However, it could continue on as the remote work.
One question before I start to review those changes: as I explained firmware loading my earlier mail, are these changes valid any-more?
It sounds a little bit weird if I haven't meet these problems as I have tested those using multiple devices. af9015, anysee, ec168, au6610 and Cypress FX2 with warm/cold IDs.
regards Antti -- http://palosaari.fi/ -- 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
