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

Mark Rutland mark.rutland at arm.com
Wed Feb 24 11:10:00 PST 2016


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.

Mark.



More information about the linux-arm-kernel mailing list