On Thu, Feb 08, 2007 at 09:05:15AM -0500, Edwin Olson wrote:
>
> > I'll look at it in a few minutes, but first, what do you want to do that
> > libusb can't do?
> >
> Perhaps I'm out of date, but the documentation for libusb seems to
> indicate that the API is synchronous, which would limit th
On Fri, 9 Feb 2007 11:01:08 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Feb 2007, Pete Zaitcev wrote:
>
> > If we get multiply callbacks in reality, many things my break, especially
> > when files are closed, devices disconnected, modules removed, etc.
>
> Pete, note that Edwin
On Fri, 9 Feb 2007, Pete Zaitcev wrote:
> If we get multiply callbacks in reality, many things my break, especially
> when files are closed, devices disconnected, modules removed, etc.
Pete, note that Edwin is talking about callbacks for multiple URBs in the
same frame. Not multiple callbacks fo
On Thu, 08 Feb 2007 18:02:12 -0500, Edwin Olson <[EMAIL PROTECTED]> wrote:
> [...] staring at usbmon, it
> appears that sometimes I do in fact get multiple callbacks from the same
> frame. But it's quite rare...
This is quite alarming. Maybe you want to check the 1s file and see how
many events
On Thu, 8 Feb 2007, Edwin Olson wrote:
> > So I see. Do you happen to have the URB_NO_FSBR flag turned on in your
> > URBs?
> Not in my code, at least... What does it do?
It does pretty much what you said you saw -- it hints to the controller
driver that this URB doesn't need more than one pack
>> Hmm, I've implemented the multiple outstanding URBs, but it appears that
>> my host only considers one read URB per 1ms period, no matter how many
>> read URBs have been submitted.
>>
>
> What host controller driver are you using?
It's an ICH8 (P965), and I /proc/bus/usb/devices says it'
On Thu, 8 Feb 2007, Edwin Olson wrote:
>
> >> If the host had multiple read URBs pending, would it continue to send IN
> >> tokens after it had already received a short packet in that frame?
> >>
> >
> > Yes.
> >
> Hmm, I've implemented the multiple outstanding URBs, but it appears that
>> If the host had multiple read URBs pending, would it continue to send IN
>> tokens after it had already received a short packet in that frame?
>>
>
> Yes.
>
Hmm, I've implemented the multiple outstanding URBs, but it appears that
my host only considers one read URB per 1ms period, no
Am Donnerstag, 8. Februar 2007 20:28 schrieb Edwin Olson:
> I definitely understand limiting the number of outstanding URBs to avoid
> a DoS, but I don't follow why MAX_TRANSFER is being set to this
> particular value. MAX_TRANSFER = PAGE_SIZE would seem like a better
> choice, as it wouldn't
>> * Why does usb-serial set MAX_TRANFER to (PAGE_SIZE - 512)? What's the
>> 512 for?
>>
>
> A measure to make sure that a malicious user cannot use up unlimited
> amounts of kernel memory. 512 is the maximum packet size of ehci.
> Thus we make sure the number of packets on the page is an in
On Thu, 8 Feb 2007, Edwin Olson wrote:
>
> >> On my embedded platform, it is fairly expensive to do write-merging in
> >> order to send maximum length packets. (In other words, on my device, my
> >> "write" syscalls have a 1:1 correspondence with USB packets; when these
> >> packets are less t
>> On my embedded platform, it is fairly expensive to do write-merging in
>> order to send maximum length packets. (In other words, on my device, my
>> "write" syscalls have a 1:1 correspondence with USB packets; when these
>> packets are less than 64 bytes, I only get one packet per 1ms USB fr
On Thu, 8 Feb 2007, Edwin Olson wrote:
> I forgot to ask an additional question:
>
> Is it sensible to have multiple outstanding read URBs, in the way that
> there are multiple outstanding write URBs?
Yes.
> On my embedded platform, it is fairly expensive to do write-merging in
> order to sen
Am Donnerstag, 8. Februar 2007 14:40 schrieb Edwin Olson:
> * Is my locking correct?
Short answer: No.
Long answer:
/* prevent the device from being autosuspended */
retval = usb_autopm_get_interface(interface);
if (retval)
goto exit;
/* increment
I forgot to ask an additional question:
Is it sensible to have multiple outstanding read URBs, in the way that
there are multiple outstanding write URBs?
On my embedded platform, it is fairly expensive to do write-merging in
order to send maximum length packets. (In other words, on my device, m
> I'll look at it in a few minutes, but first, what do you want to do that
> libusb can't do?
>
Perhaps I'm out of date, but the documentation for libusb seems to
indicate that the API is synchronous, which would limit the number of
outstanding URBs per endpoint to one (unless I made a pthrea
Am Donnerstag, 8. Februar 2007 14:40 schrieb Edwin Olson:
> Attached is a fairly simple new driver ("susi" for "simple usb stream
> interface") that provides an ordered/reliable stream interface,
> compatible with usb-serial, except that it dispenses with the tty layer
> and it doesn't care abo
I'm writing firmware for a number of USB devices, and it seems that most
of the time, I simply want a ordered/reliable communications stream
between host and device: I can build my actual protocol on top of this
in userspace. I've previously used usb-serial, but the performance
wasn't satisfact
18 matches
Mail list logo
