Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed
Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed
On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
On Tuesday 28 February 2006 9:48 pm, Marc Singer wrote:
The question is this: what is the simplest gadget to use for debugging
a UDC driver? I started with the serial gadget because I figured it
would be easy to verify that
Hello Alan,
Thanks for the pointers. It is clearer now.
It gets the number of ports from the hardware during initialization.
However, it does _not_ know where they are.
Got it, its comming from the UHCRHDA Root Hub Descrptor Register.
Aparently the PXA271 OHCI only reports 2 ports (ndp=1), but
(please CC, I'm not on the list.)
Hi!
The ep93xx is an arm920t based embedded CPU from Cirrus which has,
amongst other things, an AHB OHCI USB host interface. This CPU isn't
supported in linux yet, but I will be submitting the core ARM support
code for 2.6.17, and in the meanwhile, I would love
On Wed, Mar 01, 2006 at 02:13:25PM +0100, Lennert Buytenhek wrote:
(please CC, I'm not on the list.)
Hi!
The ep93xx is an arm920t based embedded CPU from Cirrus which has,
amongst other things, an AHB OHCI USB host interface. This CPU isn't
supported in linux yet, but I will be
Marc Singer wrote:
The only oddity I've seen so far is that the gadget wasn't detected
when the target (gadget) rebooted. I know that the driver has an
error in the USB power control. Perhaps that's at fault in the
detection.
Hello Marc,
i wrote a fix for that, but it's not thoroughly
Thanks Alan,
I am very thankful for your patient responses.
Regards,
Mukund Jampala
-Original Message-
From: Alan Stern [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 01, 2006 8:45 PM
To: Mukund JB.
Cc: [EMAIL PROTECTED]; Randy.Dunlap
Subject: RE: [linux-usb-devel] RE: Analyze the USB
Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed
On Wed, 1 Mar 2006, Thomas Seiler wrote:
Hello Alan,
Thanks for the pointers. It is clearer now.
It gets the number of ports from the hardware during initialization.
However, it does _not_ know where they are.
Got it, its comming from the UHCRHDA Root Hub Descrptor Register.
Aparently
On Wednesday 01 March 2006 1:09 am, Marc Singer wrote:
On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
http://www.linux-usb.org/usbtest/#gadgets
...
I'm not seeing an explanation of what the tests should look like. How
long should each one last? Most take about a
On Wednesday 01 March 2006 5:13 am, Lennert Buytenhek wrote:
+static struct hc_driver ohci_ep93xx_hc_driver = {
+ .description= hcd_name,
+ .product_desc = EP93xx OHCI,
+ .hcd_priv_size = sizeof(struct ohci_hcd),
+ .irq=
Hello,
This patch adds support for the Nokia ca42 version 2 cable to the
cypress_m8 driver. The device was tested by others with this patch and
found to be compatible with the cypress_m8 driver. A special note
should be taken that this cable seems to vary in the type of chipset
used.
On Wed, Mar 01, 2006 at 02:50:25PM +0100, Oliver Nittka wrote:
Marc Singer wrote:
The only oddity I've seen so far is that the gadget wasn't detected
when the target (gadget) rebooted. I know that the driver has an
error in the USB power control. Perhaps that's at fault in the
On Wed, Mar 01, 2006 at 07:39:06AM -0800, David Brownell wrote:
On Wednesday 01 March 2006 1:09 am, Marc Singer wrote:
On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
http://www.linux-usb.org/usbtest/#gadgets
...
I'm not seeing an explanation of what the tests
Hi,
can someone give me some hints how i can implement flow control in the serial
gadget driver ?
Regards
Tobias
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile
On Wednesday 01 March 2006 9:27 am, Marc Singer wrote:
Test #10 taking a few minutes? Sounds troublesome. If this is using
an OHCI or EHCI host controller and you've compiled with USB_DEBUG,
you'll find a /sys/class/usb_host/.../async dump of the control and
bulk queues. If it doesn't
From: David Brownell [EMAIL PROTECTED]
To: linux-usb-devel@lists.sourceforge.net
CC: Steve Calfee [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] Re: Question about OTG operations
Date: Tue, 28 Feb 2006 23:42:35 -0800
On Tuesday 28 February 2006 11:03 pm, Steve Calfee wrote:
Yes, it is a huge
Martin Michlmayr spotted this potentially serious bug. Please apply.
Jordan
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
www.amd.com/embeddedprocessors
[PATCH] Buglet in Alchemy OCHI
From: Jordan Crouse [EMAIL PROTECTED]
Failure to get the right
* Jordan Crouse [EMAIL PROTECTED] [2006-03-01 11:30]:
Martin Michlmayr spotted this potentially serious bug. Please apply.
Please don't send patches as MIME attachments. Here it is again (with
a better summary too):
[PATCH] Alchemy OCHI: return if right resources cannot be obtained
From:
The -EPROTO is common after unplug, but that -EILSEQ suggests you
have a real issue in the lh7a40x_udc driver ...
Not necessarily. -EILSEQ is a normal code used by uhci-hcd when a CRC or
timeout error occurs on an IN transaction.
True, but it's usually an either/or: either you always
On Tue, 28 Feb 2006, Marc Singer wrote:
...
The question is this: what is the simplest gadget to use for debugging
a UDC driver? I started with the serial gadget because I figured it
would be easy to verify that it is working.
Marc,
Below is a patch against 2.6.16-rc5, which works with
What would be handy is if there was a log of the packets being sent by
the usbtest code, and whether or not those packets had the expected
result. Is there such a log somewhere? Does the dmesg output show
this?
There is nothing in async when my test10 goes awry. There is a lot in
dmesg, but
On Wed, Mar 01, 2006 at 10:04:48AM -0800, David Brownell wrote:
On Wednesday 01 March 2006 9:27 am, Marc Singer wrote:
Test #10 taking a few minutes? Sounds troublesome. If this is using
an OHCI or EHCI host controller and you've compiled with USB_DEBUG,
you'll find a
On Wed, Mar 01, 2006 at 03:34:12PM -0500, Jamie Guinan wrote:
Marc,
Below is a patch against 2.6.16-rc5, which works with CONFIG_USB_ETH
and CONFIG_USB_ETH_RNDIS.
It looks like you found the same thing tha I did, the portc bits were
set incorrectly. I was kind of hoping that you hadn't
On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 22 Feb 2006, Pete Zaitcev wrote:
Frankly, I cannot fathom Alan's resistance to it when he actually suggested
the main idea for the patch.
I'm not at all resistant to the idea. It's just that the patch
Am Mittwoch, 1. März 2006 21:16 schrieb René Rebe:
Hi,
I wonder if:
drivers/usb/core/devio.c:86
#define MAX_USBFS_BUFFER_SIZE 16384
is some random, or outdated limit or if there really is some code path that
could
not handle bigger URBs.
We are nice to the VM. 16384 is optimistic
Jamie,
The patch changes the behavior, but it still fails test 10. Now,
though, I get a bonafide error.
[EMAIL PROTECTED] ~/z/usb sudo ./testusb -a -t 10
unknown speed /proc/bus/usb/002/012
/proc/bus/usb/002/012 test 10 -- 32 (error 32)
EPIPE?
Since this works for you, I'm going to
It looks like I'm going to have to go all the way back to the
beginning. I'm seeing a STALL on the device side when I connect the
USB cable between the host and device. I don't know if this is an
issue, but I suspect that there may be several things going on. I
think that the debug messages in
Patches should apply-able with -p1 when applied at the top-level of
the source tree. I know that SVN doesn't do this and it's a big PITA.
I've switched to git and found that
a) it's a lot better suited to kernel hacking since it handles
branching properly,
b) it has the right sorts of
On Wed, 1 Mar 2006, Marc Singer wrote:
What would be handy is if there was a log of the packets being sent by
the usbtest code, and whether or not those packets had the expected
result. Is there such a log somewhere? Does the dmesg output show
this?
You can use usbmon. Read
On Wed, 1 Mar 2006, David Brownell wrote:
The -EPROTO is common after unplug, but that -EILSEQ suggests you
have a real issue in the lh7a40x_udc driver ...
Not necessarily. -EILSEQ is a normal code used by uhci-hcd when a CRC or
timeout error occurs on an IN transaction.
True,
On Wed, 1 Mar 2006, Pete Zaitcev wrote:
On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern [EMAIL PROTECTED]
wrote:
On Wed, 22 Feb 2006, Pete Zaitcev wrote:
Frankly, I cannot fathom Alan's resistance to it when he actually
suggested
the main idea for the patch.
I'm not at
On Wed, Mar 01, 2006 at 06:37:35PM +, Martin Michlmayr wrote:
* Jordan Crouse [EMAIL PROTECTED] [2006-03-01 11:30]:
Martin Michlmayr spotted this potentially serious bug. Please apply.
Please don't send patches as MIME attachments. Here it is again (with
a better summary too):
I'd appreciate some feedback about this. I'm attaching the raw log as
well as showing the output of a simple parser. There are a couple of
things that I don't know of they should bother me.
In the following output, the time stamps lead the line and are
computed as offsets from the first value.
I performed a second capture using the driver as present in the kernel
archive with a couple of changes so that it would compile. The
results are similar.
What isn't clear to me is what this apparent error code means and who
is sending it.
My annotated capture has these entries:
0:15.261198 #
On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer [EMAIL PROTECTED] wrote:
0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS )
--- 2
0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH st dv
GET_DESCRIPTOR [DEVICE_QUALIFIER 0] ) --- 10
...
0:15.261981 #
On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer [EMAIL PROTECTED] wrote:
0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS
) --- 2
0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH st dv
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Its response to #11 is what is
broken. It may be getting confused by the second status request *or*
it may have sent the STALL (is that the -32?) before it received the
second GET_STATUS.
If queueing in HCD works well,
On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Why don't you enable tracing in UDC or whatever that thing is?
I gather that you are hacking on the device, so what does it see?
Enabling DEBUG in the UDC driver makes it break even worse. Alan
Stern recommended that
On Wed, Mar 01, 2006 at 06:07:47PM -0800, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Why don't you enable tracing in UDC or whatever that thing is?
I gather that you are hacking on the device, so what does it see?
Enabling DEBUG in the
I've been using the pxa2xx_udc driver as a basis for comparison. Is
this the best we have at the moment?
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media.
I have this:
e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 0002ff00
00fa0705 02024000 00070581 0240
e2372840 1612603151 S Ci:009:00 s 80 06 0200 0400 1024
which says to me that the callback was received before the submission.
There is not another e2372840 URB
On Wed, 1 Mar 2006 18:36:57 -0800, Marc Singer [EMAIL PROTECTED] wrote:
0:33.300555 # 16 s Ci 009:00 s 80 06 0200 0400 ( DtH st dv
GET_DESCRIPTOR [CONFIGURATION 0] ) --- 1024
...
0:33.322552 # 16 c Ci 009:00 --- -121 32 = 09022000 0103fac0 01090400
0002ff00 00fa0705 02024000
On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer [EMAIL PROTECTED] wrote:
e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 0002ff00
00fa0705 02024000 00070581 0240
e2372840 1612603151 S Ci:009:00 s 80 06 0200 0400 1024
So, how can this happen? Am I seeing an
From: John Zaitseff [EMAIL PROTECTED]
The following patch to Linux kernel 2.6.16-rc5 enables the extra
keys found on the Microsoft Natural Ergonomic 4000 USB keyboard. I
had to add a number of keycodes to include/linux/input.h; feel free
to reallocate IDs assigned to these new keys.
Main
On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Its response to #11 is what is
broken. It may be getting confused by the second status request *or*
it may have sent the STALL (is that the -32?) before it
On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer [EMAIL PROTECTED] wrote:
e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400
0002ff00 00fa0705 02024000 00070581 0240
e2372840 1612603151 S Ci:009:00 s 80 06
On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer [EMAIL PROTECTED] wrote:
e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400
0002ff00 00fa0705 02024000 00070581 0240
e2372840 1612603151 S Ci:009:00 s 80 06
On Wed, Mar 01, 2006 at 07:30:16PM -0800, David Brownell wrote:
The thing to understand about test #10 is that it's _trying_ to do things
that UDC drivers often get wrong. Trying to trigger races (both events
in one IRQ), trying to issue back-to-back faults so that improper cleanup
of one
A new version of usbutils is available from the linux-usb download
area at SourceForge.net:
http://sourceforge.net/project/showfiles.php?group_id=3581package_id=142529
Changes since 0.71 are in the release notes; notably, removing usbmodules
(distros using 2.4 kernels should use older
On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Its response to #11 is what is
broken. It may be getting confused by the second
On Wed, Mar 01, 2006 at 08:51:19PM -0800, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer [EMAIL PROTECTED] wrote:
Its response to #11
53 matches
Mail list logo
