David Brownell wrote: >>If INTs could be queued, there would not really even be a need to >>'resubmit' the URBs. The completion handler can simply resubmit a >>completed URB (if desired) without any loss of data or polling time. >> > >For the record, this is going down the path of the "support >multi-buffering" proposal I sketched out (API change #2) ... >you might look at that a bit more, and share comments on >that part of the original RFC. > >One difference between that and what Roman sketched >was that I did was in the model for schedule management: > >- He suggested a new HCD level "set_endpoint_properties" > call (perhaps coupled to set_config and set_interface?) > to schedule the bandwidth. > This is just the old idea of a static, consistent and valid 'endpoint property descriptor'. Basically a URB is a container that contains the data and has a big label. At the moment we put some informations of an endpoint onto that label (type of transfer, interrupt interval,..) and some other informations of an endpoint into core-structures (toggle bit, max-packet size,...). And labels of two different URBs to an endpoint can contain inconsistent data. So I think a URB should just contain the data/length/status and an address (endpoint/device or pointer to an endpoint descriptor) but not any property of an endpoint.
> >- I'd suggested that the bandwidth would stay scheduled until > after an interrupt transfer completed, there was no transfer > queued. > If I understand you right here, I think you lose the offset (or phase) information of the interrupt schedule of the endpoint. E.g. if we send single shot interrupt URBs every 10ms to a 255ms endpoint. Then I think the transfer should take place every 255 ms. With your model there would be a transfer every 10ms. - Roman > >Yes, I tend to think that it might be worth breaking existing >interrupt transfer code in this way to get an improved API. >But it'd be work... > >- Dave > >p.s. I have similar comments about ISO transfers... :) > > Apart from some wire-level differences, the main > structural difference between INTR and ISO is > supposed to be that (a) no lowspeed ISO, (b) for > fullspeed, INTR has a smaller maxpacket (64 bytes > vs 1023 for ISO), (c) at all speeds, errors on INTR > transfers are supposed to get retried, but ISO ones > get reported. Both are supposed to respect the > endpoint poll period, and "high bandwidth" mode > (up to 24 MByte/sec, highspeed) works much the same. > > In short, we may want to consider corresponding > updates to the ISO transfer model, since it's not > intended to be as different from the INTR one as > it is today in Linux. > > > > > _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
