All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	Thomas Kleffel <tk@maintech.de>
Subject: Re: [PATCH 1/2] s3c24xx: DMA: don't use autoreload feature
Date: Wed, 08 Sep 2010 00:37:00 +0100	[thread overview]
Message-ID: <4C86CC9C.9070506@fluff.org> (raw)
In-Reply-To: <1283901799-20461-1-git-send-email-anarsoul@gmail.com>

On 08/09/10 00:23, Vasily Khoruzhick wrote:
> Some integrated DMA-capable hardware doesn't like autoreload
> feature of s3c24xx DMA-engine, that's why s3cmci driver
> didn't work with DMA transfers enabled.
> 
> I rewrote DMA driver not to use autoreload feature and removed
> all pre-loading features. Buffer re-load is fast enought to perform
> it in IRQ handler, and anyway I don't see any reason to waste CPU
> cycles on waiting for buffer load. Driver is much simplier now,
> it was tested with s3cmci and s3c24xx-i2s drivers on s3c2442 and
> s3c2410 SoCs and works just nice.

I found this really necessary, especially on systems where some
drivers can keep the cpu irq load high, such as pio hard-discs.

Can this be changed to a flag that is set to control the behaviour
on a per driver basis?

WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] s3c24xx: DMA: don't use autoreload feature
Date: Wed, 08 Sep 2010 00:37:00 +0100	[thread overview]
Message-ID: <4C86CC9C.9070506@fluff.org> (raw)
In-Reply-To: <1283901799-20461-1-git-send-email-anarsoul@gmail.com>

On 08/09/10 00:23, Vasily Khoruzhick wrote:
> Some integrated DMA-capable hardware doesn't like autoreload
> feature of s3c24xx DMA-engine, that's why s3cmci driver
> didn't work with DMA transfers enabled.
> 
> I rewrote DMA driver not to use autoreload feature and removed
> all pre-loading features. Buffer re-load is fast enought to perform
> it in IRQ handler, and anyway I don't see any reason to waste CPU
> cycles on waiting for buffer load. Driver is much simplier now,
> it was tested with s3cmci and s3c24xx-i2s drivers on s3c2442 and
> s3c2410 SoCs and works just nice.

I found this really necessary, especially on systems where some
drivers can keep the cpu irq load high, such as pio hard-discs.

Can this be changed to a flag that is set to control the behaviour
on a per driver basis?

  reply	other threads:[~2010-09-07 23:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-07 15:09 [PATCH 0/2] s3c24xx: fix s3cmci DMA support Vasily Khoruzhick
2010-09-07 15:09 ` Vasily Khoruzhick
2010-09-07 15:16 ` [PATCH 2/2] s3cmci: minor fixups Vasily Khoruzhick
2010-09-07 15:16   ` Vasily Khoruzhick
2010-09-07 23:15   ` Ben Dooks
2010-09-07 23:15     ` Ben Dooks
2010-09-07 23:14 ` [PATCH 0/2] s3c24xx: fix s3cmci DMA support Ben Dooks
2010-09-07 23:14   ` Ben Dooks
2010-09-07 23:23 ` [PATCH 1/2] s3c24xx: DMA: don't use autoreload feature Vasily Khoruzhick
2010-09-07 23:23   ` Vasily Khoruzhick
2010-09-07 23:37   ` Ben Dooks [this message]
2010-09-07 23:37     ` Ben Dooks
2010-09-08  6:27     ` Vasily Khoruzhick
2010-09-08  6:27       ` Vasily Khoruzhick
  -- strict thread matches above, loose matches on Subject: below --
2010-08-18 15:04 [PATCH 0/2] s3c24xx: fix DMA support for MCI Vasily Khoruzhick
2010-08-18 15:04 ` [PATCH 1/2] s3c24xx: DMA: don't use autoreload feature Vasily Khoruzhick
2010-08-18 15:04   ` Vasily Khoruzhick
2010-08-27 20:03   ` Vasily Khoruzhick
2010-08-27 20:03     ` Vasily Khoruzhick

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=4C86CC9C.9070506@fluff.org \
    --to=ben-linux@fluff.org \
    --cc=anarsoul@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=tk@maintech.de \
    /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.