public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christer Weinigel <christer@weinigel.se>
To: Ben Dooks <ben-linux@fluff.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch 2/3] s3cmci - call pio_tasklet from IRQ
Date: Mon, 08 Sep 2008 17:12:28 +0200	[thread overview]
Message-ID: <48C540DC.3070306@weinigel.se> (raw)
In-Reply-To: <20080908134656.GB30478@trinity.fluff.org>

Ben Dooks wrote:
> On Mon, Sep 08, 2008 at 02:48:50PM +0200, Christer Weinigel wrote:
>> Scheduling a tasklet to perform the pio transfer introduces a bit of
>> extra processing, just call pio_tasklet directly from the interrupt
>> instead.  Writing up to 64 bytes to a FIFO is probably uses less CPU
>> than scheduling a tasklet anyway.
> 
> Hmm, i'd be interested to find out how long these are taking... I might
> try and rig up something to test the time being taken via an SMDK.
> 
> If the fifo read/writes are taking significant amounts of time, then the
> pio tasklet will at least improve the interrupt latencies invloved, as
> iirc we're currently running the main irq handler in IRQ_DISABLED mode
> to stop any problems with re-enternancy.... I'll check this and see what
> is going on.

Ok, I just measured this on the 200 MHz S3C24A0, when running the SDIO 
bus at 10 MHz, the longest time I saw the driver spend in the pio_read 
function was ~10us.  I guess that means that the hardware managed to 
empty the fifo enough to do yet another spin through the loop.  So with 
a faster SDIO clock the time spent in pio_read ought to go up, and for a 
long transfer it could grow without bounds.

I also tried to run the code with the schedule_tasklet still there, and 
then I saw ~13us as the longest time spent in the loop, and every now 
and then there was a ~10ms gap when the clock stopped.

If we have working DMA, I think the PIO tasklet is unneccesary, then 
we'll do PIO for short transfers which won't affect latency much, and 
use DMA for long transfers that would have affected latency if done with 
PIO from interrupt context.

   /Christer


  parent reply	other threads:[~2008-09-08 15:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-08 12:48 [patch 0/3] s3cmci SDIO patches Christer Weinigel
2008-09-08 12:48 ` [patch 1/3] s3cmci -- support odd block transfers Christer Weinigel
2008-09-08 12:48 ` [patch 2/3] s3cmci - call pio_tasklet from IRQ Christer Weinigel
2008-09-08 13:46   ` Ben Dooks
2008-09-08 14:04     ` Christer Weinigel
2008-09-08 15:12     ` Christer Weinigel [this message]
2008-09-08 12:48 ` [patch 3/3] s3cmci - add SDIO interrupt support Christer Weinigel

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=48C540DC.3070306@weinigel.se \
    --to=christer@weinigel.se \
    --cc=ben-linux@fluff.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox