Patchwork FHCI driver adaptation for CPM2

login
register
mail settings
Submitter Laurent Pinchart
Date Dec. 17, 2008, 3:33 p.m.
Message ID <200812171633.58081.laurentp@cse-semaphore.com>
Download mbox | patch
Permalink /patch/14500/
State Not Applicable, archived
Headers show

Comments

Laurent Pinchart - Dec. 17, 2008, 3:33 p.m.
Hi Remi,

On Wednesday 17 December 2008 16:10:16 Remi Lefevre wrote:
> Hi,
>
> I have a few questions with regard to adapting the FHCI USB host
> controller driver (for QE) from Anton Vorontsov to CPM2, based
> on past discussions from linuxppc-dev & linuxppc-embedded.
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-April/054253.html
>
> >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 ?
>
> Has this CPM2  patch adaptation been posted somewhere ?
> I will have soon to evaluate an USB disk on MPC8270 and it would be great
> to spend time working on adapting the patch to last gpio changes and trying
> to merge it with the original QE patch rather than doing this work again.

You will find my latest version of the CPM2 FHCI patch attached to this e-
mail. I've never bothered to clean it as we decided to drop the USB host 
function from our device.

> http://ozlabs.org/pipermail/linuxppc-embedded/2008-June/030541.html
>
> >Laurent Pinchart-4 wrote:
> >The bad news is that, from my experience with the CPM2, the controller is
> >almost unusable. It eats around 40% CPU time on my MPC8248 system, and
> >requires software help to generate SOF tokens, which results in bad SOF
> >tokens being sent on the bus. Most USB disks don't seem to care, but all
> > the USB Bluetooth host controllers I've tested crashed.
>
> Does this mean than SOF tokens handling can be ignored when working with
> USB disks, or only that they don't care of a few errors ?

This depends on the disk. Some will probably not check the SOF token, others 
will do and behave strangely.

> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how much
> does the CRC computation contribute in this CPU hogging ?

I haven't measured that, but probably not much. The biggest CPU time eater 
isn't the SOF generation interrupt but the USB packet handling code. The CPM2 
USB host controller is really too low-level to be usable (except maybe for 
specific applications). Comparing the OHCI/UHCI/EHCI and FHCI controllers is 
akin to  bit like comparing a full 16550 UART with a software bit-bang 
implementation. You can get around with it, it might work for your specific 
application, but you shouldn't try a full speed 115200bds communication while 
computing a CPU-hungry physical simulation.
Remi Lefevre - Dec. 17, 2008, 8:27 p.m.
> Hi Remi,

Hi Laurent,

> You will find my latest version of the CPM2 FHCI patch attached to this e-
> mail. I've never bothered to clean it as we decided to drop the USB host
> function from our device.

Thank you very much. Not clean is better than lost.

> This depends on the disk. Some will probably not check the SOF token, others
> will do and behave strangely.
>
>> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how much
>> does the CRC computation contribute in this CPU hogging ?
>
> I haven't measured that, but probably not much. The biggest CPU time eater
> isn't the SOF generation interrupt but the USB packet handling code. The CPM2
> USB host controller is really too low-level to be usable (except maybe for
> specific applications). Comparing the OHCI/UHCI/EHCI and FHCI controllers is
> akin to  bit like comparing a full 16550 UART with a software bit-bang
> implementation. You can get around with it, it might work for your specific
> application, but you shouldn't try a full speed 115200bds communication while
> computing a CPU-hungry physical simulation.

That's what I was afraid of. I now understand clearly why you didn't expect that
much better performance with CPM3 in a past message
(http://ozlabs.org/pipermail/linuxppc-embedded/2008-May/030508.html).
Still, as you said, it can have some use for specific applications.

Do you remember the throughput you were able to reach with this cpu overhead ?

> Laurent Pinchart
> CSE Semaphore Belgium

Kind regards,
Rémi Lefèvre
Laurent Pinchart - Dec. 18, 2008, 10:23 a.m.
Hi Remi,

On Wednesday 17 December 2008 21:27:49 Remi Lefevre wrote:
> >> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how
> >> much does the CRC computation contribute in this CPU hogging ?
> >
> > I haven't measured that, but probably not much. The biggest CPU time
> > eater isn't the SOF generation interrupt but the USB packet handling
> > code. The CPM2 USB host controller is really too low-level to be usable
> > (except maybe for specific applications). Comparing the OHCI/UHCI/EHCI
> > and FHCI controllers is akin to  bit like comparing a full 16550 UART
> > with a software bit-bang implementation. You can get around with it, it
> > might work for your specific application, but you shouldn't try a full
> > speed 115200bds communication while computing a CPU-hungry physical
> > simulation.
>
> That's what I was afraid of. I now understand clearly why you didn't expect
> that much better performance with CPM3 in a past message
> (http://ozlabs.org/pipermail/linuxppc-embedded/2008-May/030508.html).
> Still, as you said, it can have some use for specific applications.
>
> Do you remember the throughput you were able to reach with this cpu
> overhead ?

I'm sorry I don't.

Best regards,

Patch

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 755823c..0d072ef 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -22,6 +22,7 @@  config USB_ARCH_HAS_HCD
 	default y if PCMCIA && !M32R			# sl811_cs
 	default y if ARM				# SL-811
 	default y if SUPERH				# r8a66597-hcd
+	default y if CPM2				#
 	default PCI
 
 # many non-PCI SOC chips embed OHCI
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index a419c42..7b14564 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -16,6 +16,7 @@  obj-$(CONFIG_USB_UHCI_HCD)	+= host/
 obj-$(CONFIG_USB_SL811_HCD)	+= host/
 obj-$(CONFIG_USB_U132_HCD)	+= host/
 obj-$(CONFIG_USB_R8A66597_HCD)	+= host/
+obj-$(CONFIG_USB_FHCI_HCD)	+= host/
 
 obj-$(CONFIG_USB_C67X00_HCD)	+= c67x00/
 
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 33b467a..9c08bf1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -305,3 +305,23 @@  config SUPERH_ON_CHIP_R8A66597
 	help
 	   Renesas SuperH processor has USB like the R8A66597.
 	   This driver supported processor is SH7366.
+
+config USB_FHCI_HCD
+	tristate "Freescale QE USB Host Controller support"
+	depends on USB && OF_GPIO && (QUICC_ENGINE || CPM2)
+	select FSL_GTM
+	select CRC5 if CPM2
+	help
+	  Some Freescale PowerPC processors (such as MPC8360E and
+	  MPC8323) have a Full/Low Speed QE USB Host controller.
+
+	  Say "y" to enable support for such controllers, or "m" to compile
+	  it as a module: the module will be called fhci-hcd.
+
+config FHCI_DEBUG
+	bool "Freescale QE USB Host Controller debug support"
+	depends on USB_FHCI_HCD
+	select DEBUG_FS
+	help
+	  Say "y" to see some FHCI debug information and statistics
+	  throught debugfs.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index f1edda2..b71dfed 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -19,3 +19,4 @@  obj-$(CONFIG_USB_SL811_CS)	+= sl811_cs.o
 obj-$(CONFIG_USB_U132_HCD)	+= u132-hcd.o
 obj-$(CONFIG_USB_R8A66597_HCD)	+= r8a66597-hcd.o
 obj-$(CONFIG_USB_ISP1760_HCD)	+= isp1760.o
+obj-$(CONFIG_USB_FHCI_HCD)	+= fhci-hcd.o