All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: shawn.guo@linaro.org, patches@linaro.org, vinod.koul@intel.com,
	gregkh@suse.de, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dan.j.williams@intel.com,
	cjb@laptop.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number
Date: Mon, 6 Jun 2011 11:15:56 +0100	[thread overview]
Message-ID: <20110606101556.GE10508@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110606191041U.fujita.tomonori@lab.ntt.co.jp>

On Mon, Jun 06, 2011 at 07:12:20PM +0900, FUJITA Tomonori wrote:
> On Mon, 6 Jun 2011 10:47:51 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > On Mon, Jun 06, 2011 at 06:41:09PM +0900, FUJITA Tomonori wrote:
> > > On Mon, 6 Jun 2011 10:14:10 +0100
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > > 
> > > > On Mon, Jun 06, 2011 at 05:06:03PM +0900, FUJITA Tomonori wrote:
> > > > > max_segs isn't unrelated with the dma mapping API. I explained above,
> > > > > IOMMUs doesn't increase the number of segments (could decrease the
> > > > > number of segments by merging).
> > > > > 
> > > > > The limitation about the number of segment already lives elsewhere
> > > > > (e.g. queue's limits.max_segments).
> > > > 
> > > > I think you're missing the point entirely.
> > > > 
> > > > Lets take the problem at hand: you have two devices.  One of them is
> > > > handled by the DMA engine code.  One of them is a block device.
> > > > 
> > > > The block layer needs to know the various parameters of what is
> > > > allowable for DMA, including such things as the maximum size of a
> > > > segment, and the _number_ of segments that can be placed into any
> > > > one request.
> > > > 
> > > > As the DMA provider is _entirely_ separate and unknown to the block
> > > > device driver, the block device driver has no way to sanely provide
> > > > these parameters to the block layer - they are not a property of the
> > > > block device driver, but of the DMA provider.
> > > 
> > > struct device_dma_parameters is used for a property of the block
> > > device drivers (and scsi HBA drivers, etc). Not DMA provider. Right?
> > 
> > Wrong.  struct device_dma_parameters is a property of the _DMA_ _provider_.
> > It has to be.  Read what I said above and think about it.
> 
> I think that it's up to your definition of DMA provider.

I give up.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number
Date: Mon, 6 Jun 2011 11:15:56 +0100	[thread overview]
Message-ID: <20110606101556.GE10508@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110606191041U.fujita.tomonori@lab.ntt.co.jp>

On Mon, Jun 06, 2011 at 07:12:20PM +0900, FUJITA Tomonori wrote:
> On Mon, 6 Jun 2011 10:47:51 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > On Mon, Jun 06, 2011 at 06:41:09PM +0900, FUJITA Tomonori wrote:
> > > On Mon, 6 Jun 2011 10:14:10 +0100
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > > 
> > > > On Mon, Jun 06, 2011 at 05:06:03PM +0900, FUJITA Tomonori wrote:
> > > > > max_segs isn't unrelated with the dma mapping API. I explained above,
> > > > > IOMMUs doesn't increase the number of segments (could decrease the
> > > > > number of segments by merging).
> > > > > 
> > > > > The limitation about the number of segment already lives elsewhere
> > > > > (e.g. queue's limits.max_segments).
> > > > 
> > > > I think you're missing the point entirely.
> > > > 
> > > > Lets take the problem at hand: you have two devices.  One of them is
> > > > handled by the DMA engine code.  One of them is a block device.
> > > > 
> > > > The block layer needs to know the various parameters of what is
> > > > allowable for DMA, including such things as the maximum size of a
> > > > segment, and the _number_ of segments that can be placed into any
> > > > one request.
> > > > 
> > > > As the DMA provider is _entirely_ separate and unknown to the block
> > > > device driver, the block device driver has no way to sanely provide
> > > > these parameters to the block layer - they are not a property of the
> > > > block device driver, but of the DMA provider.
> > > 
> > > struct device_dma_parameters is used for a property of the block
> > > device drivers (and scsi HBA drivers, etc). Not DMA provider. Right?
> > 
> > Wrong.  struct device_dma_parameters is a property of the _DMA_ _provider_.
> > It has to be.  Read what I said above and think about it.
> 
> I think that it's up to your definition of DMA provider.

I give up.

  reply	other threads:[~2011-06-06 10:16 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-06  7:30 [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number Shawn Guo
2011-06-06  7:30 ` Shawn Guo
2011-06-06  7:30 ` [PATCH v2 2/3] dmaengine: mxs-dma: set up max_segment_number Shawn Guo
2011-06-06  7:30   ` Shawn Guo
2011-06-06  7:30 ` [PATCH v2 3/3] mmc: mxs-mmc: call dmaengine API to set mmc->max_segs Shawn Guo
2011-06-06  7:30   ` Shawn Guo
2011-06-06  8:06 ` [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number FUJITA Tomonori
2011-06-06  8:06   ` FUJITA Tomonori
2011-06-06  9:14   ` Russell King - ARM Linux
2011-06-06  9:14     ` Russell King - ARM Linux
2011-06-06  9:41     ` FUJITA Tomonori
2011-06-06  9:41       ` FUJITA Tomonori
2011-06-06  9:47       ` Russell King - ARM Linux
2011-06-06  9:47         ` Russell King - ARM Linux
2011-06-06 10:12         ` FUJITA Tomonori
2011-06-06 10:12           ` FUJITA Tomonori
2011-06-06 10:15           ` Russell King - ARM Linux [this message]
2011-06-06 10:15             ` Russell King - ARM Linux
2011-06-06 18:48           ` Dan Williams
2011-06-06 18:48             ` Dan Williams
2011-06-08  5:23             ` FUJITA Tomonori
2011-06-08  5:23               ` FUJITA Tomonori
2011-06-08  6:56               ` Dan Williams
2011-06-08  6:56                 ` Dan Williams
2011-06-08  7:10                 ` FUJITA Tomonori
2011-06-08  7:10                   ` FUJITA Tomonori
2011-06-08 20:05                   ` Dan Williams
2011-06-08 20:05                     ` Dan Williams
2011-06-08 20:05                     ` Dan Williams
2011-06-08 20:41                     ` Russell King - ARM Linux
2011-06-08 20:41                       ` Russell King - ARM Linux
2011-06-08 21:52                       ` Dan Williams
2011-06-08 21:52                         ` Dan Williams
2011-06-09  0:07                     ` FUJITA Tomonori
2011-06-09  0:07                       ` FUJITA Tomonori
2011-06-07 22:35 ` Dan Williams
2011-06-07 22:35   ` Dan Williams
2011-06-12 15:28   ` Shawn Guo
2011-06-12 15:28     ` Shawn Guo
2011-06-12 15:28     ` Shawn Guo
2011-06-15 12:08   ` [PATCH v3] " Shawn Guo
2011-06-15 12:08     ` Shawn Guo
2011-06-15 12:08     ` Shawn Guo
2011-06-15 16:25     ` FUJITA Tomonori
2011-06-15 16:25       ` FUJITA Tomonori
2011-06-16  9:54     ` Per Forlin
2011-06-16  9:54       ` Per Forlin
2011-06-16  9:54       ` Per Forlin
2011-06-16 12:30   ` [PATCH v3 RESEND] dma-mapping: add new " Shawn Guo
2011-06-16 12:30     ` Shawn Guo
2011-06-17 12:40     ` Matthew Wilcox
2011-06-17 12:40       ` Matthew Wilcox
2011-06-17 18:09       ` Per Forlin
2011-06-17 18:09         ` Per Forlin
2011-06-21 17:44       ` FUJITA Tomonori
2011-06-21 17:44         ` 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=20110606101556.GE10508@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=cjb@laptop.org \
    --cc=dan.j.williams@intel.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=gregkh@suse.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=shawn.guo@linaro.org \
    --cc=vinod.koul@intel.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 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.