David Brownell wrote: > >GOAL: support INTR-OUT and INTR-IN transfers with >one API model which could also be used for a device >controller API using an URB-like model. > > >CURRENT MODEL: all interrupt transfers are specified >with using an URB with transfer_buffer_length set to a >fixed packet size, and a fixed polling interval. Also, >current host controller drivers say only one interrupt URB >(usually of at most maxpacketsize) may be queued. > usb-ohci allows to queue interrupt URBs. If you want to keep a 1ms interrupt endpoint bussy you have to queue interrupt URBs.
The current model lacks the phase (or offset) of the polling interval. Also for queued URBs the 'fixed' polling intervall could be changed from URB to URB ( inconsistently). The model as I think it should be: For each interrupt endpoint there are scheduled time slots (offset and interval) for the transfer of data. This is a property of the endpoint and should be defined by 'set interface' (needs a new API (set_endpoint_properties) call for HCDs because at least ohci would benefit of static endpoint properties). Now, at a scheduled time slot if there is a queued URB it will be transfered - if there is no queued URB then there is no transfer. The resubmition of the URBs is a different story but maybe we should define a consistent way of resubmition for all kinds of transfers. Also during the callback the URB is owned by the device driver so length and databuffer can be changed. - Roman _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
