From: Brian King <brking@linux.vnet.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Kreling <kreling@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
linux-scsi <linux-scsi@vger.kernel.org>,
Sreekanth Reddy <sreekanth.reddy@avagotech.com>
Subject: Re: [PATCH] mpt2sas: Fall back to 64 bit coherent mask if 64 bit DMA / 32 bit coherent mask not supported
Date: Wed, 13 May 2015 09:12:47 -0500 [thread overview]
Message-ID: <55535BDF.6020502@linux.vnet.ibm.com> (raw)
In-Reply-To: <10045033.4fV0qQU90u@wuerfel>
On 05/13/2015 08:31 AM, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 08:23:41 Brian King wrote:
>> On 05/13/2015 03:10 AM, Arnd Bergmann wrote:
>>> On Tuesday 12 May 2015 18:24:43 Brian King wrote:
>>>>
>>>> Commit 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c broke 64 bit DMA for mpt2sas on Power.
>>>> That commit changed the sequence for setting up the DMA and coherent DMA masks so
>>>> that during initialization the driver requests a 64 bit DMA mask and a 32 bit consistent
>>>> DMA mask, then later requests a 64 bit consistent DMA mask. The Power architecture does
>>>> not currently support this, which results in always falling back to a 32 bit DMA window,
>>>> which has a negative impact on performance. Tweak this algorithm slightly so that
>>>> if requesting a 32 bit consistent mask fails after we've successfully set a 64 bit
>>>> DMA mask, just try to get a 64 bit consistent mask. This should preserve existing
>>>> behavior on platforms that support mixed mask setting and restore previous functionality
>>>> to those that do not.
>>>>
>>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>>
>>> I believe the way the API is designed, it should guarantee that after dma_set_mask()
>>> succeeds for a device, dma_set_coherent_mask() with the same mask will also succeed.
>>>
>>> Could you just call dma_set_mask_and_coherent() here to avoid that complex logic?
>>
>> I don't think that would work. The mpt2sas driver wants to set the dma mask to 64bits
>> but set the coherent mask to 32 bits, then my change is to set the coherent mask to
>> 64bits if setting it to 32bit fails. I'm not seeing how using dma_set_mask_and_coherent
>> would simplify anything here.
>
> My question was more about why the driver would ask for a 32-bit coherent
> mask to start with. Is this a limitation in the mpt2sas device that can
> only have descriptors at low addresses, or is it trying to work around some
> bug in a particular host system?
I'll need help from Sreekanth in answering that. All that is in the git commit log is:
2. 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.
So, I'm not sure my patch won't break something with mpt2sas... This commit also changed
how the RDPO pools are allocated, so its possible this won't work. However, I did load
it on Power box and I'm not seeing any major problems so far. I am seeing the following message
get logged on a regular basis, not sure if its related to this change or not:
mpt2sas3: log_info(0x31120303): originator(IOP), code(0x03), sub_code(0x3112)
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2015-05-13 14:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 22:07 mpt2sas DMA mask Brian King
2015-05-12 22:10 ` Benjamin Herrenschmidt
2015-05-12 23:24 ` [PATCH] mpt2sas: Fall back to 64 bit coherent mask if 64 bit DMA / 32 bit coherent mask not supported Brian King
2015-05-13 8:10 ` Arnd Bergmann
2015-05-13 13:23 ` Brian King
2015-05-13 13:31 ` Arnd Bergmann
2015-05-13 13:59 ` James Bottomley
2015-05-13 14:12 ` Brian King [this message]
2015-05-13 16:44 ` Sreekanth Reddy
2015-05-13 20:56 ` Benjamin Herrenschmidt
2015-05-13 21:37 ` Brian King
2015-05-14 7:43 ` [RFC/PATCH] powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask < dma_mask Benjamin Herrenschmidt
2015-05-14 21:34 ` Brian King
2015-05-14 21:58 ` [RFC/PATCH v2] " Benjamin Herrenschmidt
2015-05-14 22:03 ` [RFC/PATCH v3] " Benjamin Herrenschmidt
2015-05-15 22:19 ` Brian King
2015-05-18 3:56 ` [PATCH] " Benjamin Herrenschmidt
2015-05-18 6:40 ` Michael Ellerman
2015-06-19 21:19 ` Brian King
2015-06-19 23:01 ` Benjamin Herrenschmidt
2015-06-29 19:38 ` Brian King
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=55535BDF.6020502@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=kreling@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=sreekanth.reddy@avagotech.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 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).