Hi, > However, I'm still having trouble. Perhaps you have an idea? > I can't seem to get the chip/driver to generate the CLKRDY bit in > the HCuPINT register, so it always fails due to no clock started. > I can read/write registers okay. I'm using the software reset, > but it's not entering the timeout condition. > > What's wierd, though, is that HCCONTROL is 0x00000000, which leads > me to believe that it's still in the reset state.. Do you know > what could possibly cause this? I'm assuming you're using hardware > reset, so you may not have run into this. > > I'd be very grateful for any help. > I tested the sw reset function some time ago and it had been working. But I don't use it normally so it seems to be broken now.
After looking at the chip documentation again I'm not sure whether CLKRDY should be asserted after software reset. It says the chip is put into USB_SUSPEND state after asserting HCR. CLKRDY signals the wakeup of the chip from suspend mode. Does it work, if you don't check for CLKRDY? Maybe Olav can comment on this, since the SW reset routine has been taken literally from his driver. Lothar Wassmann ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
