Re: some question about usb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi:

2011/2/9 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Wed, 9 Feb 2011, loody wrote:
>
>> Hi all:
>> I have some questions about usb driver:
>> 1. what is qh->stamp used for?
>
> It is used to prevent the CPU from doing unnecessary and unwanted work.
>
>>     I trace the source and I found it seems only used to increase the
>> performance such that we will avoid re-scan the previous qh.
>
> That's right.
>
>> But if we don't check qh->stamp, in qh_completions, it will return
>> immediately if the qh has been scanned before, since the qtd_list of
>> the qh is empty, right.
>
> What makes you think the qtd_list will be empty?  Didn't you read the
> code in scan_async?
>
>                        /* clean any finished work for this qh */
>                        if (!list_empty (&qh->qtd_list)
>                                        && qh->stamp != ehci->stamp) {
>
> Obviously the call to qh_completions won't occur if the list is empty.

if so, why we still add below adjournment in qh_completions, even we
use unlikely in the "if statement"?
	if (unlikely (list_empty (&qh->qtd_list)))
		return count;

Per your explanation, "qh->stamp is used for prevent the CPU from
doing unnecessary and unwanted work."

If I trace the code in the correct way, "the unnecessary and unwanted
work" is scanning qtd_list and it will be empty after the first time
the qh is been scanned.

The next time we bump to the same qh it will be screen out in the
statement , "if (!list_empty (&qh->qtd_list)", except the qh is
submitted with any new urbs in the past.

Is there any situation that "!list_empty(&qh->qtd_list) && (qh->stamp
== ehci->stamp)"?

>
>> if so, why we still need to check qh->stamp?
>> Meanwhile, there will be 1/8192 chance that 2 stamps be the same,
>> suppose my frame list size is 1024, right?
>
> That's sort of true.  The probability isn't really 1/8192 because of
> other factors.  Still, this could be a bug.  It could be fixed by
> masking out the higher bits from the frame index register and
> incrementing the higher bits of ehci->stamp.  For example:
>
>        ehci->stamp = (ehci->stamp & ~0x1fff) + 0x2000 +
>                (ehci_readl(ehci, &ehci->regs->frame_index) & 0x1fff);
>
>> 2. what is the max value of "Frame index register"
>> I set my frame list size as 1024, in my opinion the max value of
>> "Frame index register" should be 8192, 0x2000.
>
> You probably mean 8191 (0x1fff), not 8192.
>
>> But I found sometimes it will over 0x2000.
>> Does that I calculate the wrong value?
>
> The spec merely says that the upper bits are reserved; it doesn't say
> that they have to be 0.
>
> Alan Stern
>
>

appreciate your kind help
miloody
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux