All of lore.kernel.org
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: dan.j.williams@intel.com
Cc: fujita.tomonori@lab.ntt.co.jp, cjb@laptop.org,
	linux@arm.linux.org.uk, patches@linaro.org, vinod.koul@intel.com,
	gregkh@suse.de, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number
Date: Thu, 9 Jun 2011 09:07:02 +0900	[thread overview]
Message-ID: <20110609090403I.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <BANLkTikFKr+3Qph+CR40SUV-DCir1v=KBg@mail.gmail.com>

On Wed, 8 Jun 2011 13:05:57 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> Perhaps, but this sounds like the reverse of what happens today where
> scsi device drivers with knowledge of their own hardware will tell the
> midlayer/subsystem the restriction.  The change with regard to this
> patch is that the scsi device driver (for example) will recognize that
> the device it is driving will not be a bus master and will arrange to
> allocate a dma channel from dmaengine.  When said scsi driver reports
> the dma restrictions to the subsystem it will borrow the parameters
> from the dma channel, not the scsi device.  So yes, I still think it
> should be whatever the dma channel says.
> 
> Although, you've been doing scsi work longer than I, so maybe I'm
> overlooking something...?
> 
> Are there any cases today where the subsystem imposes tighter
> restrictions on the dma geometry than what the device reports?  Even

Yeah, there are already lots.

SCSI-mid layer set the max sg entries to 128 on many architectures
(see SCSI_MAX_SG_CHAIN_SEGMENTS).

SCSI HBA drivers stores the max sg entries in scsi_host structure.

SCSI-mid layer sets the tighter one (see __scsi_alloc_queue).

	blk_queue_max_segments(q, min_t(unsigned short, shost->sg_tablesize,
					SCSI_MAX_SG_CHAIN_SEGMENTS));

As you know, modern SCSI HBA can handle more sg entries than 128.


> if that were the case it would be same situation that the scsi device
> driver reports maximum parameters, but the subsystem opts for
> something tighter.  Whether the maximal parameters come from the scsi
> device or the dma channel is moot.

If only you convert all the SCSI HBA drivers to store the limit of sg
entries in struct device_dma_parameters and use the proposed API.

I can't find any description in this patchset about how we will
convert software that already set the limit of max sg entries in a
different way.

I don't think that this patchset needs to convert the SCSI (and other
software layers setting the limit of max sg entries). But I think that
we need a new rule, the data structure, and the API about how and
where everyone sets the dma restrictions and tells them to the upper
software layers.

WARNING: multiple messages have this Message-ID (diff)
From: fujita.tomonori@lab.ntt.co.jp (FUJITA Tomonori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number
Date: Thu, 9 Jun 2011 09:07:02 +0900	[thread overview]
Message-ID: <20110609090403I.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <BANLkTikFKr+3Qph+CR40SUV-DCir1v=KBg@mail.gmail.com>

On Wed, 8 Jun 2011 13:05:57 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> Perhaps, but this sounds like the reverse of what happens today where
> scsi device drivers with knowledge of their own hardware will tell the
> midlayer/subsystem the restriction.  The change with regard to this
> patch is that the scsi device driver (for example) will recognize that
> the device it is driving will not be a bus master and will arrange to
> allocate a dma channel from dmaengine.  When said scsi driver reports
> the dma restrictions to the subsystem it will borrow the parameters
> from the dma channel, not the scsi device.  So yes, I still think it
> should be whatever the dma channel says.
> 
> Although, you've been doing scsi work longer than I, so maybe I'm
> overlooking something...?
> 
> Are there any cases today where the subsystem imposes tighter
> restrictions on the dma geometry than what the device reports?  Even

Yeah, there are already lots.

SCSI-mid layer set the max sg entries to 128 on many architectures
(see SCSI_MAX_SG_CHAIN_SEGMENTS).

SCSI HBA drivers stores the max sg entries in scsi_host structure.

SCSI-mid layer sets the tighter one (see __scsi_alloc_queue).

	blk_queue_max_segments(q, min_t(unsigned short, shost->sg_tablesize,
					SCSI_MAX_SG_CHAIN_SEGMENTS));

As you know, modern SCSI HBA can handle more sg entries than 128.


> if that were the case it would be same situation that the scsi device
> driver reports maximum parameters, but the subsystem opts for
> something tighter.  Whether the maximal parameters come from the scsi
> device or the dma channel is moot.

If only you convert all the SCSI HBA drivers to store the limit of sg
entries in struct device_dma_parameters and use the proposed API.

I can't find any description in this patchset about how we will
convert software that already set the limit of max sg entries in a
different way.

I don't think that this patchset needs to convert the SCSI (and other
software layers setting the limit of max sg entries). But I think that
we need a new rule, the data structure, and the API about how and
where everyone sets the dma restrictions and tells them to the upper
software layers.

  parent reply	other threads:[~2011-06-09  0:07 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
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 [this message]
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=20110609090403I.fujita.tomonori@lab.ntt.co.jp \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=cjb@laptop.org \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@suse.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --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.