[PATCH] Freescale QUICC Engine USB Host Controller

[Laurent Pinchart]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080409/0a31b605/attachment.pgp>