All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davem@davemloft.net, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sparc: use asm-generic/scatterlist.h
Date: Tue, 02 Mar 2010 13:38:31 +0000	[thread overview]
Message-ID: <201003021438.32144.arnd@arndb.de> (raw)
In-Reply-To: <20100302212513N.fujita.tomonori@lab.ntt.co.jp>

On Tuesday 02 March 2010, FUJITA Tomonori wrote:
> Yeah, but IIRC, Alpha, x86_64 GART, parisc, and IA64 don't have
> CONFIG_ option for IOMMU virtual merging. I prefer to avoid to adding
> something like CONFIG_HAVE_IOMMU_VMERGE for them. If we add
> CONFIG_HAVE_IOMMU_VMERGE to them, it's a bit strange not to add the
> feature to disable virtual merging for them (I guess GART already has
> the feature though).

While I think the runtime feature (actually a workaround for broken device
drivers) should be consistently used on all architectures, or removed
entirely, it's orthogonal to this discussion. I'm sure you'll come
up with a reasonable name for a new option if you introduce one.
CONFIG_HAVE_IOMMU_VMERGE and CONFIG_NEED_SG_DMA_LENGTH both seem ok
to me.

> Actually, I want to use dma_length on all the architectures (if nobody
> complains).

Fine with me as well. It wastes a small amount of memory but makes
the code more consistent.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: davem@davemloft.net, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sparc: use asm-generic/scatterlist.h
Date: Tue, 2 Mar 2010 14:38:31 +0100	[thread overview]
Message-ID: <201003021438.32144.arnd@arndb.de> (raw)
In-Reply-To: <20100302212513N.fujita.tomonori@lab.ntt.co.jp>

On Tuesday 02 March 2010, FUJITA Tomonori wrote:
> Yeah, but IIRC, Alpha, x86_64 GART, parisc, and IA64 don't have
> CONFIG_ option for IOMMU virtual merging. I prefer to avoid to adding
> something like CONFIG_HAVE_IOMMU_VMERGE for them. If we add
> CONFIG_HAVE_IOMMU_VMERGE to them, it's a bit strange not to add the
> feature to disable virtual merging for them (I guess GART already has
> the feature though).

While I think the runtime feature (actually a workaround for broken device
drivers) should be consistently used on all architectures, or removed
entirely, it's orthogonal to this discussion. I'm sure you'll come
up with a reasonable name for a new option if you introduce one.
CONFIG_HAVE_IOMMU_VMERGE and CONFIG_NEED_SG_DMA_LENGTH both seem ok
to me.

> Actually, I want to use dma_length on all the architectures (if nobody
> complains).

Fine with me as well. It wastes a small amount of memory but makes
the code more consistent.

	Arnd

  reply	other threads:[~2010-03-02 13:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-26  0:43 [PATCH] sparc: use asm-generic/scatterlist.h FUJITA Tomonori
2010-02-26  0:43 ` FUJITA Tomonori
2010-02-26 12:35 ` David Miller
2010-02-26 12:35   ` David Miller
2010-03-01  6:05   ` FUJITA Tomonori
2010-03-01  6:05     ` FUJITA Tomonori
2010-03-01  7:03     ` David Miller
2010-03-01  7:03       ` David Miller
2010-03-01 11:29     ` Arnd Bergmann
2010-03-01 11:29       ` Arnd Bergmann
2010-03-02  3:33       ` FUJITA Tomonori
2010-03-02  3:33         ` FUJITA Tomonori
2010-03-02 12:03         ` Arnd Bergmann
2010-03-02 12:03           ` Arnd Bergmann
2010-03-02 12:25           ` FUJITA Tomonori
2010-03-02 12:25             ` FUJITA Tomonori
2010-03-02 13:38             ` Arnd Bergmann [this message]
2010-03-02 13:38               ` Arnd Bergmann
2010-03-02 13:49               ` FUJITA Tomonori
2010-03-02 13:49                 ` FUJITA Tomonori
2010-03-02 13:54                 ` Arnd Bergmann
2010-03-02 13:54                   ` Arnd Bergmann
2010-03-02 13:55                   ` David Miller
2010-03-02 13:55                     ` David Miller
2010-03-02 14:06                     ` FUJITA Tomonori
2010-03-02 14:06                       ` FUJITA Tomonori

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=201003021438.32144.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@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 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.