From: Sinan Kaya <okaya@codeaurora.org> To: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, Abhijit Mahajan <abhijit.mahajan@avagotech.com>, Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>, linux-scsi@vger.kernel.org, jcm@redhat.com, timur@codeaurora.org, linux-kernel@vger.kernel.org, Sreekanth Reddy <sreekanth.reddy@avagotech.com>, Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>, cov@codeaurora.org, linux-arm-msm@vger.kernel.org, agross@codeaurora.org, MPT-FusionLinux.pdl@avagotech.com, Hannes Reinecke <hare@suse.de> Subject: Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Date: Tue, 10 Nov 2015 14:56:36 -0500 [thread overview] Message-ID: <56424BF4.2040207@codeaurora.org> (raw) In-Reply-To: <1447184611.2187.45.camel@HansenPartnership.com> On 11/10/2015 2:43 PM, James Bottomley wrote: > The Issue, as stated by LSI is > > Initially set the consistent DMA mask to 32 bit and then change > it > to 64 bit mask after allocating RDPQ pools by calling the > function > _base_change_consistent_dma_mask. This is to ensure that all the > upper 32 bits of RDPQ entries's base address to be same. > Need somebody from mpt to confirm that this behavior is still valid for the recent cards besides altix. > If you set a 64 bit coherent mask before this point, you're benefiting > from being lucky that all the upper 32 bits of the allocations are the > same ... we can't code a driver to rely on luck. Particularly not when > the failure mode looks like it would be silent and deadly. Of course nobody wants unreliable code. I'm wondering if I was just lucky during my testing or the 92xx and 93xx hardware supports full 64 bit range. I don't have any insight into what the endpoint does or what it is capable of. > >> >Another comment here from you. >> >https://lkml.org/lkml/2015/4/2/28 >> > >> >"Well, it was originally a hack for altix, because they had no regions >> >below 4GB and had to specifically manufacture them. As you know, in >> >Linux, if Intel doesn't need it, no-one cares and the implementation >> >bitrots." >> > >> >Maybe, it is time to fix the code for more recent (even decent) hardware? > What do you mean "fix the code"? The code isn't broken, it's > parametrising issues with particular hardware. There's no software work > around (except allocating memory with the correct characteristics). Need confirmation. I'm questioning if we are stuck with this behavior because of altix or something else. If the latter case, the code could have used PCI ID to do something special for it. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Date: Tue, 10 Nov 2015 14:56:36 -0500 [thread overview] Message-ID: <56424BF4.2040207@codeaurora.org> (raw) In-Reply-To: <1447184611.2187.45.camel@HansenPartnership.com> On 11/10/2015 2:43 PM, James Bottomley wrote: > The Issue, as stated by LSI is > > Initially set the consistent DMA mask to 32 bit and then change > it > to 64 bit mask after allocating RDPQ pools by calling the > function > _base_change_consistent_dma_mask. This is to ensure that all the > upper 32 bits of RDPQ entries's base address to be same. > Need somebody from mpt to confirm that this behavior is still valid for the recent cards besides altix. > If you set a 64 bit coherent mask before this point, you're benefiting > from being lucky that all the upper 32 bits of the allocations are the > same ... we can't code a driver to rely on luck. Particularly not when > the failure mode looks like it would be silent and deadly. Of course nobody wants unreliable code. I'm wondering if I was just lucky during my testing or the 92xx and 93xx hardware supports full 64 bit range. I don't have any insight into what the endpoint does or what it is capable of. > >> >Another comment here from you. >> >https://lkml.org/lkml/2015/4/2/28 >> > >> >"Well, it was originally a hack for altix, because they had no regions >> >below 4GB and had to specifically manufacture them. As you know, in >> >Linux, if Intel doesn't need it, no-one cares and the implementation >> >bitrots." >> > >> >Maybe, it is time to fix the code for more recent (even decent) hardware? > What do you mean "fix the code"? The code isn't broken, it's > parametrising issues with particular hardware. There's no software work > around (except allocating memory with the correct characteristics). Need confirmation. I'm questioning if we are stuck with this behavior because of altix or something else. If the latter case, the code could have used PCI ID to do something special for it. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-11-10 19:56 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-09 1:57 [PATCH V2 0/3] scsi: mptxsas: updates for ARM64 Sinan Kaya 2015-11-09 1:57 ` Sinan Kaya 2015-11-09 1:57 ` [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Sinan Kaya 2015-11-09 1:57 ` Sinan Kaya 2015-11-09 7:09 ` Hannes Reinecke 2015-11-09 7:09 ` Hannes Reinecke 2015-11-09 8:59 ` Arnd Bergmann 2015-11-09 8:59 ` Arnd Bergmann 2015-11-09 14:07 ` Sinan Kaya 2015-11-09 14:07 ` Sinan Kaya 2015-11-09 14:33 ` Arnd Bergmann 2015-11-09 14:33 ` Arnd Bergmann 2015-11-09 23:22 ` Sinan Kaya 2015-11-09 23:22 ` Sinan Kaya 2015-11-09 23:29 ` Timur Tabi 2015-11-09 23:29 ` Timur Tabi 2015-11-10 8:38 ` Arnd Bergmann 2015-11-10 8:38 ` Arnd Bergmann 2015-11-10 16:06 ` Sinan Kaya 2015-11-10 16:06 ` Sinan Kaya 2015-11-10 16:47 ` Arnd Bergmann 2015-11-10 16:47 ` Arnd Bergmann 2015-11-10 17:00 ` Timur Tabi 2015-11-10 17:00 ` Timur Tabi 2015-11-10 19:13 ` Arnd Bergmann 2015-11-10 19:13 ` Arnd Bergmann 2015-11-10 21:03 ` Timur Tabi 2015-11-10 21:03 ` Timur Tabi 2015-11-10 21:54 ` Arnd Bergmann 2015-11-10 21:54 ` Arnd Bergmann 2015-11-10 21:59 ` Timur Tabi 2015-11-10 21:59 ` Timur Tabi 2015-11-10 22:08 ` Arnd Bergmann 2015-11-10 22:08 ` Arnd Bergmann 2015-11-10 17:19 ` Sinan Kaya 2015-11-10 17:19 ` Sinan Kaya 2015-11-10 18:27 ` James Bottomley 2015-11-10 18:27 ` James Bottomley 2015-11-10 19:14 ` Sinan Kaya 2015-11-10 19:14 ` Sinan Kaya 2015-11-10 19:43 ` James Bottomley 2015-11-10 19:43 ` James Bottomley 2015-11-10 19:56 ` Sinan Kaya [this message] 2015-11-10 19:56 ` Sinan Kaya 2015-11-10 20:05 ` James Bottomley 2015-11-10 20:05 ` James Bottomley 2015-11-10 20:26 ` Sinan Kaya 2015-11-10 20:26 ` Sinan Kaya 2015-11-10 20:35 ` James Bottomley 2015-11-10 20:35 ` James Bottomley 2015-11-10 19:56 ` Arnd Bergmann 2015-11-10 19:56 ` Arnd Bergmann 2015-11-10 20:58 ` Sinan Kaya 2015-11-10 20:58 ` Sinan Kaya 2015-11-10 22:06 ` Arnd Bergmann 2015-11-10 22:06 ` Arnd Bergmann 2015-11-09 14:00 ` Sinan Kaya 2015-11-09 14:00 ` Sinan Kaya 2015-11-09 1:57 ` [PATCH V2 2/3] scsi: fix compiler warning for sg Sinan Kaya 2015-11-09 1:57 ` Sinan Kaya 2015-11-09 14:14 ` Andy Shevchenko 2015-11-09 14:14 ` Andy Shevchenko 2015-11-10 3:21 ` Sinan Kaya 2015-11-10 3:21 ` Sinan Kaya 2015-11-10 3:21 ` Sinan Kaya 2015-11-10 3:26 ` Timur Tabi 2015-11-10 3:26 ` Timur Tabi 2015-11-10 4:51 ` Sinan Kaya 2015-11-10 4:51 ` Sinan Kaya 2015-11-10 4:53 ` Timur Tabi 2015-11-10 4:53 ` Timur Tabi 2015-11-10 9:23 ` Andy Shevchenko 2015-11-10 9:23 ` Andy Shevchenko 2015-11-10 10:09 ` Arnd Bergmann 2015-11-10 10:09 ` Arnd Bergmann 2015-11-09 1:57 ` [PATCH V2 3/3] scsi: mptxsas: offload IRQ execution Sinan Kaya 2015-11-09 1:57 ` Sinan Kaya 2015-11-09 7:15 ` Hannes Reinecke 2015-11-09 7:15 ` Hannes Reinecke 2015-11-09 14:01 ` Sinan Kaya 2015-11-09 14:01 ` Sinan Kaya 2015-11-10 5:59 ` Sinan Kaya 2015-11-10 5:59 ` Sinan Kaya 2015-11-10 5:59 ` Sinan Kaya 2016-03-16 15:31 ` Christopher Covington 2016-03-16 15:31 ` Christopher Covington
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=56424BF4.2040207@codeaurora.org \ --to=okaya@codeaurora.org \ --cc=James.Bottomley@HansenPartnership.com \ --cc=MPT-FusionLinux.pdl@avagotech.com \ --cc=abhijit.mahajan@avagotech.com \ --cc=agross@codeaurora.org \ --cc=arnd@arndb.de \ --cc=cov@codeaurora.org \ --cc=hare@suse.de \ --cc=jcm@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=nagalakshmi.nandigama@avagotech.com \ --cc=praveen.krishnamoorthy@avagotech.com \ --cc=sreekanth.reddy@avagotech.com \ --cc=timur@codeaurora.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: 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.