Hi Alan, > > > > Most likely the root cause is a hardware bug in the Atmel G45. > > > > However the only way to prove this would be to replace the G45 with a > > > > different kind of system. > > > > I think I found something on this : > > > > The G45 has a 2 port USB host and 1 USB device connection. > > The device connection gets enabled by setting EN_UDPHS. > > Does the device connection share the second host port, or does it use a > separate port? How many ports are there altogether? The G45 has 2 host ports and 1 device port. On one of the host ports I use a 4-port HUB, which in turn is connected to 4x 4-port HUBs. So a lot of HUBs are used with 16 connections to the outside world basically. My tests for this issue are however done using only one HUB. btw, I tested using multiple HUBs as well directly from the G45. It runs well and I never saw it fail. Just as soon as USB device kicks in, things go wrong. However, I found some additional things : 1) I changes some timing settings in ehci-hcd.c, this seems to have overcome some problem that I had at the very first time I try to communicate. However, I also did some other things, so I may have to test it further. 2) I tested using only full-speed HUBs and this seems to run perfectly in combination with the high speed device connection. So, in this case I see no disconnects occur. After I changed the timing in item 1, I noticed that I had no startup issues any more, but still had another strange issue that I don't have when using full speed hubs. My PC communication is only a write and read. These always come in pairs. The write causes my devices that are connected to the HUB to perform some action which takes time (sometimes a lot of time, up to 5 seconds). The PC doesn't have any wait time between issuing the write and read and this works well when I use full speed HUBs. This is the expected behavior for these devices (USBTMC). However, when I use the high speed HUBs, it is necessary to wait between the write and read on the host PC, otherwise a disconnect occurs. It looks like when the USB device port receives a read while the G45 is still busy processing the write part, it will choke. But, only with high speed HUBs connected. This could all still be a G45 issue, so I asked Atmel to check on this as well. I do however notice that as soon as at91-ohci is used instead of ehci- hcd that things work as expected. I just can't find anything why the USB device part can cause an issue with ehci-hcd. Remember that high speed HUBs using ehci-hcd work perfectly when not using the USB device port. I hope the people at Atmel do have some additional ideas on this. > > Linux reports at startup : > > hub 1-0:1.0: 2 ports detected. > > > > Once Linux is started I start my gadget device driver. This enabled USB > > device and I suppose it would disable port 2. Starting USB device > > earlier than host doesn't change anything. > > If the port is shared, then yes, one would expect port 2 to be > disabled. Otherwise there is no reason to disable it, as far as I > know. > > > Port 1 is in use, port 2 is not. It is at least not accessible from > > outside the G45. > > What do you mean? Why not? Well, it's not routed on my board so I would basically like to disable it in software even though the G45 supports this port. > > I don't see how to disable it in the G45 spec though. It just speaks > > about enabling USB device. Anyway, if it's still active in the G45 but > > not accessible from outside I guess it could be considered a bug in the > > hardware. > > > > Is there a way to disable port2 in Linux ? > > You should ask the people who maintain the Atmel drivers. However, if > nothing is connected to that port then it shouldn't ever do anything. I agree. I'm just not sure if it really does nothing. > > While I communicate over the USB device, I receive the following : > > > > hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0004 > > atmel-ehci atmel-ehci: GetStatus port 2 status 001803 POWER sig=j CSC > > CONNECT hub 1-0:1.0: port 2, status 0501, change 0001, 480 Mb/s > > usb 1-2: USB disconnect, address 2 > > usb 1-2.1: USB disconnect, address 4 > > usb 1-2.1: unregistering device > > usb 1-2.1: usb_disable_device nuking all URBs > > usb 1-2.1: unregistering interface 1-2.1:1.0 > > > > Line 3 seems to indicate a change on a port that I don't use or I'm > > misinterpreting the message. > > Maybe you're misinterpreting the message. This says that a hub was > connected to port 2 (and some other device was connected to port 1 on > that hub); the message indicates that it got disconnected. OK, got it. Thanks, Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
