[PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

[Tirumalesh Chalamarla]

On 02/24/2016 11:10 AM, Mark Rutland wrote:
> On Wed, Feb 24, 2016 at 03:54:48PM +0000, Chalamarla, Tirumalesh wrote:
>>
>> On 2/24/16, 3:32 AM, "Mark Rutland" <mark.rutland at arm.com> wrote:
>>
>>> On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
>>>> in Summary,
>>>>
>>>> if i change asid-base to cavium,asid-base and still use DT for
>>>> supplying base value, is this a solution that will be accepted,
>>>
>>> No. The property is _insufficient_, regardless of its name. This has
>>> been pointed out more than once.
>>>
>>> A base alone does not tell you what set of IDs it is valid to use
>>> without risking a clash. The OS is well within its rights to allocate
>>> _any_ ID above that base. It is not a requirement of the hardware nor
>>> the binding that the OS allocate a contiguous set of IDs starting at the
>>> base.
>>>
>>> Consider:
>>>
>>> smmu_a {
>>> 	whatver,*id-base = <128>;
>>> };
>>>
>>> smmu_b {
>>> 	whatever,*id-base = <64>;
>>> };
>>>
>>> In both cases, the *IDs 129+ could be allocated on both SMMUs.
>>
>> Does adding a check to see if base + number of contexts supported will not overlap with each other
>> Make it acceptable.
>> Or do you want the size be provided from DT also?
>
> At this point I think Robin's suggestion of giving the ThunderX SMMU a
> different compatible string and treating that as a separate case
> entirely is the best thing to do.
>
> Then the only requirement is that _all_ the ThunderX SMMUs with shared
> TLBs are under the control of the OS, and it can allocate IDs as it
> chooses, so long as it ensures that there are no conflicts across all
> the SMMUs it is in control of.
>
yes, resending based on the suggestions.
> Mark.
>