grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Long USB transfers problem


From: Aleš Nesrsta
Subject: Re: [PATCH] Long USB transfers problem
Date: Tue, 12 Feb 2013 00:13:28 +0100

Hi Vladimir,

in some e-mail in this thread You wrote:
> Can this be computed from the device info rather than hardwired to 2K?

So, there is "draft" of patch which makes maybe little bit more
sophisticated limiting of bulk transfer length.

How it works:
I added new variable "max_bulk_tds" into USB controller structure
"grub_usb_controller_dev". This value is controller specific, i.e. it is
set inside each USB controller driver during its registering.
Meaning of this variable is simple: How much TDs can be maximally used
per one bulk transfer.
This value is used inside function grub_usb_bulk_read together with
value of max. packet length to calculate max. possible bulk transfer
length in bytes - which is used instead of previous constant
MAX_USB_TRANSFER_LEN.
(The constant MAX_USB_TRANSFER_LEN is still used as some "safe value" in
case when max_bulk_tds is set to zero from some reason. This "safety"
code cen be deleted.)

Main problem is how to calculate proper value of "max_bulk_tds".
There shouldn't be maximal count of all TDs - because some TDs should be
reserved for potential simultaneous transfers. Even the GRUB is single
threaded, there can happen some simultaneous transfers (e.g.
"interrupts" for hubs or keyboards, possibly bulk transfer related to
USB/RS232 converter etc.) - all these transfers uses the same "heap" of
TDs (but, fortunately, they are using only few TDs, usually approx. 1-8
per each such transfer).

There is a problem to estimate how much devices could simultaneously
communicate in all real cases.
The only one thing which I hope I can expect (according to actual GRUB
single-threading) is: There should be no more than one "large" (i.e.
disc related) bulk transfer at the same time. (If this will be not
valid, then it will be necessary to do something else to prevent TDs
"exhausting".)

So, initially I tried to use very simple calculating/estimating of
"max_bulk_tds" = max. count of TDs * 3/4.
As the count of all TDs is usually about 600 in each kind of USB driver,
I hope there will be more than sufficient amount of "reserved" TDs and
also relative big count of TDs for large bulk transfer.

But, unfortunately, we still have some hardwired numbers here - only
with another meaning (maybe potentially more reasonable - ?) and
controller-specific (if necessary).

What do you prefer - this "improved" bulk transfer limiting or the
simple original one?

BR,
Ales

Attachment: usb_patch_130211_0
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]