| Message ID | 20191031213102.17108-1-robdclark@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iommu/arm-smmu: avoid pathological RPM behaviour for unmaps | expand |
On Thu, Oct 31, 2019 at 02:31:02PM -0700, Rob Clark wrote: > From: Rob Clark <robdclark@chromium.org> > > When games, browser, or anything using a lot of GPU buffers exits, there > can be many hundreds or thousands of buffers to unmap and free. If the > GPU is otherwise suspended, this can cause arm-smmu to resume/suspend > for each buffer, resulting 5-10 seconds worth of reprogramming the > context bank (arm_smmu_write_context_bank()/arm_smmu_write_s2cr()/etc). > To the user it would appear that the system just locked up. > > A simple solution is to use pm_runtime_put_autosuspend() instead, so we > don't immediately suspend the SMMU device. > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/iommu/arm-smmu.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > index 7c503a6bc585..5abc0d210d90 100644 > --- a/drivers/iommu/arm-smmu.c > +++ b/drivers/iommu/arm-smmu.c > @@ -122,7 +122,7 @@ static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu) > static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu) > { > if (pm_runtime_enabled(smmu->dev)) > - pm_runtime_put(smmu->dev); > + pm_runtime_put_autosuspend(smmu->dev); > } > > static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) > @@ -1154,6 +1154,20 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > /* Looks ok, so add the device to the domain */ > ret = arm_smmu_domain_add_master(smmu_domain, fwspec); > > + /* > + * Setup an autosuspend delay to avoid bouncing runpm state. > + * Otherwise, if a driver for a suspendend consumer device I fixed this typo and applied with Robin's reviewed-by from before. Will
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 7c503a6bc585..5abc0d210d90 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -122,7 +122,7 @@ static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu) static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu) { if (pm_runtime_enabled(smmu->dev)) - pm_runtime_put(smmu->dev); + pm_runtime_put_autosuspend(smmu->dev); } static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) @@ -1154,6 +1154,20 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) /* Looks ok, so add the device to the domain */ ret = arm_smmu_domain_add_master(smmu_domain, fwspec); + /* + * Setup an autosuspend delay to avoid bouncing runpm state. + * Otherwise, if a driver for a suspendend consumer device + * unmaps buffers, it will runpm resume/suspend for each one. + * + * For example, when used by a GPU device, when an application + * or game exits, it can trigger unmapping 100s or 1000s of + * buffers. With a runpm cycle for each buffer, that adds up + * to 5-10sec worth of reprogramming the context bank, while + * the system appears to be locked up to the user. + */ + pm_runtime_set_autosuspend_delay(smmu->dev, 20); + pm_runtime_use_autosuspend(smmu->dev); + rpm_put: arm_smmu_rpm_put(smmu); return ret;