> From: "Dunlap, Randy" <[EMAIL PROTECTED]>
> Date: Tue, 27 Feb 2001 12:21:00 -0800
> > If Randy or anyone else explain me why it happens, I am willing
> > to come up with a patch which would redo hub_disconnect()
> > to put hubs on reaping list and have usb_hub_events actually
> > destroy them.
"history" ... eventually, I'd like to see the host controllers
sharing more code, using a layer like the "hcd" layer in
the EHCI patch. That's got root hub support that works
basically like the existing root hub code, except that lots
of it is sharable. It uses "hub.h".
The same sharing logic c
On Wed, Mar 07, 2001 at 11:52:38PM -0800, Greg KH wrote:
> On Wed, Mar 07, 2001 at 06:35:31PM -0800, Jean Tourrilhes wrote:
> > Johannes Erdfelt wrote :
> > > The key is probably the function that calls irda_usb_change_speed_xbofs.
> > > Most likely it allocates self on the stack (as an automatic
Thomas Dodd wrote:
>
> David Brownell wrote:
> >
> > > > > usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
> > > > > usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
> > > > > USB
> > > >
> > > But 2.4.0-ac12, 2.4.1-ac18, and 2.4.2-ac1->ac3 worked fine
> > > (I'm not sure
On 8 Mar, Greg KH wrote:
> On Thu, Mar 08, 2001 at 10:47:30AM -0500, [EMAIL PROTECTED] wrote:
>> > Some USB to serial devices handle latencies better than others. But of
>> > course they cost more :)
>>
>> Naturally, ;-) ...I'm using stock Intel UHCI.
>
> No, I mean that the USB to serial dev
On Thu, Mar 08, 2001 at 05:18:54PM +0100, Wolfgang Grandegger wrote:
> I checked the linux-usb-devel mailing list and indeed also
> pilot-xfer seems not to be properly written. You can look for
> example here:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=97889646414658&w=2
>
> What y
On Thu, Mar 08, 2001 at 10:47:30AM -0500, [EMAIL PROTECTED] wrote:
> > Some USB to serial devices handle latencies better than others. But of
> > course they cost more :)
>
> Naturally, ;-) ...I'm using stock Intel UHCI.
No, I mean that the USB to serial device _itself_ is probably where the
g
> I anticipated this and came up with about 5ms worst case:
>
> 1 Submit packet to USB drivers
> 2 data to UART
> 3 data through loopback
> 4 data from UART
> 5 data from USB drivers
At least for OHCI, an idle host controller "should" be able to handle
(1) and (2) in less than a frame on average
"Rafael R. Sevilla" wrote:
>
> On Wed, 7 Mar 2001, Wolfgang Grandegger wrote:
> >
> > Does this help? I will send you a test version later
> > this week.
> >
>
> I'll see what happens...
>
> > Does the pilot-link program handle the write() return
> > code correctly. A write to the serial device
On 8 Mar, To: [EMAIL PROTECTED] wrote:
> On 8 Mar, Greg KH wrote:
>> On Wed, Mar 07, 2001 at 02:34:26PM -0500, [EMAIL PROTECTED] wrote:
>>> I found that a native UART has a latency of 1-2ms for a single byte.
>>> That latency increases with packet size. When run over the 8U232AM
>>> the 1 byte
David Brownell wrote:
>
> > > > usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
> > > > usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
> > > > USB
> > >
> > But 2.4.0-ac12, 2.4.1-ac18, and 2.4.2-ac1->ac3 worked fine
> > (I'm not sure on the 2.4.2 series, Alan's been rele
On 8 Mar, Greg KH wrote:
> On Wed, Mar 07, 2001 at 02:34:26PM -0500, [EMAIL PROTECTED] wrote:
>> I found that a native UART has a latency of 1-2ms for a single byte.
>> That latency increases with packet size. When run over the 8U232AM
>> the 1 byte latency is about 16-17ms and remains about 15
12 matches
Mail list logo
