All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.pitre@linaro.org (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Improve MMC performance on Versatile Express
Date: Fri, 21 Jan 2011 17:20:57 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1101211655110.8580@xanadu.home> (raw)
In-Reply-To: <20110121215110.GD23151@n2100.arm.linux.org.uk>

On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 21, 2011 at 02:59:35PM -0500, Nicolas Pitre wrote:
> > On Fri, 21 Jan 2011, Pawel Moll wrote:
> > 
> > > VE suffers from serious problem with MMC transfers - low performance,
> > > errors when other IO peripherals (especially USB) are used at the
> > > same time etc.
> > > 
> > > It all boils down to the MMC controller short FIFO and - in result -
> > > timing constrains. The most problematic case - USB driver hogging
> > > CPU and MMC FIFO under/overruns in the result - can be mitigated on
> > > SMP system by distributing interrupts handling for these peripherals
> > > between cores.
> > 
> > Wouldn't the ultimate solution be to simply use FIQs to service the MMC FIFO?
> 
> Could you suggest how to route an arbitary interrupt to the FIQ using
> the GIC?

No I can't, hence my question.

> On systems which implement security extensions, the non-secure world can
> only use IRQs and not FIQs.  The secure world can use FIQs - in which
> case interrupts marked as secure interrupts can go to FIQ.

In that case, in theory, the secure world could provide some kind of 
software based DMA engine facility to the non-secure world for this FIFO 
servicing purpose.

> On systems without security extensions, the GIC only supports IRQ, and
> you need a second GIC implemented for FIQs.  I'm not aware of any system
> doing that.

The only solution in that case is to give top priority to the FIFO IRQ 
and never disable IRQs when in interrupt context, except for that FIFO 
servicing handler which should keep IRQs masked out throughout.  In any 
case this would certainly be only a hack for badly misdesigned hardware.


Nicolas

  reply	other threads:[~2011-01-21 22:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 13:59 [PATCH] arm: Improve MMC performance on Versatile Express Pawel Moll
2011-01-21 15:09 ` Sergei Shtylyov
2011-01-21 19:59 ` Nicolas Pitre
2011-01-21 21:51   ` Russell King - ARM Linux
2011-01-21 22:20     ` Nicolas Pitre [this message]
2011-01-21 22:29       ` Russell King - ARM Linux
2011-02-01 14:29         ` Linus Walleij
2011-02-01 17:25           ` Pawel Moll
2011-01-24 12:27   ` Pawel Moll
2011-01-24 13:35     ` Russell King - ARM Linux
2011-01-24 16:13       ` Pawel Moll
2011-01-24 16:24         ` Russell King - ARM Linux
2011-01-24 16:30           ` Russell King - ARM Linux
2011-01-24 16:39           ` Pawel Moll
2011-01-24 16:53             ` Russell King - ARM Linux
2011-01-24 17:03               ` Russell King - ARM Linux
2011-01-24 17:54                 ` Pawel Moll
2011-01-24 18:09                   ` Russell King - ARM Linux
2011-01-24 19:59                     ` Pawel Moll
2011-01-24 23:10                       ` Russell King - ARM Linux
2011-02-01 11:18                         ` Russell King - ARM Linux
2011-02-01 13:34                           ` Pawel Moll
2011-02-01 14:28                             ` Russell King - ARM Linux
2011-02-01 17:25                               ` Pawel Moll
2011-02-03 14:15       ` Linus Walleij

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=alpine.LFD.2.00.1101211655110.8580@xanadu.home \
    --to=nicolas.pitre@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.