Skip to content

Commit 5583a55

Browse files
stephan-ghwilldeacon
authored andcommitted
iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal
Some platforms (e.g. SC8280XP and X1E) support more than 128 stream matching groups. This is more than what is defined as maximum by the ARM SMMU architecture specification. Commit 1226113 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128") disabled use of the additional groups because they don't exhibit the same behavior as the architecture supported ones. It seems like this is just another quirk of the hypervisor: When running bare-metal without the hypervisor, the additional groups appear to behave just like all others. The boot firmware uses some of the additional groups, so ignoring them in this situation leads to stream match conflicts whenever we allocate a new SMR group for the same SID. The workaround exists primarily because the bypass quirk detection fails when using a S2CR register from the additional matching groups, so let's perform the test with the last reliable S2CR (127) and then limit the number of SMR groups only if we detect that we are running below the hypervisor (because of the bypass quirk). Fixes: 1226113 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Signed-off-by: Will Deacon <will@kernel.org>
1 parent 5941f0e commit 5583a55

1 file changed

Lines changed: 17 additions & 10 deletions

File tree

drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c

Lines changed: 17 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -432,17 +432,19 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
432432

433433
/*
434434
* Some platforms support more than the Arm SMMU architected maximum of
435-
* 128 stream matching groups. For unknown reasons, the additional
436-
* groups don't exhibit the same behavior as the architected registers,
437-
* so limit the groups to 128 until the behavior is fixed for the other
438-
* groups.
435+
* 128 stream matching groups. The additional registers appear to have
436+
* the same behavior as the architected registers in the hardware.
437+
* However, on some firmware versions, the hypervisor does not
438+
* correctly trap and emulate accesses to the additional registers,
439+
* resulting in unexpected behavior.
440+
*
441+
* If there are more than 128 groups, use the last reliable group to
442+
* detect if we need to apply the bypass quirk.
439443
*/
440-
if (smmu->num_mapping_groups > 128) {
441-
dev_notice(smmu->dev, "\tLimiting the stream matching groups to 128\n");
442-
smmu->num_mapping_groups = 128;
443-
}
444-
445-
last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1);
444+
if (smmu->num_mapping_groups > 128)
445+
last_s2cr = ARM_SMMU_GR0_S2CR(127);
446+
else
447+
last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 1);
446448

447449
/*
448450
* With some firmware versions writes to S2CR of type FAULT are
@@ -465,6 +467,11 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
465467

466468
reg = FIELD_PREP(ARM_SMMU_CBAR_TYPE, CBAR_TYPE_S1_TRANS_S2_BYPASS);
467469
arm_smmu_gr1_write(smmu, ARM_SMMU_GR1_CBAR(qsmmu->bypass_cbndx), reg);
470+
471+
if (smmu->num_mapping_groups > 128) {
472+
dev_notice(smmu->dev, "\tLimiting the stream matching groups to 128\n");
473+
smmu->num_mapping_groups = 128;
474+
}
468475
}
469476

470477
for (i = 0; i < smmu->num_mapping_groups; i++) {

0 commit comments

Comments
 (0)