ebsite, so I called the product ID PRODUCT_ID_PRESTIGE to match the
product string.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
--- a/drivers/usb/net/rtl8150.c 2006-06-20 05:31:55.0 -0400
+++ b/drivers/usb/net/rtl8150.c 2006-07-05 22:07:05.0 -0400
@@ -129,11 +129,13 @@
#
cations into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>___
>linux-usb-devel@lists.so
quot;fill up" the USB 2.0 hub's transaction translator periodic schedule with
only a few devices. The updates allow many more devices to fit in the
TT's periodic schedule. The specific number of devices depends on how
many periodic endpoints, those endpoint's poll rates, and t
you want of course :)
or if you have other comments and/or want me to resend the patches let me
know.
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
This
n so people can test out the patches fully
before replacing the old model.
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
This SF.net email is spo
This adds a config option to use the new TT scheduling function. The
option is marked as EXPERIMENTAL so it can be tested for a while without
actually rolling it out by default.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/Kconfig b/drivers/usb/host/K
e
as many transfers as will fit on each TT's bus.
Again, I think I covered most of your concerns from the previous patches,
but let me know if you see any problems. Thanks.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-sched.c b/drivers/usb/h
periodic_usecs" does, except on the other side
of the TT, i.e. it calculates the low/fullspeed bandwidth usage instead
of highspeed.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/eh
of data per 1ms frame, or 24Mbytes per second.
I thought it might too, but the function isn't used by the ehci driver,
so it will only be used for fullspeed cases.
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a g
Simply updates the ehci driver version and comments based on previous
patches to add tt downstream bus scheduling.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2005-07-15
This removes tt_no_collision, replaced by tt_available in an earlier
patch.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2005-08-03 12:56:33.0 -0400
+++ b/d
This removes gap_uf, which is no longer used.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2005-08-03 13:15:40.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2005-08-03 13:19:37.000
11.18.4 requirement 3b, that is, a csplit in each of the
uframes folling the downstream transfer (which is 1 uframe after the
ssplit), except for transfers in uframe 5 and 6, since those would need
FSTN which isn't supported yet.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
d
to the USB 2.0 spec section 11.18.1
(figure 11-60) and section 11.18.4 requirement #4. This does allow
multiple ssplits/csplits during a single uframe, up to 16 as specified by
the USB 2.0 spec.
Note this only adds the function, later patches change the driver to use
it and remove the tt_no_coll
with the qh or iso stream, as calculated by usb_calc_bus_time.
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2005-08-03 13:09:41.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2005-
I've broken up the previous patch for adding tt downstream scheduling into
7 patches. Here's the first.
This simply adds think_time to the usb_tt struct and sets it appropriately
(measured in ns).
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
diff -urpN a/drivers/usb/core
ermore, bandwidth calculations are always done
>per-frame, whereas different ISO packets from an URB are sent in different
>frames (when running at full speed).
>
>Alan Stern
>
--
Dan Streetman
[EMAIL PROTECTED]
-
Oops, forgot...
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
On Thu, 28 Jul 2005, Dan Streetman wrote:
>
>Hi Dave,
>
>ok as promised here's a patch that implements full downstream (low/full
>speed) scheduling for transaction translators. It replaces the old
&
Hi Dave,
ok as promised here's a patch that implements full downstream (low/full
speed) scheduling for transaction translators. It replaces the old
collision-scheduling model, and allows multiple ssplits and csplits per
uframe.
Specifically, the function tt_no_collision is replaced with
tt_
s the time in nanoseconds (I didn't notice that before) while the
HS_USECS and HS_USECS_ISO are microseconds. This fixes the function to
return nanoseconds always, and adjusts ehci-q.c (the only high-speed
caller of the function) to wrap the call in NS_TO_US().
Signed-off-by: Dan St
Isn't the function miscalculating the high speed bus time, as fixed below?
Or am I misunderstanding the function parameter "isoc" meaning?
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
--- linux-2.6.12.2-orig/drivers/usb/core/hcd.c 2005-06-29 19:00:53.0
-04
?
(Also, technically, the first csplit is supposed to be 2 uframes after the
ssplit, not 1, i.e. ssplit/gap/csplit/csplit/, as
shown in the USB 2.0 spec figure 11-66, section 11.18.7, page 380, but
I'll hold off on trying to talk you into that for later :)
Signed-off-by: Dan Streetman <[
ed.
I'm not suspecting it of being buggy at all, I'm saying it makes the
assumption TT's can't handle queueing split transactions, that is it's
entire job :) If the design is changed to queue split transactions,
tt_no_collision would need to be either removed or updated to al
special handling of sitd's is needed?
Thanks!
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
SF.Net email is sponsored by: Discover Easy Linux Migrati
On Thu, 24 Feb 2005, Vojtech Pavlik wrote:
>> would a module parameter that selects raw or hw-calibrated be better?
>
>That'd be a conflict-less solution, indeed.
ok, here's a patch to add a boolean parameter "raw_coordinates". It
defaults to true, so behavior won't change by default.
One not
rnel.
However, if you think passing the raw values is still needed, would a
module parameter that selects raw or hw-calibrated be better?
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't jus
Ok, so I think that all are in agreement that this patch is ok. This
allows people to use hw-calibration. This should not effect people using
software calibration at all (besides having to do a one-time
software recalibration).
Signed-off-by: Dan Streetman <[EMAIL PROTEC
p that plan... :(
How does my plan have any effect at all on you creating a software
calibration library?
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
-
-calibrated coordinate
data.
-if software calibration is being used, a software calibration program
would need to get run, period. The mtouchusb driver can report raw or
hw-calibrated coordinate data, it makes no difference to the software
calibration program.
--
Dan Streetman
[EMAIL
On Thu, 17 Feb 2005, Paulo Marques wrote:
>Dan Streetman wrote:
>> Bottom line points:
>>
>> -nothing is gained from passing raw coordinates to evdev
>
>Nothing is gained either, since the information is the same (or less, in
>case the hardware was mis-calibrated)
coordinates as raw
coordinates. You won't ever notice the difference.
Please, can we pass hardware-calibrated coordinates up from the 3M touch
screen? :)
On Thu, 17 Feb 2005, Paulo Marques wrote:
>Dan Streetman wrote:
>> [...]
>>>One reason is to make the behavior of all tou
'll still use software calibration, with all the benefits of the HW
>one.
But as far as I know, I can't, and it still would be easier to use
hardware calibration, where it "just works" with no software
calibration...
--
Dan Streetman
[EMAIL PROTECTED]
---
es makes
>> software calibration optional...
>
>We'll have to have software calibration for devices which don't have it
>in hardware (and many don't), anyway.
Sure, sure, I'm just saying, why _force_ software calibration? If the 3M
panel reports only raw coor
c:
http://www.3m.com/3MTouchSystems/downloads/tecdoc.jhtml
and it's just a single USB Vendor Request. After the request the
touchscreen uses the next 2 touches to do internal hardware calibration.
Thanks!
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
Hi Todd,
In mtouchusb, you switched back to raw coordinate data, from calibrated
coordinate data...but, isn't it better to report calibrated coordinate
data? Could we patch the driver to go back to calibrated coordinate data?
--
Dan Streetman
[EMAIL PROT
on evdev's coordinate origin being upper-left?
Thanks!
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
SF email is sponsored by - The IT Product Guide
Read h
t the usage->code.
So should both D-pad up and D-pad down get mapped to ABS_HATxY (and
similar for left/right) or should up get ABS_HAT0Y (or next available) and
down get ABS_HAT1Y?
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per s
e.
Thanks!
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
G
fix, I can send a patch in for that. Do you think the GENDESK Usage Id
matching should be increased significantly for most/all Usage Ids or would
you rather just adding a catch for the 0x "undefined" Usage Id?
Thanks.
On Wed, 11 Aug 2004, Vojtech Pavlik wrote:
>On T
r
usage->code was shifted because of this).
This patch changes the code to only set the bit. I left the test for
code > max in, but that probably is not needed except as a sanity check
for the set_bit().
Signed-off-by: Dan Streetman <[EMAIL PROTECTED]>
--- linux-2.6.8-rc4/dri
Ok here is a patch to make the mount options work. In addition to
implementing the remount function, it removes the parse_options() call
from usb_fill_super and adds a "ignore" flag around the mounting that gets
done in create_special_files. The parse_options call in usb_fill_super is
remove
There is a problem in 2.6 with the mount options for usbfs/usbdevfs,
they are ignored. This is becuase the "remount" function isn't
extended to re-parse the options and update the nodes. I have a patch
for this, but while writing it I noticed that while usbfs and usbdevfs
are different filesystem
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it
Hi all,
here is a backport of the usbfs 'disconnect' functionality. The only
difference I know of from the 2.5 code is this doesn't use the kernel
lock. I'm not sure if that is really needed? Anyway it would be great to
finally get this into 2.4...
diff -urN linux-2.4.18-3/drivers/usb/dev
It seems this didn't get thru the first time...
-- Forwarded message --
Date: Wed, 20 Aug 2003 23:45:42 -0400 (EDT)
From: Dan Streetman <[EMAIL PROTECTED]>
To: Linux USB devel <[EMAIL PROTECTED]>,
Greg KH <[EMAIL PROTECTED]>
Subject: [patch] backport
On Wed, 20 Aug 2003, Dan Streetman wrote:
>here is a backport of the usbfs 'disconnect' functionality. The only
>difference I know of from the 2.5 code is this doesn't use the kernel
>lock. I'm not sure if that is really needed? Anyway it would be great t
se to have a conversion function in usb.c,
something like:
inline int bInterval_to_ms(unsigned char bInterval, int speed, int isoc)
{
if (USB_SPEED_HIGH == speed)
return (2^(bInterval-1)) * 125;
else if (isoc)
return (2^(bInterval-1));
else
return bInterval;
}
--
Dan Streetman
w and full) only, and ehci-hcd handles highspeed only, it would be
easiest to handle conversion in the HCDs themselves...
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
-
for interrupt or just ISO?
>
>What it says in the USB 2.0 spec: true for high speed interrupt
>as well as all ISO endpoints.
>
>Full and low speed interrupt endpoints use a linear encoding
>(with an effective max interval 128msec).
Hmm, so should the conversion from bInterval t
On Wed, 15 Jan 2003, oliverthered wrote:
>Changes to usb_epnum_to_ep and usb_epnum_to_ep will break drivers that
>require an alt_setting other than 0 but fail to call setinterface.
drivers that attempt to use inactive alternate settings are broken; so
hopefully there aren't any
wer at OSDN's High Performance Computing Channel
>http://hpc.devchannel.org/
>___
>[EMAIL PROTECTED]
>To unsubscribe, use the last form field at:
>https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
--
Dan Streetman
[EMAIL PROTECTED]
--
a driver, so you can't talk to that
interface.
However to read strings, you talk to the device, so the format of the
header is wrong - its recipient should be device, not interface (or
endpoint).
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn'
e where your
trouble is coming from.
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsi
initial driver binding process can many seconds (I think
there is a 2 or 3 second sleep in the hotplug script...).
Or, try the latest 2.5 kernel, it should work great.
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It i
that I can find. It would make much more
sense to be a normal BCD instead of some special BCD that uses a
combination of a byte and two nibbles (when all other BCDs
are always nibble-based).
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles
ike the HCD would just clean them out during
the next frame. Especially since it would be easier (more
centralized) to do it in the HCD, while doing it in the drivers is
more work...
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per sec
SET).
>In fact patches have recently been integrated (2.4, 2,5)
>to address a usbfs bug where it wasn't doing that.
I thought that was to fix (voluntarily) releasing an interface with
pending URBs, which is different than an interface being disconnected
with pending URBs.
--
Dan Stree
nterface supposedly
was disconnected may cause problems (depending on the driver).
I don't think #3 is possible for all devices. The easiest way is have
new drivers reset or otherwise stablize the device/interface.
Currently, #1 is done by usbdevfs, not (AFAIK) #2. And #3 is really
up
quot;host controller halted. very bad"
was the /proc/driver/uhci/ output not helpful, even with debug
set to 3 (or more)? (i.e. modprobe uhci-hcd debug=3)
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
t-interface calls directly) or checking in the
usb core to watch for set-config/set-interface calls...
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
Th
On Wed, 30 Oct 2002, Greg KH wrote:
>On Wed, Oct 30, 2002 at 04:51:31PM -0500, Dan Streetman wrote:
>>
>> On Wed, 30 Oct 2002, Greg KH wrote:
>>
>> >On Wed, Oct 30, 2002 at 04:36:25PM -0500, Dan Streetman wrote:
>> >> but how long until that gets
On Wed, 30 Oct 2002, Greg KH wrote:
>On Wed, Oct 30, 2002 at 04:36:25PM -0500, Dan Streetman wrote:
>> but how long until that gets to 2.4?
>
>Who knows? Someone will eventually realize the goodness involved in it
>and take the time to backport it.
>
>You sent me
On Wed, 30 Oct 2002, Greg KH wrote:
>On Wed, Oct 30, 2002 at 04:08:41PM -0500, Dan Streetman wrote:
>>
>> On Wed, 30 Oct 2002, Greg KH wrote:
>>
>> >On Wed, Oct 30, 2002 at 01:53:29PM -0500, Dan Streetman wrote:
>> >>
>> >> This patch se
On Wed, 30 Oct 2002, Greg KH wrote:
>On Wed, Oct 30, 2002 at 01:50:44PM -0500, Dan Streetman wrote:
>>
>> This patch adds ioctls to get the active config# and interface setting#
>> through usbfs.
>>
>> As far as I can tell, the only way to currently get
On Wed, 30 Oct 2002, Greg KH wrote:
>On Wed, Oct 30, 2002 at 01:53:29PM -0500, Dan Streetman wrote:
>>
>> This patch sets up the URB interval correctly when using interrupts via
>> usbfs. This is finally possible since the automagic resubmission is gone.
>
>Hm, I
This patch sets up the URB interval correctly when using interrupts via
usbfs. This is finally possible since the automagic resubmission is gone.
--- usb-2.5/drivers/usb/core/devio.cTue Oct 8 18:53:39 2002
+++ linux-bk/drivers/usb/core/devio.c Mon Oct 28 23:56:23 2002
@@ -750,7 +750,7
This patch adds ioctls to get the active config# and interface setting#
through usbfs.
As far as I can tell, the only way to currently get the active config is
via the devices file (generates bus traffic, I'd rather not use it) and
there is no way from userspace to determine the active inter
he Linux host-side driver implementation. So they're
currently unsuitable to be used by user-space or slave/target drivers.
So ... comments?
- Dave
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per se
On Wed, 16 Oct 2002, David Brownell wrote:
>Dan Streetman wrote:
>> After the interrupt queueing was added, I don't think the old way of
>> resetting interrupts will work anymore. This patch changes it to simply
>> do a full unlink and resubmission autom
After the interrupt queueing was added, I don't think the old way of
resetting interrupts will work anymore. This patch changes it to simply
do a full unlink and resubmission automatically. Note that since
usb_hcd_giveback_urb() is never called for a resubmitting interrupt URB,
that means w
The talk about disconnect locking reminded me of this - the error code in
the no-driver case for the disconnect ioctl isn't a unique error code.
This changes the error code to what getdriver() uses, -ENODATA.
--- linux-2.5.42/drivers/usb/core/devio.c Sat Oct 12 00:22:08 2002
+++ linu
k that's more than 1 control transfer...
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
This sf.net email is sponsored by:ThinkGeek
Welco
would want to claim a webcam's interfaces on
device connection, but it shouldn't reserve ep bandwidth until a user
application is ready to use the device. Then, it should reserve the
bandwidth for the endpoints it will use.
--
Dan Streetman
[EMAIL PROTECTED]
-
On Sun, 13 Oct 2002, David Brownell wrote:
>Dan Streetman wrote:
> > I have to agree with JE, there should be a common API for drivers to
> > reserve bandwidth on a per-ep basis, and then any URBs submitted are
> > guaranteed not to fail from a shortage of bandwidth.
&g
want to be able to open devices "early" (say, to address
>permissions problems by handing off file descriptors as opposed to
>changing device permissions) and allocate bandwidth later (by issuing
>some kind of read) that's their business.
>
>- Dave
>
>
>
--
Dan
Ok, I'm a moron - the first patch I sent was corrupted - when I diff'ed
the trees, I sent the patch through "grep -v Only" to remove Only in ...
lines. I forgot that would remove source code lines with Only also!
anyway, this is the first patch, that really applies this time. Tested it
myse
Ok, this removes a failed urbp from uhci->urb_list. Otherwise bad things
happen.
diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
--- usb-2.5/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:52:49 2002
+++ linux/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:59:53 2002
@@
This just adds outputting of the 2 uhci lists (urb_list, urb_remove_list,
and complete_list) to the /proc/driver/uhci/ file read.
It also doubles the buffer size used.
This info was just useful to me.
diff -ur usb-2.5/drivers/usb/host/uhci-debug.c linux/drivers/usb/host/uhci-debug.c
--- usb-
Ok, I'm breaking up the big patch into smaller ones, at least for the
simple(r) stuff.
This one fixes a bug where different names were being used for creation
and removal of the /proc/ entry.
diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
--- usb-2.5/drivers/u
On Sat, 12 Oct 2002, David Brownell wrote:
>Having browsed Dan's patch, I see his looked a lot like mine.
>Even down to having picked some of the same new names!
I cracked your home system and copied your patch. I 0wn j0u! Kidding. ;-)
--
Dan Streetman
[EMAI
On Fri, 11 Oct 2002, Greg KH wrote:
>It looks like you are using a buggy version of pine that strips the
>whitespace off of the ends of lines, so this patch didn't apply.
Ok, I managed to fixup pine...strange offtopic item, even the latest
version of pine strips trailing whitepace, I had to hand
g.
The iso endpoint belonging to the default interface setting is non-zero,
in fact it defaults to the largest available max packet size of all its
alternate settings. So it does violate the spec, but it exists...it's a
DLink DSB-V100 video adapter.
--
Dan Streetman
[EMAIL PROTECTED]
-
;t pass the BW reservation to
the next queued interrupt URB...oops!
Since there's that bug, and the big patch I sent should be smaller
patches, would you guys like me to re-send the patch, but with that change
and more seperated into smaller patches? (After I update my pine mailer,
of course ;)
--
D
gt;got working this AM. Some compare'n'contrast action may
>help to improve things even more.
that'd be great.
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
-
On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
>On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>> Hi all. Finally got time to work on this...so, this patch is rather
>> large, but it (almost) all needs to happen at once. So, I'll list
>> essential
Hi all. Finally got time to work on this...so, this patch is rather
large, but it (almost) all needs to happen at once. So, I'll list
essentially what all the changes are, not necessarily in order. I have
tested control and interrupt queueing, but not bulk (no bulk devices on
hand...), so if pe
Hi, this patch fixes usbfs. You can't use a single mount_count for 2
different mounts.
--- usb-2.5/drivers/usb/core/inode.cFri Oct 11 16:52:49 2002
+++ linux/drivers/usb/core/inode.c Fri Oct 11 15:54:47 2002
@@ -45,7 +45,8 @@
static struct vfsmount *usbdevfs_mount;
static struct vfs
On Sat, 20 Jul 2002, David Brownell wrote:
>Comments? Additional/related points? Volunteers?
If nobody else volunteers I can work on UHCI at least. I've been
meaning to see if I can get Control queueing into UHCI anyway.
I'll start reviewing the UHCI driver...
--
Dan Str
ecial
cases which made it very difficult to follow.
I haven't tested enough to make any comments on the speed or
reliability of either driver.
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn't just a good ide
;On Monday 01 July 2002 17:42, Dan Streetman wrote:
>> On Fri, 28 Jun 2002, Duncan Sands wrote:
>> >I send to the 0x81 modem endpoint complete at once with -EILSEQ.
>>
>> what's the format of the URB you send? The size should be exactly the
>> ep's
On Fri, 28 Jun 2002, Duncan Sands wrote:
>I send to the 0x81 modem endpoint complete at once with -EILSEQ.
what's the format of the URB you send? The size should be exactly the
ep's bMaxPacketSize...
--
Dan Streetman
[EM
g rate. Use USB_NO_FSBR to
reduce polling to 1 per millisec (it works for me, at least, on a
per-URB basis).
As far as the rate of URB submission, I don't think it matters, as the
HCD manages the real polling rate and is not affected by URB
submission rate.
--
Dan Streetman
[EMAIL PROTECTED]
reason
>to avoid using those UHCI-only "one shot interrupt" requests.
>
>- Dave
>
>
>
>
>
>
>
>---
>This sf.net email is sponsored by: Jabber Inc.
>Don't miss the IM event of the season | Special of
aster
than 1 poll per millisec) then turn on USB_NO_FSBR to slow the polling
to 1 per ms.
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn't just a good idea, it's the law!
--
be great! If you can point out which changes you suspect I'll
try them out. I'm still suspicious though, since it's happening in
both uhci and usb-uhci...I didn't think they shared queueing code...?
Thanks.
--
Dan Streetman
[EMAIL PROTECTED]
--
t just use those?
I have to use 2.4.2-2, so the best I can hope for is find the specific
problem code and patch the 2.4.2-2 kernel (if possible).
--
Dan Streetman
[EMAIL PROTECTED]
--
186,28
Ok, I'm completely stumped on a problem and thought I'd see if anyone
has seen this or might have an idea why it's happening.
I (unfortunately) have to use an older kernel (2.4.2-2, i.e. Redhat
7.1) and on both UHCI drivers (uhci.o and usb-uhci.o) I'm seeing what
looks like the HCD is "losing" d
. using HID/hiddev) you need HID.
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn't just a good idea, it's the law!
___
Don't miss the 2002 Sprint P
r Host Controller Device.
>
>See above ohci.o whoudl do it.
FWIW, I agree - IMHO the 'ideal' naming would be "ehci.o", "uhci.o",
and "ohci.o". Let the 2 uhcis get named "uhci-.o" until a
decision is made, then rename
quot; with the only exception being
interrupt is earlier in the frame than bulk, so interrupt is
"guaranteed" to happen while bulk is not (on a heavily loaded bus).
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn
1 - 100 of 145 matches
Mail list logo
