linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dan.j.williams@intel.com (Dan Williams)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number
Date: Wed, 8 Jun 2011 13:05:57 -0700	[thread overview]
Message-ID: <BANLkTikFKr+3Qph+CR40SUV-DCir1v=KBg@mail.gmail.com> (raw)
In-Reply-To: <20110608160844E.fujita.tomonori@lab.ntt.co.jp>

On Wed, Jun 8, 2011 at 12:10 AM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Tue, 7 Jun 2011 23:56:21 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
>
>> > The dma parameter restriction could be due to software (HBA drivers,
>> > or subsystem). The value should be whatever the dma device driver says
>> > it is in such case?
>>
>> I'm assuming that the dma driver is taking responsibility for setting
>> this correctly. ?How would this work otherwise... HBA driver or
>> subsystem queries the dmaengine device and then sets this parameter on
>> its behalf? ?In other words dmanengine *is* the subsystem, if I am
>> understanding your definition.
>
> Oops, I meant that the subsystem is software layer above
> dmaengine. For example, SCSI subsystem sets the limit of max number of
> sglist entries. That is, it is possible that software layer above
> dmaengine could set dma limit, which is smaller than the limit of
> dmaengine?
>

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
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.

  reply	other threads:[~2011-06-08 20:05 UTC|newest]

Thread overview: 26+ 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 ` [PATCH v2 2/3] dmaengine: mxs-dma: set up max_segment_number 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  8:06 ` [PATCH v2 1/3] dmaengine: add new dma API for max_segment_number FUJITA Tomonori
2011-06-06  9:14   ` Russell King - ARM Linux
2011-06-06  9:41     ` FUJITA Tomonori
2011-06-06  9:47       ` Russell King - ARM Linux
2011-06-06 10:12         ` FUJITA Tomonori
2011-06-06 10:15           ` Russell King - ARM Linux
2011-06-06 18:48           ` Dan Williams
2011-06-08  5:23             ` FUJITA Tomonori
2011-06-08  6:56               ` Dan Williams
2011-06-08  7:10                 ` FUJITA Tomonori
2011-06-08 20:05                   ` Dan Williams [this message]
2011-06-08 20:41                     ` Russell King - ARM Linux
2011-06-08 21:52                       ` Dan Williams
2011-06-09  0:07                     ` FUJITA Tomonori
2011-06-07 22:35 ` Dan Williams
2011-06-12 15:28   ` Shawn Guo
2011-06-15 12:08   ` [PATCH v3] " Shawn Guo
2011-06-15 16:25     ` FUJITA Tomonori
2011-06-16  9:54     ` Per Forlin
2011-06-16 12:30   ` [PATCH v3 RESEND] dma-mapping: add new " Shawn Guo
2011-06-17 12:40     ` Matthew Wilcox
2011-06-17 18:09       ` Per Forlin
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='BANLkTikFKr+3Qph+CR40SUV-DCir1v=KBg@mail.gmail.com' \
    --to=dan.j.williams@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).