[PATCH] Freescale QUICC Engine USB Host Controller

[Pandita, Vikram]

What does QUICC stand for? 
Am getting confused with SmartCard UICC. Is it anyway related? 

>-----Original Message-----
>From: linux-usb-owner at vger.kernel.org [mailto:linux-usb-owner at vger.kernel.org] On Behalf Of Laurent
>Pinchart
>Sent: Wednesday, April 09, 2008 5:44 PM
>To: avorontsov at ru.mvista.com
>Cc: linuxppc-dev at ozlabs.org; linux-usb at vger.kernel.org; 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