Subject: Re: [PATCH] Freescale QUICC Engine USB Host Controller

From: Anton Vorontsov <[email-masked]>
Date: Thu, 3 Apr 2008 18:30:52 +0400

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?)

> - 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.

> - 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.

> - 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.

> or thought about any particular issue 
> I should pay attention to ?

Nope, sorry.

-- 
Anton Vorontsov
email: [email-masked]
irc://irc.freenode.net/bd2