[PATCH] Freescale QUICC Engine USB Host Controller
laurentp at cse-semaphore.com
Wed Apr 9 22:13:44 EST 2008
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
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
T +32 (2) 387 42 59
F +32 (2) 387 42 75
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Linuxppc-dev