On Wednesday 16 November 2005 2:53 am, Manjunath B S wrote: > b. When I try to dump raw data onto the dsp device file, the Host > Controller issues a FATAL. This problem is easily reproduced by > dumping a very large file onto the dsp device file.
Yes, the ISO support is still EXPERIMENTAL. Seems to work OK until multi-microframe transactions kick in. I never had time to put together a good enough test setup for those. > While looking into the sources, I found a couple of issues and have > fixed the same. I would like to confirm the changes before submission. > > i. In the scan_periodic() (ehci-sched.c) the ISO caching is not taken > into consideration and in case of periodically scheduled SITD's with > IOC set, the interrupt is raised with the precision as configured by > log2_irq_thresh parameter (ehci-hcd.c). When the IOC is raised, the > periodic schedule is altered. Section 4.7.2.1 of the EHCI spec says that the caching applies to how the controller prefetches schedule information ... so it's used when scheduling, not when scanning for completions. I'm not sure why you think scan_periodic() should care about how many (S)ITDs may have been cached, since they're only removed from the schedule when they've completed. Are you thinking that the caching affects writeback for partial (S)ITD completion? I don't see that written in the spec, but then I did find the whole "scheduling threshold" discussion to be weak. > ii. With the Interrupt threshold configured for 125 us and the SITD > completing early in the frame, the Interrupt is raised and the > schedule altered, while the Host Controller is still in the same > frame. Some Host Controllers (including the one I'm working on) report > a fatal in these circumstances, in spite of "live" checks in the > scan_periodic logic. The "active" tests are to make sure that when the HC hasn't yet finished with an (S)ITD, the HCD knows it has to re-scan. What's the mechanism you're thinking for the FATAL error? Would it suffice to stop scanning (S)ITD entries -- only if caching is done! -- as soon as an active one is found? That'd get tricky, since not all (S)ITDs cause IRQs, and the interrupt QH entries would still need to be scanned... I don't much like the way ISO data structures work. It'd be better (from the software perspective) if ISO transfers just had queues of TDs ... that is, working more like OHCI than like UHCI. > In my opinion, we should refrain from scanning the live frame which > the Host Controller is currently reading and read only till the end of > previous frame. Why? > But this logic with Interrupt threshold less than 1 ms > precision will break the Isochronous behaviour 'coz it will not read > the last completed packet descriptor. Could you explain? It's intended to work regardless of the IRQ threshold, by scanning everything that could have been completed since the last IRQ. > I've configured the Interrupt > threshold to be 1ms and have tested the logic and it is working fine. A high IRQ threshold (increased latency) will slow down various things that don't relate to ISO transfers at all. > c. The function tt_no_collision() (ehci-sched.c) called from > sitd_slot_ok(), is passed wrong period. tt_no_collision() expects the > period in terms of frames. The call passes "period_uframes << 3", which is the period in frames... > d. In the function sitd_slot_ok(), we are scanning from the first > frame till the end, and tt_no_collision() also scans every frame in > the schedule, is it not sufficient to call tt_no_collision() only once > instead of calling it in a loop in sitd_slot_ok() ?? The scheduling decision is supposed to make sure that the specified slot will always be available. If it only checked one frame, it would overlook collisions in other frames. That said, Dan Streetman is looking at some updates to the TT scheduling logic which should give denser packing of the available TT slots. - Dave ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
