Hi All,
Pls could you tell me Where can I get info/sample code for
Isochronous data write?
I mean I need to send data through ISO endpoints to audio
device(MP3/MPEG data).
Thanks,
Ashok
---
This sf.net email is sponsored by:ThinkGeek
Welco
Hello everyone!
Is it ok to sleep in probe() ?
My testing says - NO. For example, I want to query some information from
device as soon it is connected. If I sumbit one small interrupt urb (8 bytes)
and sleep until completion handler wakes me up, everything is ok. But if I
try to do it 2 times
Am Dienstag, 10. Dezember 2002 12:56 schrieb Tvrtko A. Ursulin:
> Hello everyone!
>
> Is it ok to sleep in probe() ?
>
> My testing says - NO. For example, I want to query some information from
> device as soon it is connected. If I sumbit one small interrupt urb (8
> bytes) and sleep until complet
Greg, here's a patch for the 2.4.x series. Can you please apply it?
Matt
- Forwarded message from Marek Michalkiewicz <[EMAIL PROTECTED]> -
Date: Tue, 10 Dec 2002 09:36:59 +0100 (CET)
From: Marek Michalkiewicz <[EMAIL PROTECTED]>
Subject: Datafab KECF-USB / Sagatek DCS-CF / Simpletech U
> > Is it ok to sleep in probe() ?
> >
> > My testing says - NO. For example, I want to query some information from
> > device as soon it is connected. If I sumbit one small interrupt urb (8
> > bytes) and sleep until completion handler wakes me up, everything is ok.
> > But if I try to do it 2 ti
Am Dienstag, 10. Dezember 2002 19:13 schrieb Tvrtko A. Ursulin:
> > > Is it ok to sleep in probe() ?
> > >
> > > My testing says - NO. For example, I want to query some information
> > > from device as soon it is connected. If I sumbit one small interrupt
> > > urb (8 bytes) and sleep until complet
On Tue, 10 Dec 2002, Tvrtko A. Ursulin wrote:
| > > Is it ok to sleep in probe() ?
| > >
| > > My testing says - NO. For example, I want to query some information from
| > > device as soon it is connected. If I sumbit one small interrupt urb (8
| > > bytes) and sleep until completion handler wakes
> > So I guess it is not ok to sleep in a probe. Just wanted somebody to
> > confirm this.
>
> On the contrary. You may sleep in probe().
Ok, found it - my mistake. Fingers were quicker than the brain. It happens. :)
---
This sf.net email is
On Mon, Dec 09, 2002 at 07:28:38PM -0800, David Brownell wrote:
>
> >>That's not a timeout, "-EREMOTEIO" means it got a short read.
> >>In this case, that last packet included only 13 bytes not 512.
> >>(Assuming this was at high speed, otherwise it wasn't the last
> >>one, and that was likely 13
On Mon, Dec 09, 2002 at 06:11:32PM -0800, Matthew Dharm wrote:
> On Mon, Dec 09, 2002 at 05:34:11PM -0800, Greg KH wrote:
> > On Mon, Dec 09, 2002 at 05:32:02PM -0800, David Brownell wrote:
> > > >>...
> > > >>Dec 9 15:22:26 soap kernel: usb-storage:
> > > >>usb_stor_bulk_transfer_sglist(): xfer
"13 bytes not 512" is rather suspicious if we have bInterfaceClass ...Protocol = x 08
50. In that context, 13 just happens to be the length of a CSW. How sure are we that
the packet here is data? Do we know if its first four bytes are "USBS", as we would
expect in a CSW?
When working with
I saw changes in how 2.5.51 (*) behaved:
- One of the "buffer layer error" messages vanished,
but the fs/buffer.c:1163 one still seems to happen.
- New "scsi HBA driver usb-storage didn't set max_sectors,
please fix the template" message on device probe.
- SCSI shows differently in sysfs, so
On Tue, Dec 10, 2002 at 02:40:01PM -0700, Pat LaVarre wrote:
> "13 bytes not 512" is rather suspicious if we have bInterfaceClass
> ...Protocol = x 08 50. In that context, 13 just happens to be the
> length of a CSW. How sure are we that the packet here is data? Do we
> know if its first four by
> the device reports:
> I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Thanks for quoting this.
> Nope
Ouch, lost me, sorry. What a reader of the Usb spec
might phrase as "bInterfaceClass = x08" or
"bDeviceClass = x08" here appears as "Cls=08(stor.)".
And
On Tue, Dec 10, 2002 at 01:34:26PM -0800, Greg KH wrote:
> On Mon, Dec 09, 2002 at 06:11:32PM -0800, Matthew Dharm wrote:
> > On Mon, Dec 09, 2002 at 05:34:11PM -0800, Greg KH wrote:
> > > On Mon, Dec 09, 2002 at 05:32:02PM -0800, David Brownell wrote:
> > > > >>...
> > > > >>Dec 9 15:22:26 soap k
Oh... excellent observation, Pat. A dropped packet would produce almost
exactly this sort of thing...
Matt
On Tue, Dec 10, 2002 at 02:54:26PM -0700, Pat LaVarre wrote:
> > the device reports:
> > I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
>
> Thanks for quoting t
On Tue, Dec 10, 2002 at 02:54:26PM -0700, Pat LaVarre wrote:
>
> Lost me again, sorry. What reason do we have to
> believe that it is the device, not the host, that
> starts dropping data packets when we switch to Usb2 HS
> from Usb1 FS?
>
> Maybe it's host hardware, not the host software per
On Tue, Dec 10, 2002 at 12:12:14AM +0100, Oliver Neukum wrote:
> > > > Any fixes for this would be gladly accepted.
> > >
> > > Well, this isn't easy to do well without deep surgery.
> > > Here's a patch that fixes the problem but isn't pretty.
> > > It's just for review and please note, my kernel
On Tue, Dec 10, 2002, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > > Any fixes for this would be gladly accepted.
> > >
> > > Well, this isn't easy to do well without deep surgery.
> > > Here's a patch that fixes the problem but isn't pretty.
> > > It's just for review and please note, my kernel
On Tue, Dec 10, 2002 at 09:31:06AM -0800, Matthew Dharm wrote:
> Greg, here's a patch for the 2.4.x series. Can you please apply it?
I've added it to both 2.4 and 2.5, thanks.
greg k-h
---
This sf.net email is sponsored by:
With Great Power,
Matthew Dharm wrote:
On Mon, Dec 09, 2002 at 05:34:11PM -0800, Greg KH wrote:
But does that deserve the long "reset the endpoint" delay that happens
because of this? I'd rather have a bit slower throughput and no long
delays, than shorter bursts of data, with long delays, cutting the end
throu
Pat LaVarre wrote:
Lost me again, sorry. What reason do we have to
believe that it is the device, not the host, that
starts dropping data packets when we switch to Usb2 HS
from Usb1 FS?
In fact, what kind of device is it? And does it show
up when using the ehci driver with this device at full
Heh, it might be. This same hardware configuration worked just fine a
few 2.5 kernel versions ago. I can reboot to see how well 2.0 on 2.4.20
works too...
And then that might point to the ehci driver :)
Could certainly be. But there seems to be other wierdness going on too,
including proble
On Mon, Dec 09, 2002 at 04:57:30PM -0800, David Brownell wrote:
> This patch does two main things:
>
> - add a new primitive, wait_timeout(),
>that's like wait_for_completion() but it takes a timeout
>
> - uses it to replace some dubious code at the core of the
>usb synchronous messagi
> "JimC" == James H Cloos <[EMAIL PROTECTED]> writes:
JimC> In all 2.4 versions I've tested, (the most recent of which are
JimC> 2.4.20-pre4-ac1 and 2.4.20-pre8), ide-scsi, sbp2 and usb-storage
JimC> all use scsi host id 0.
I don't see that I posted an update to this. In 2.4, this was fixed
> > Doesn't sound easy to me.
>
> Ick, that's even messier :(
> In looking at your match, I think we only need the last bit, right? The
> other stuff was formatting cleanup, and code reorg from a first glance.
The first hunk is editor junk, true, sorry.
The rest is essential. That code is shifte
FYI, here's a patch I just added to my 2.5 bk trees that adds driver
core bus support for the usb-serial drivers. Now all of the different
ports show up in sysfs individually, which will make things easier in
the future.
It also shows what ports are attached to what drivers, as this snippet
of /s
On Wed, Dec 11, 2002 at 01:26:53AM +0100, Oliver Neukum wrote:
>
> > > Doesn't sound easy to me.
> >
> > Ick, that's even messier :(
> > In looking at your match, I think we only need the last bit, right? The
> > other stuff was formatting cleanup, and code reorg from a first glance.
>
> The fir
28 matches
Mail list logo