Dear Alan,
Something is miss understanding!!
2011/6/2 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Thu, 2 Jun 2011, Soho Soho123 wrote:
>
>> Dear Alan,
>>
>> in this e-mail that you mentioned below:
>>
>> linux 2.6.30 has bug, it can not check wrong schedule index for re-submit urb.
>> But today we do the verification:
>> We measure CPU cycles for :
>> 1. decode function in UVC complete call back function
>> 2. big for loop in scan_periodic
>> We compare the result between 2.6.30 and update code we used.
>> UVC driver is the same, the big difference is
>> A: 2.6.30: NO any update for USB subsystem and usb host driver
>> B: update code we used : included ehci schedule patch up to 2.6.39
>> and we disable "printk" when submit urb error in iso_stream_schedule()
>> and complete call back function, since that will cause cpu cycle
>> inaccuracy.
>
> Okay, that sounds like a good idea.
>
>> =================================================
>> Result:
>> in CPU cycle:
>> we do not find any strange. becasue we save some data to array, then
>> dump data by command. and both code does not trigger the threshold
>> that we set to treat error case.
>> it means : decode function in UVC driver and scan_periodic do not
>> cause long irq latency, when we use Code B for testing, IP cam is
>> dissconnect but the error case do not triggered.
>
> I don't understand. If the camera is disconnected from the USB bus,
> there's nothing to test!
Soho: I mean :there is not any streaming data to client(networking).
Not USB disconnect.
>
>> ==========================================================
>>
>> it seems the irq latency is not cause. The cause mybe the check rule
>> for schedule index.
>> it seems something wrong about maintenance of iso schedule index in
>> new ehci code.
>> Do you have any idea?
>
> No, I don't know of anything wrong in the iso scheduling code.
>
> Maybe you can run a test where you print out the CPU cycle counter:
>
> Just before the start of the big "for" loop in scan_periodic()
> (also print out the values of now_uframe and clock);
>
> Just after the "restart:" statement label (also print out the
> value of now_uframe);
>
> And just after the call to itd_complete().
>
> Try this for the 2.6.30 kernel and also with the updated ehci-hcd
> driver. Seeing the numbers might help me to figure out the problem.
>
Soho: Let me explain how to measure CPU cycle that we used:
there is a "enter point" and a "exit point" , then we
calculate cpu cycle :
count in exit point - count in enter point
"enter point" and "exit point" should be a pair, such that
we can know the count from begin to end
Could you explain the meaning of yours? As my understanding,
1. I put the enter point in before "big" for loop, but where I can
put the exit point for the first pair?
2. I put the enter point after the line "restart" label, but where I
can put the exit point for this pair?
> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
