FHCI driver adaptation for CPM2

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.

> 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

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,