public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Mike Rapoport <mike@compulab•co.il>
To: Laurent Pinchart <laurent.pinchart@tbox•biz>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: CPM2 USB driver & MPC8248
Date: Tue, 07 Feb 2006 16:20:35 +0200	[thread overview]
Message-ID: <43E8ACB3.6030401@compulab.co.il> (raw)
In-Reply-To: <200602071414.28551.laurent.pinchart@tbox.biz>

Laurent Pinchart wrote:

>How is the driver development going ? You're not using the sourceforge CVS/SVN 
>repository, is there another one somewhere (maybe a git tree) ? Are you 
>actively working on performance issues, or is the development currently 
>stalled ? 
>  
>
The driver development is stalled and I don't know when I'll be able to 
continue working on it.

>What are the major performance issues ? 
>  
>
One of the issues in this driver is redunduncy between qe end ep 
structures and as a consequence a lot of uneeded code that make cross 
updates.
I didn't run profiling, so I can't tell better.

>I noticed that the driver uses the MPC82xx packet level interface. 
>Why don't you use the transaction level interface ?
>  
>
The original driver I've started with used packet level. I thought on 
switching to transaction level, but I hadn't time for it because of 
other projects pressure.

>  
>
>>Another thing that may cause problems is how storage devices treat SOF
>>packets, but I'm not USB expert enough to be sure about that.
>>    
>>
>
>That might explain why some devices don't even respond to the first request. I 
>noticed that, on my EP8248 board, the controller only sends 990 SOF packets 
>per second (or rather 990 SOF interrupts are generated). I might have a time 
>base problem somewhere, as I computed the number of interrupts per second 
>with a simple
>
>cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 && 
>cat /proc/driver/m8xxhci_privateh > sof.2
>
>  
>
I'm not sure such measurements are correct, since you sleep not exatly 
300 seconds. I haven't measured how many SOF interrupts I get, but I 
think you maybe right.
It may happen that during transmit or recieve the interrupts are off and 
SOF packets are not sent.

>Do you have the same problem ? I'll see if I can get my hands on a USB 
>protocol analyzer.
>  
>
Good luck, I'll try to help but unfotunately I'm very much busy with 
other projects now.

>Laurent Pinchart
>
>
>
>  
>


-- 
Sincerely yours,
Mike Rapoport

  reply	other threads:[~2006-02-07 14:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 11:10 CPM2 USB driver & MPC8248 Laurent Pinchart
2006-02-03 11:34 ` Laurent Pinchart
2006-02-03 13:11   ` Alexandre BASTOS
2006-02-03 12:46     ` Laurent Pinchart
2006-02-03 15:53       ` Alex BASTOS
2006-02-05  8:44 ` Mike Rapoport
2006-02-07 13:14   ` Laurent Pinchart
2006-02-07 14:20     ` Mike Rapoport [this message]
2006-02-07 14:33       ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E8ACB3.6030401@compulab.co.il \
    --to=mike@compulab$(echo .)co.il \
    --cc=laurent.pinchart@tbox$(echo .)biz \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox