Does anyone besides me find it a bit odd that we bind drivers to an
interface, yet need to pass the device pointer to functions like
usb_control_msg()?
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
I see you've been reading
Hi All,
I am attempting to communicate with a USB device called the Labjack under
Linux. Several other people have posted questions related to this device
before, but thus far, it does not appear that anyone has met with success.
I've done some research on the Labjack, on USB, and on USB under L
Jonathan Thorpe wrote:
> Greetings,
Thanks for the info ... the irq threshold experiment worked as I
had expected, although I hadn't noticed "hdparm" gave such low
numbers on 2.4 kernels. On 2.5 they can be more than four times
bigger, in part because usb-storage there uses urb queueing.
> Afte
Jonathan Thorpe wrote:
However, the BIOS on this board (an
AMI BIOS, latest release from the motherboard vendor) has an option called
"PCI Latency (PCI Clocks)" with a default setting of 32. I changed this to
the maximum, which is 248 and the stability was far greater than before,
on both NEC a
Hi,
But you don't check for asynchronousity, you check for in_interrupt().
Got patch? :)
Not the complicated patch you prefer. I don't know enough about ehci yet.
I'd likely kill the driver.
That's a one-liner. I think it won't actually affect much, but its
clearly wrong and should get f
i am not sure if i understand this driver in depth the question
i have is who can multiple "packets" be sent within the same frame?
the interrupt service routine (hc_interrupt) seems to allow only ONE
packet per frame? is this correct???
when xferdone is handled... the sh_done_list is cal
On Sat, 18 Jan 2003, Duncan Sands wrote:
> Greetings all, if in a completion handler I put the urb on a queue
> for later processing, may I assume that urb->status will stay the
> same as during the completion handler (assuming I do not resubmit)?
> Or does the status change after the completion h
Am Samstag, 18. Januar 2003 14:00 schrieb Duncan Sands:
> Greetings all, if in a completion handler I put the urb on a queue
> for later processing, may I assume that urb->status will stay the
> same as during the completion handler (assuming I do not resubmit)?
> Or does the status change after th
Greetings all, if in a completion handler I put the urb on a queue
for later processing, may I assume that urb->status will stay the
same as during the completion handler (assuming I do not resubmit)?
Or does the status change after the completion handler returns?
Thanks,
Duncan.
--
Am Samstag, 18. Januar 2003 02:59 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Samstag, 18. Januar 2003 02:00 schrieb David Brownell:
> >>Oliver Neukum wrote:
> >>>Hi,
> >>>
> >>>regarding this piece of code:
> >>> spin_lock_irqsave (&ehci->lock, flags);
> >>> ...
> >>>
> >>>Does this
Oliver Neukum wrote:
Am Samstag, 18. Januar 2003 02:00 schrieb David Brownell:
Oliver Neukum wrote:
Hi,
regarding this piece of code:
spin_lock_irqsave (&ehci->lock, flags);
...
Does this mean that any call to usb_unlink_urb() for an URB on EHCI
with a spinlock held will fail?
No, but a
Greetings,
Recently, I've been testing an Asrock K7VT2 motherboard on Linux Kernel
2.4.21-pre2 with David Brownwell's EHCI patch dated 20th of December 2002.
Since the application of the patch, there have been some improvements, but
there are still many hangs. I've been in contact with David with
12 matches
Mail list logo
