On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote: > 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. :-)
The current version of the code is CPM2-specific and won't work on QE-based platforms. Should I still post it ? > > 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? No it didn't, it's a completely different problem. The IDLE interrupts I see every millisecond for around 175ms after disconnecting the device are probably due to the SOF tokens sent between device disconnection and the fhci_stop_sof_timer() call. Calling fhci_stop_sof_timer() in device_disconnected_interrupt() prevents spurious idle interrupts from being generated. After further investigation I found out why no idle interrupt were generated when replugging the device. Upon disconnection the FHCI driver turns bus power off by setting the suspend GPIO pin high. As the signal is connected to the suspend input of the USB phy on my hardware, setting the signal high turned the phy off, disconnecting the RP and RN signals completely. I solved the issue by referencing the bus power control GPIO instead of the suspend GPIO in the device tree. GPIO_SUSPN should really be renamed GPIO_POWER. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75
pgpAzepHbsJHa.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
