On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: [...] > I had a first go at hacking the FHCI driver to make it run on a CPM2 > platform. > Results so far are quite good. After getting rid of qe-specific APIs as > explained above, and adding SOF token generation support, I've been able to > access a mass storage device. The driver hasn't been stress-tested yet > though.
Wow, awesome! That's great news, really. Looking forward for the patch. :-) > I ran into an issue with IDLE and RESET interrupts. When the device is first > plugged into the USB port, the idle interrupt kicks in and the driver detects > the device properly. When the device is then removed, the reset interrupt is > generated and the driver handles device removal properly. Right after the > reset interrupt, idle interrupts are generated every milliseconds for around > 175ms. The status register always reports a non-idle condition when read in > the interrupt handler. The flow of idle interrupts then stops, and no idle > interrupt is generated when I replug the device. I've checked the interrupts > mask register to make sure idle interrupts were enabled. > > Have you noticed a similar behaviour when you tested the driver on your > QE-based platform ? I suspected a debouncing issue, but I should then get > idle conditions once every other time when reading the status register. Hm.. nope, I didn't see anything like that, at least not something that is affecting the driver functionality. Did out_be16(tmr->gtevr, 0xFFFF); help there? Or it's different problem? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
