On Monday 24 July 2006 1:31 am, Maulik Mankad wrote: > Hi, > > I have been able to fix this issue. > > The problem was incorrect endianess. > > I removed "cpu_to_le32" macro from all the qtd and qh data structures in > "ehci-q.c" and some other relevant host files. > > My processor works in big endian and I think the Linux USB code is for > little endian processor. As a result after making the above change I was > able to resolve this issue.
Hmm, the driver works on PPC so the issue is different: that with your *specific* processor, the data structures are using a different endianness than on more mainstream EHCI implementations. You might put together an endianness patch mirroring the approach OHCI used for a similar problem. - Dave > The DMA engine was not able to transfer packets on the bus as it was > referring to some wrong address (swapped address) due to incorrect > endianess. > > Thanks for all the support I have got from the Linux USB group. > > Regards, > Maulik Mankad > > > > -----Original Message----- > From: Alan Stern [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 9:34 PM > To: Maulik Mankad > Cc: David Brownell; linux-usb-devel@lists.sourceforge.net > Subject: RE: [linux-usb-devel] EHCI IXDP465 USB Host :- : device not > accepting address 3, error -110 > > On Thu, 22 Jun 2006, Maulik Mankad wrote: > > > Hi Alan and David, > > > > First of all let me thank both of you for replying to my mail. > > > > This is what the datasheet of Intel's IXP465 say for the Embedded TT. > > > > "IXP465 USB host supports directly connected full and low speed devices > > without requiring a companion controller by including the capabilities of > a > > USB 2.0 high-speed hub transaction > > translator. Although there is no separate Transaction Translator block in > > the system, the transaction translator function normally associated with a > > high-speed hub has been implemented within the DMA and Protocol engine > > blocks. The embedded transaction translator function is an extension to > EHCI > > interface, but makes use of the standard data structures and operational > > models that exist in the EHCI specification to support full and low speed > > devices." > > Okay. You said earlier that there are no transaction translators > available; you didn't say that one is already embedded in the device. > > > (1) Can there be a problem in the DMA engine, which is not transmitting my > > descriptor requests to the device? I do not have any programmable register > > to start the DMA or to initialize it. > > You'd better ask Intel about that. They know a lot more than we do about > errors in their devices. > > > Alan- > > ============ > > About Bus trace. > > ============ > > I use the Ellisys USB analyzer (hardware) to capture the USB packets on > the > > bus. The analyzer shows the following packets. > > -> Reset > > -> High Speed Detection Handshake (Timeout) [The device properly > generates > > the High Speed Chirp but no response from host, as the host does not > support > > High Speed] > > -> SOF packets. > > -> Suspended State > > > > At this point as per the bus enumeration sequence I should get the Device > > Descriptor request on the bus. The USB analyzer does not capture this > > request. Moreover I have traced the Linux core code for the USB and it > seems > > that the request gets timed out and then aborted and removed from the > queue. > > This is why I believe its not captured by the analyzer. > > No -- the reason it is not captured by the analyzer is because the > controller never sends the request at all. Perhaps the EHCI driver > doesn't support this controller fully, or there might be some other > problem with your hardware setup. > > For instance, why do you get "Suspended State"? Why don't the SOF packets > continue? > > Alan Stern > > > > eInfochips Business Disclaimer: > This message may contain confidential, proprietary or legally Privileged > information. In case you are not the original intended Recipient of the > message, you must not, directly or indirectly, use, Disclose, distribute, > print, or copy any part of this message and you are requested to delete it > and inform the sender. Any views expressed in this message are those of the > individual sender unless otherwise stated. Nothing contained in this message > shall be construed as an offer or acceptance of any offer by eInfochips > Limited and/or eInfochips Inc("eInfochips") unless sent with that express > intent and with due authority of eInfochips. eInfochips has taken enough > precautions to prevent the spread of viruses. However the company accepts no > liability for any damage caused by any virus transmitted by this email. > > > > eInfochips Business Disclaimer: > This message may contain confidential, proprietary or legally Privileged > information. In case you are not the original intended Recipient of the > message, you must not, directly or indirectly, use, Disclose, distribute, > print, or copy any part of this message and you are requested to delete it > and inform the sender. Any views expressed in this message are those of the > individual sender unless otherwise stated. Nothing contained in this message > shall be construed as an offer or acceptance of any offer by eInfochips > Limited and/or eInfochips Inc("eInfochips") unless sent with that express > intent and with due authority of eInfochips. eInfochips has taken enough > precautions to prevent the spread of viruses. However the company accepts no > liability for any damage caused by any virus transmitted by this email. > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
