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.
next prev 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: linkBe 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.