What does QUICC stand for? Am getting confused with SmartCard UICC. Is it anyway related?
>-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent >Pinchart >Sent: Wednesday, April 09, 2008 5:44 PM >To: [EMAIL PROTECTED] >Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; Timur Tabi; Scott Wood; David >Brownell >Subject: Re: [PATCH] Freescale QUICC Engine USB Host Controller > >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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev