Hello
You can have several bulk tansfert in one frame. And each device
may have an interrupt packet for a frame number. In the same frame
you may have one ore more isochronous, one or more interrupt, one
or more bulk and one or more configure packet and for one or more
device: You can have more th
Am Montag, 20. Januar 2003 09:47 schrieb Charl P. Botha:
> On Mon, 2003-01-20 at 07:31, Oliver Neukum wrote:
> > Am Montag, 20. Januar 2003 00:03 schrieb Charl P. Botha:
> > > This is kernel version 2.4.21-pre3 + acpi20030109 + swsusp16 and the
> > > unkillable khubd happens after a cold restart, e
speedtouch: simplify the receive urb lifecycle: allocate them in the usb probe
function,
free them on disconnect.
speedtouch.c | 81 +--
1 files changed, 51 insertions(+), 30 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b
> MaxPower Needed: 100mA
Eric,
The device appears non-compliant with USB 1.1 specification
for power. Their documentation states that it is USB
bus-powered,
drawing a maximum of 100mA from the bus; yet the device can
supply up to 200mA for 16 output pins. Add the power needed
for the 'dev
thanks...
but i thought sh_done_list returns (urb_state = -1) if it is done???
but in the hc_interrupt... it checks whether urb_state == 0... which
means it would not try another packet???
Pei Liu wrote:
>
> >
> >i am not sure if i understand this driver in depth the question
> >i have is
>
>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?
Yes, you can send multiple USB transactions within the same frame.
>
>the interrupt service routine (hc_interrupt) seems to allow only ONE
>packet per f
Do you know if it is ACCEPTABLE to turn of SOF interrupt when there
is nothing to send
a. would it stop SOF generation towards the function/device?
b. can the driver turns on SOF before having something to send???
and turn if off after all ack/tarnsactions are completed
this is to preve
As mentioned in a previous message, I'm unable to use 2.4.20 and
2.4.21-pre3 on my Globespan IVR (mips-based, little-endian) platform
due to (I'm guessing) IDE problems. My kernel starts from flash, and
detects the ide drives, but can't boot from them when the kernel is
done loading.
When I t
>
>but i thought sh_done_list returns (urb_state = -1) if it is done???
>but in the hc_interrupt... it checks whether urb_state == 0... which
>means it would not try another packet???
Yes, I think I understand your concern. The sh_done_list returns a -1 when
it has completed the URB, in such cas
that means the packet will be sent during next frame instead?
can we just change the hc_interrupt to
if ( && urb_state <= 0)
{
if (urb_state == 0) add_packet
else schedule_trans
Pei Liu wrote:
>
> >
> >but i thought sh_done_list returns (urb_state = -1) if it is d
Tom Collins wrote:
I replaced drivers/usb/* and include/linux/usb*.h in my 2.4.19 tree with
the versions from 2.4.21-pre3. I was able to compile the kernel, but
when I installed it I got the following errors when I turned on my USB
2.0 hard drive:
hub.c: new USB device 00:13.2-2, assigned ad
>that means the packet will be sent during next frame instead?
No, the sh_schedule_trans() got preempted when a xferdone irq occurs (Kinda
like suspended/blocked), and will continue after the irq has been handled.
(kinda like resume)
>can we just change the hc_interrupt to
>
>if ( && urb_st
Matthew Dharm wrote:
In a separate discussion with Mike, he mentioned that you can't
scsi_remove_device() unless there are no pending commands.
How the hell is an LLD supposed to assure that!?!?
ABORT TASK/ABORT TASK SET.
For a year now I've been trying to get something of the sort
scsi_cancel
Oliver Neukum wrote:
Hi,
I was just looking at the TODO list and it seemed to me that a list somewhat
more specific and focused on usbcore might be useful.
I think the real issue is who will fix the various bugs and issues that
turn up, but having lists can help focus that energy.
So here's
Am Montag, 20. Januar 2003 19:21 schrieb David Brownell:
> Oliver Neukum wrote:
> > Hi,
> >
> > I was just looking at the TODO list and it seemed to me that a list
> > somewhat more specific and focused on usbcore might be useful.
>
> I think the real issue is who will fix the various bugs and issu
Alan Stern wrote:
Okay, let's forget about bandwidth reservation for the time being.
Sure, particularly since I didn't have a chance to investigate that
too deeply ... there did seem to be some logic intending to recycle
allocations in uhci-hcd, maybe it's reallly correct. And I suspect
other
Can anyone help me for using under linux the us robotics modem 5633 (the
5605 is the old model)
Thanks
Antonio Bernabei
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to
>
>Do you know if it is ACCEPTABLE to turn of SOF interrupt when there
>is nothing to send
It is possible, but the driver needs a different method to keep track of the
frame number. I don't have the hardware specification with me, I think
hardware keep tracks the frame number also, all you
Pei
Do you know if INSERT/REMOVE interrupt works for SL811H??? the driver
seems to have that interrupt enabled but when the cable is removed..
nothing happen... is this interrupt for exactly what i thought i meant?
(removing/insertion of cable)???
thanks
--
Hi,
This patch adds vendor/product ids for Artec, Canon, Compaq, Epson,
HP, and Microtek scanners. Further more, the device list was cleaned
up, sorted and duplicated entries have been removed.
Bye,
Henning
diff -u -r linux-2.4.21-pre3.syslog/drivers/usb/scanner.c
linux-2.4.21-pre3.newids4/dr
Hi,
This patch adds vendor/product ids for Artec, Canon, Compaq, Epson,
HP, and Microtek scanners. Further more, the device list was cleaned
up, sorted and duplicated entries have been removed.
Bye,
Henning
diff -u -r linux-2.5.59-syslog/drivers/usb/image/scanner.c
linux-2.5.59-newids4/driver
Hi,
this patch fixes a bug where submitting an sg request could get a task
stuck in state D if the first submission fails.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual
>Do you know if INSERT/REMOVE interrupt works for SL811H??? the driver
>seems to have that interrupt enabled but when the cable is removed..
>nothing happen... is this interrupt for exactly what i thought i meant?
>(removing/insertion of cable)???
>
The INSERT/REMOVE irq works for the SL811HS. W
I've recently been trying 2.4.20 and the keyspan driver. I've been
using the keyspans fine with 2.4.18 and 2.4.19 (in fact we have 100s
of them ;-) but trying them with 2.4.20 I get the Oops below quite a
lot. It happens on close of the port but I think there must have to
be data flowing through
Oliver Neukum wrote:
this patch fixes a bug where submitting an sg request could get a task
stuck in state D if the first submission fails.
Did you actually observe that? I strongly suspect not. Using yield()
instead of that schedule() bit should be OK (is that what you're saying
would get "s
I noticed that if you modprobe uhci but have no such hardware (it was
an alpha, with ohci, and I was tired) the module fails to load,
obviously, but it leaves a proc file behind, /proc/driver/uhci.
The attached patch should fix that, it seemed simple enough. It's not
tested beyond the fact that it
> I take it you mean that the transport will tell the LLDD that the device
> is gone and it (LLDD) call the one above, SCSI Core to remove the device.
>
> Hmm, more thinking needs to be done here, as shouldn't this be handled
> by hotplugging? I.e. Targets do not *initiate* events.
>
> The transpo
Oliver Neukum wrote:
I take it you mean that the transport will tell the LLDD that the device
is gone and it (LLDD) call the one above, SCSI Core to remove the device.
Hmm, more thinking needs to be done here, as shouldn't this be handled
by hotplugging? I.e. Targets do not *initiate* events.
Th
> > We as the writers of device drivers need a way to get rid of the device
> > as we are notified of the physical disconnect.
>
> Yes, and as I explained earlier: you *may* get notified by the transport.
That exactly is the point. There must be no maybe. Gone is gone.
Failure is not an option he
Luben Tuikov wrote:
But a removal of a device would probably have to start in top-down
approach, to free/release/etc resources/etc, rather than a bottom-up
approach (I just cannot see how this would work...)
Well, the driver model core covers key parts of that. Or it was
at least intended to .
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD that the device
is gone
Am Montag, 20. Januar 2003 21:08 schrieb David Brownell:
> Luben Tuikov wrote:
> >> The way this should work is that the LLD calls scsi_remove_device(), and
> >> that cuts off the flow of commands. The LLD can promise to error-out
> >> any pending commands in the device command queue.
> >
> > I ta
Oliver Neukum wrote:
That model cannot be applied to SCSI as it is much more diverse
in the number of bus types it supports.
USB can do it, because it knows about hubs. SCSI cannot,
as there are no hubs in SCSI.
Hubs are irrelevant here, the key functionality is noticing
hardware addition/disco
Am Montag, 20. Januar 2003 22:24 schrieb David Brownell:
> Oliver Neukum wrote:
> > That model cannot be applied to SCSI as it is much more diverse
> > in the number of bus types it supports.
> > USB can do it, because it knows about hubs. SCSI cannot,
> > as there are no hubs in SCSI.
>
> Hubs are
David Brownell wrote:
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out
any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD
Oliver Neukum wrote:
I should be more specific.
Yes...
The SCSI is different for several reasons:
- we are talking about bus as well as device detection
- there's no common way to probe for devices
(the probing of LUNs works only on conventional busses)
So the SCSI stack needs to support
Luben Tuikov wrote:
David, when I said ``... the transport will tell the LLDD that the
device ...'' this is *exactly* what I meant. You're just repeating
it here in a more broken-down way.
OK
By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
and the initiator (aka the init
Am Montag, 20. Januar 2003 23:09 schrieb David Brownell:
> Oliver Neukum wrote:
> > this patch fixes a bug where submitting an sg request could get a task
> > stuck in state D if the first submission fails.
>
> Did you actually observe that? I strongly suspect not. Using yield()
> instead of that
Oliver Neukum wrote:
Removals? Additions? Comments?
Yes, I'll be glad to see more of the usbcore cleanups happen.
Here are a random bunch of things
- Someone just emailed me for help on that classic, and still
unresolved, issue of associating a device from 'lsusb' (etc)
with the right /
Oliver Neukum wrote:
Am Montag, 20. Januar 2003 23:09 schrieb David Brownell:
Oliver Neukum wrote:
this patch fixes a bug where submitting an sg request could get a task
stuck in state D if the first submission fails.
Did you actually observe that? I strongly suspect not. Using yield()
ins
David Brownell wrote:
Oliver Neukum wrote:
Removals? Additions? Comments?
Yes, I'll be glad to see more of the usbcore cleanups happen.
Here are a random bunch of things
- Someone just emailed me for help on that classic, and still
unresolved, issue of associating a device from 'lsusb' (
Am Montag, 20. Januar 2003 21:41 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>Removals? Additions? Comments?
> >>
> >>Yes, I'll be glad to see more of the usbcore cleanups happen.
> >>Here are a random bunch of things
> >>
> >> - Someone just emailed me for help on that classic, and still
>
> >>The patch is problematic, since it basically prevents submission of large
> >>scatterlists from working at all in cases where resources are very tight.
> >>..
> >
> > If you know a better way how to determine how often to loop, I'll
> > implement it.
>
> Any "better way" observes the "graceful
Oliver Neukum wrote:
When will we go to code freeze?
No such thing as "code freeze", not like commercial UNIX
where it means a year before customers could see fixes.
(If they're willing to pay through the nose for patches.)
On the other hand, 2.5.59 won't change for a few weeks,
that's at leas
> So the SCSI stack needs to support more than one model for
> device/bus detection. This can't be news. And some of them
> have to handle "conventional" busses, like USB and PCI; maybe
> even handle booting off them...
Until very recently it was news. And they still haven't fully
comprehended
> > By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
> > and the initiator (aka the initiator port). This terminology is not
> > really that new, but still not that old, and described in SAM-3.
>
> I was hoping for something described in the 2.5.58 kernel docs,
> which only tal
Oliver Neukum wrote:
So you were talking past what I said about notifying that highest level,
not disagreeing with it.
I was trying to make the point that callbacks have no place in that process.
If so, you didn't persuade me ...
It must go bottom to top and that's it.
... because those
Am Dienstag, 21. Januar 2003 01:44 schrieb David Brownell:
> Oliver Neukum wrote:
> >>So you were talking past what I said about notifying that highest level,
> >>not disagreeing with it.
> >
> > I was trying to make the point that callbacks have no place in that
> > process.
>
> If so, you didn't
Oliver Neukum wrote:
Any "better way" observes the "graceful degradation" design principle.
Basically: it's not OK to break under load; slowing down is strongly
preferable to being fragile, so long as things still work.
Provided they work at all. Unless we can guarantee that the error
conditio
On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote:
> > The transport can notify that the device is gone, but an ULP entity will
> > call scsi_remove_device() not the other way around.
>
> NO!
>
> This is an insanely complicated scheme.
> We have no notification beforehand. User yanks out cable.
>
pre3-ac has a page list handling bug. That is probably the issue
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_
> That model cannot be applied to SCSI as it is much more diverse
> in the number of bus types it supports.
> USB can do it, because it knows about hubs. SCSI cannot,
> as there are no hubs in SCSI.
Not entirely true - there are devices known as bridges that bridge parallel SCSI to
parallel SCSI
Am Dienstag, 21. Januar 2003 03:06 schrieb David Brownell:
> Oliver Neukum wrote:
> >>Any "better way" observes the "graceful degradation" design principle.
> >>Basically: it's not OK to break under load; slowing down is strongly
> >>preferable to being fragile, so long as things still work.
> >
>
Hi !
I have an embedded XScale system with an SL811HS USB host chip. I've got
usb-2.4 via Bitkeeper and looked into it because it had code for this USB chip
and I had problems with
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1272/1
The links to my mail with the problems I ha
Am Dienstag, 21. Januar 2003 04:31 schrieb Alan:
> On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote:
> > > The transport can notify that the device is gone, but an ULP entity
> > > will call scsi_remove_device() not the other way around.
> >
> > NO!
> >
> > This is an insanely complicated scheme.
>
55 matches
Mail list logo
