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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
