Hi Anton, On Thursday 03 April 2008 16:30, Anton Vorontsov wrote: > On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: > > Hi Anton, > > > > On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: > > > This is patch adds support for the FHCI USB controller, as found in the > > > Freescale MPC836x and MPC832x processors. It can support Full or Low > > > speed modes. > > > > > > Quite a lot hardware is doing by itself (SOF generation, CRC generation > > > and checking), though scheduling and retransmission is on the software > > > shoulders. > > > > > > This controller does not integrate the root hub, so this driver also > > > fakes an one-port hub. External hub is required to support more than > > > one device. > > > > Would it be possible to use the driver for CPM2-based devices ? > > Probably. But no one had tried this yet. > > > The only difference I found between the CPM2 and QE USB controllers is the > > SOF handling. The QE USB controller increments the frame number itself, > > while the CPM USB controller requires the host to increment the frame > > number. > > > > At first sight the driver depends on qe_lib for: > > > > - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) > > Yeah, I already posted a patch to deal with it, see > http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html > (btw... Scott, Timur did you have a chance to look into this?)
Hope this will get into 2.6.26. I replaced all occurences of qe_muram_* by cpm_muram_* in the driver for now. > > - GPIO access (qe_gpio_set_dedicated) > > This is because of David Brownell. ;-) Specifically, unwillingness to > accept that set_dedicated is portable for some scope of GPIO controllers, > as well as GPIO users. Both sides have their arguments. As the FHCI driver is tied to CPM2/QE platforms anyway, a quick-and-dirty workaround is possible. I currently use hardcoded cpm2_set_pin calls. > > - clock routing (qe_clock_source, qe_usb_clock_set) > > Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC > doesn't use it yet. Neither I can tell if CLK API is suitable for our > needs, or if it needs to be extended. Quick&dirty workarounds are > still possible though, but clk api is the right way to go. The current clock API doesn't seem to handle clock routing, so I'm not sure what the best way to handle that is. > > - QE commands execution (qe_issue_cmd) > > No proper solution yet. > > > It shouldn't be too difficult to abstract those operation in a fashion > > similar to the cpm_uart driver. > > Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as > separate matters though. ;-) I didn't look for the reasons of this split > but I assume there are and they're strong enough. > > > Have you already worked on CPM2 support, > > Nope, I don't have CPM2 board to work on. 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. 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. Best regards, -- 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
pgp2CP9oIsraU.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev