Hello All,
Thanks a lot for your reply, I have redone all the tests again to
confirm my observations. I am yet to port the kernel onto the latest
kernel and verify the observations in the same. Please find my reply
inline...
On 11/17/05, David Brownell <[EMAIL PROTECTED]> wrote:
> 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?
>
My observations on the Board I'm testing was such. I tried redoing the
same test with Interrupt threshold of 125us unaltered (ehci-hcd.c) and
scanning till the previous uframe instead of the current uframe but
the problem still occured. I dont have the right explanation for this
kind of behaviour but the I fix I suggested definitely worked for me.
I suggested altering the scanning logic to the previous frame with
Interrupt threshold of 1 ms because my observation was that Caching
affects writeback. In my opinion, it would be great to confirm this
observations on other boards as well, before applying this thought.
> > 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.
Well with the Interrupt threshold set at 1ms, the Interrupt is raised
at at the next frame boundary of the completed packet descriptor,
which ensures that the packet descriptor is always scanned, even when
the scanning logic scans till the previous frame.
Its true that scanning logic should work irrespective of IRQ
threshold, but as I mentioned earlier we can alter this based on
observations on other boards and other EHCI Iso devices.
>
>
> > 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...
>
I think it should be "period_uframes >> 3" instead..
>
> > 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.
sitd_slot_ok() gets called from iso_stream_schedule() to check if the
stream can be scheduled in any micro frame within the period. The
function sitd_slot_ok() checks through all the frames with the given
interval from the beginning with the logic below:
/* check bandwidth */
uframe %= period_uframes;
do {
frame = uframe >> 3;
==
if (!tt_no_collision (ehci, period_uframes << 3,
stream->udev, frame, mask))
return 0;
==
/* we know urb->interval is 2^N uframes */
uframe += period_uframes;
} while (uframe < mod);
Effectively we are trying to see if we can fit the Iso stream for one
complete schedule given the interval and the schedule size. So we scan
thru every frame from the starting interval till end of schedule to
see if there are no collisions.
tt_no_collision() also looks through all the frames in the periodic
schedule starting from the given frame till the end of the schedule.
At the first step itself we would have scanned all the frames in the
schedule to see if there are any collisions, but then we loop again
repetitively. Also since we are holding the ehci->lock at this
instance, this would be cumbersome given the fact that the schedule
would not be altered during this interval.
I think, the logic would still hold good if we moved tt_no_collision()
out of the loop.
Also sitd_slot_ok() does not use ehci_iso_sched, this could be removed.
>
> - Dave
>
>
Please let me know your thoughts regarding the same.
Regards,
/Manjunath B.S.
-------------------------------------------------------
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_idv28&alloc_id845&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
