All of lore.kernel.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.co.il \
    --cc=laurent.pinchart@tbox.biz \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.