linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Oliver Rutsch <orutsch@sympatec.com>
Cc: Linuxppc-dev@ozlabs.org
Subject: Re: mpc5200b PSC interrupt load on high baud rates
Date: Thu, 17 Jul 2008 13:43:01 -0600	[thread overview]
Message-ID: <20080717194301.GC6894@secretlab.ca> (raw)
In-Reply-To: <487F0A97.9050102@sympatec.com>

On Thu, Jul 17, 2008 at 11:02:15AM +0200, Oliver Rutsch wrote:
> Hi,
>
> We're using the latest 2.4.25-Kernel from DENX on a custom mpc5200b board.
> We have a RS485 device which sends continuously its data at a rate of  
> 1.25 MBit/s. The problem here is that it takes nearly 90% of system time  
> just to read these data. I had a look into the driver  
> (arch/ppc/5xxx_io/psc.c) and the problem seems to be the RxRDY interrupt  
> of the PSCs. This interrupt is inserted every time when there's any data  
> in the FIFO. I found out, that most of the time the isr is reading only  
> 1 or 2 bytes out of the FIFO, so the system is very busy to serve  
> thousands of interrupts.
> Then I set the FFULL flag as the interrupt source in the mr1 register of  
> the PSC. I set an rx alarm level of 112 bytes (means that an interrupt  
> will be generated when FIFO>=400 bytes!) and rx granularity of 7.
> With this the system load drops down under 1 percent!
> But this approach has one big drawback: There will be no interrupt if I  
> receive less than 400 bytes. So this is not usable for "normal" SIO  
> operation.
> Although not tested it looks like the same problem is in the driver for  
> the 2.6.25-Kernel (correct me when I'm wrong here).
> So I have two ideas for better performance of this driver:
>
> 1. The interrupt will be generated by the FFULL flag. An endless kernel  
> timer will have every jiffy a look at the PSC FIFO status and pull out  
> any data if necessary. A look on the PSC FIFO status is a very short  
> operation so this timer shouldn't affect the system performance too  
> much. But maybe this adds some more latency when receiving only a few 
> bytes.

This is the approach I would take.

BTW, if you want to fix this in mainline, then you'll need to migrate to
arch/powerpc.  arch/ppc is now removed from mainline.

g.

      reply	other threads:[~2008-07-17 19:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17  9:02 mpc5200b PSC interrupt load on high baud rates Oliver Rutsch
2008-07-17 19:43 ` Grant Likely [this message]

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=20080717194301.GC6894@secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=orutsch@sympatec.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).