drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely
because of the hyp limitations. Disable PRR support on that platform.
Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
I currently don't have access to other devices from these generations.
It might be necessary to apply the same workaround to other platforms.
---
Changes in v2:
- Simplify the workaround as the issue seems to be limited to SM8250
only (Rob)
- Link to v1: https://lore.kernel.org/r/20250705-iommu-fix-prr-v1-1-ef725033651c@oss.qualcomm.com
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 62874b18f6459ad9a8b0542ab81c24e3e745c53d..53d88646476e9f193a6275d9c3ee3d084c215362 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -355,7 +355,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain,
priv->set_prr_addr = NULL;
if (of_device_is_compatible(np, "qcom,smmu-500") &&
- of_device_is_compatible(np, "qcom,adreno-smmu")) {
+ !of_device_is_compatible(np, "qcom,sm8250-smmu-500") &&
+ of_device_is_compatible(np, "qcom,adreno-smmu")) {
priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit;
priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr;
}
---
base-commit: 7244e36657076b597ac21d118be9c0b0f15fc622
change-id: 20250705-iommu-fix-prr-600451b1d304
Best regards,
--
With best wishes
Dmitry
On Sat, 05 Jul 2025 19:08:33 +0300, Dmitry Baryshkov wrote: > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > because of the hyp limitations. Disable PRR support on that platform. > > Applied to iommu (arm/smmu/updates), thanks! [1/1] iommu/arm-smmu: disable PRR on SM8250 https://git.kernel.org/iommu/c/b9bb7e814cd0 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
On 7/5/2025 9:38 PM, Dmitry Baryshkov wrote: > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > because of the hyp limitations. Disable PRR support on that platform. > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Unfortunately, there is no way to detect firmware support for PRR safely from KMD. -Akhil. > --- > I currently don't have access to other devices from these generations. > It might be necessary to apply the same workaround to other platforms. > --- > Changes in v2: > - Simplify the workaround as the issue seems to be limited to SM8250 > only (Rob) > - Link to v1: https://lore.kernel.org/r/20250705-iommu-fix-prr-v1-1-ef725033651c@oss.qualcomm.com > --- > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > index 62874b18f6459ad9a8b0542ab81c24e3e745c53d..53d88646476e9f193a6275d9c3ee3d084c215362 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > @@ -355,7 +355,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, > priv->set_prr_addr = NULL; > > if (of_device_is_compatible(np, "qcom,smmu-500") && > - of_device_is_compatible(np, "qcom,adreno-smmu")) { > + !of_device_is_compatible(np, "qcom,sm8250-smmu-500") && > + of_device_is_compatible(np, "qcom,adreno-smmu")) { > priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit; > priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr; > } > > --- > base-commit: 7244e36657076b597ac21d118be9c0b0f15fc622 > change-id: 20250705-iommu-fix-prr-600451b1d304 > > Best regards,
On Sun, Jul 6, 2025 at 7:22 AM Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote: > > On 7/5/2025 9:38 PM, Dmitry Baryshkov wrote: > > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > > because of the hyp limitations. Disable PRR support on that platform. > > > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> > > Unfortunately, there is no way to detect firmware support for PRR safely > from KMD. I still am a bit curious about whether it is the ACLTR write that trips the fw out (doubtful, since we write other bits in that reg AFAICT) or the PRR_CFG_LADDR/UADDR write that does it. In the latter case we could potentially use a reserved-region for the PRR page, instead of dynamically allocating it (if we knew what values are in LADDR/UADDR.. I guess 0x0?) to avoid reduced vk functionality on these devices. AFAIU the vk extensions that depend on PRR are required for vkd3d. BR, -R > -Akhil. > > > --- > > I currently don't have access to other devices from these generations. > > It might be necessary to apply the same workaround to other platforms. > > --- > > Changes in v2: > > - Simplify the workaround as the issue seems to be limited to SM8250 > > only (Rob) > > - Link to v1: https://lore.kernel.org/r/20250705-iommu-fix-prr-v1-1-ef725033651c@oss.qualcomm.com > > --- > > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > index 62874b18f6459ad9a8b0542ab81c24e3e745c53d..53d88646476e9f193a6275d9c3ee3d084c215362 100644 > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > @@ -355,7 +355,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, > > priv->set_prr_addr = NULL; > > > > if (of_device_is_compatible(np, "qcom,smmu-500") && > > - of_device_is_compatible(np, "qcom,adreno-smmu")) { > > + !of_device_is_compatible(np, "qcom,sm8250-smmu-500") && > > + of_device_is_compatible(np, "qcom,adreno-smmu")) { > > priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit; > > priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr; > > } > > > > --- > > base-commit: 7244e36657076b597ac21d118be9c0b0f15fc622 > > change-id: 20250705-iommu-fix-prr-600451b1d304 > > > > Best regards, >
On Sun, 6 Jul 2025 at 18:20, Rob Clark <rob.clark@oss.qualcomm.com> wrote: > > On Sun, Jul 6, 2025 at 7:22 AM Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote: > > > > On 7/5/2025 9:38 PM, Dmitry Baryshkov wrote: > > > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > > > because of the hyp limitations. Disable PRR support on that platform. > > > > > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > > > Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> > > > > Unfortunately, there is no way to detect firmware support for PRR safely > > from KMD. > > I still am a bit curious about whether it is the ACLTR write that > trips the fw out (doubtful, since we write other bits in that reg > AFAICT) or the PRR_CFG_LADDR/UADDR write that does it. Indeed, write to ACTLR seems to go through, writes (or reads) to PRR_CFG_[LU]ADDR cause a reset. > In the latter > case we could potentially use a reserved-region for the PRR page, > instead of dynamically allocating it (if we knew what values are in > LADDR/UADDR.. I guess 0x0?) to avoid reduced vk functionality on these > devices. AFAIU the vk extensions that depend on PRR are required for > vkd3d. -- With best wishes Dmitry
On Sun, Jul 6, 2025 at 9:38 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > On Sun, 6 Jul 2025 at 18:20, Rob Clark <rob.clark@oss.qualcomm.com> wrote: > > > > On Sun, Jul 6, 2025 at 7:22 AM Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote: > > > > > > On 7/5/2025 9:38 PM, Dmitry Baryshkov wrote: > > > > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > > > > because of the hyp limitations. Disable PRR support on that platform. > > > > > > > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > > > > > Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> > > > > > > Unfortunately, there is no way to detect firmware support for PRR safely > > > from KMD. > > > > I still am a bit curious about whether it is the ACLTR write that > > trips the fw out (doubtful, since we write other bits in that reg > > AFAICT) or the PRR_CFG_LADDR/UADDR write that does it. > > Indeed, write to ACTLR seems to go through, writes (or reads) to > PRR_CFG_[LU]ADDR cause a reset. ok, that is what I suspected.. I think if we can somehow figure out what the inaccessible LADDR/UADDR values are, we can come up with a reserved-region workaround BR, -R > > In the latter > > case we could potentially use a reserved-region for the PRR page, > > instead of dynamically allocating it (if we knew what values are in > > LADDR/UADDR.. I guess 0x0?) to avoid reduced vk functionality on these > > devices. AFAIU the vk extensions that depend on PRR are required for > > vkd3d. > > > -- > With best wishes > Dmitry
On Sun, Jul 6, 2025 at 8:20 AM Rob Clark <rob.clark@oss.qualcomm.com> wrote: > > On Sun, Jul 6, 2025 at 7:22 AM Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote: > > > > On 7/5/2025 9:38 PM, Dmitry Baryshkov wrote: > > > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > > > because of the hyp limitations. Disable PRR support on that platform. > > > > > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > > > Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> > > > > Unfortunately, there is no way to detect firmware support for PRR safely > > from KMD. > > I still am a bit curious about whether it is the ACLTR write that > trips the fw out (doubtful, since we write other bits in that reg > AFAICT) or the PRR_CFG_LADDR/UADDR write that does it. In the latter > case we could potentially use a reserved-region for the PRR page, > instead of dynamically allocating it (if we knew what values are in > LADDR/UADDR.. I guess 0x0?) to avoid reduced vk functionality on these > devices. AFAIU the vk extensions that depend on PRR are required for > vkd3d. oh, and if it wasn't clear, that is something we can pursue, if viable, after this patch is landed. We kinda need this patch ASAP to unbreak sm8250. BR, -R > BR, > -R > > > -Akhil. > > > > > --- > > > I currently don't have access to other devices from these generations. > > > It might be necessary to apply the same workaround to other platforms. > > > --- > > > Changes in v2: > > > - Simplify the workaround as the issue seems to be limited to SM8250 > > > only (Rob) > > > - Link to v1: https://lore.kernel.org/r/20250705-iommu-fix-prr-v1-1-ef725033651c@oss.qualcomm.com > > > --- > > > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > > index 62874b18f6459ad9a8b0542ab81c24e3e745c53d..53d88646476e9f193a6275d9c3ee3d084c215362 100644 > > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > > > @@ -355,7 +355,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, > > > priv->set_prr_addr = NULL; > > > > > > if (of_device_is_compatible(np, "qcom,smmu-500") && > > > - of_device_is_compatible(np, "qcom,adreno-smmu")) { > > > + !of_device_is_compatible(np, "qcom,sm8250-smmu-500") && > > > + of_device_is_compatible(np, "qcom,adreno-smmu")) { > > > priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit; > > > priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr; > > > } > > > > > > --- > > > base-commit: 7244e36657076b597ac21d118be9c0b0f15fc622 > > > change-id: 20250705-iommu-fix-prr-600451b1d304 > > > > > > Best regards, > >
On Sat, Jul 5, 2025 at 9:08 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > On SM8250 / QRB5165-RB5 using PRR bits resets the device, most likely > because of the hyp limitations. Disable PRR support on that platform. > > Fixes: 7f2ef1bfc758 ("iommu/arm-smmu: Add support for PRR bit setup") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> > --- > I currently don't have access to other devices from these generations. > It might be necessary to apply the same workaround to other platforms. > --- > Changes in v2: > - Simplify the workaround as the issue seems to be limited to SM8250 > only (Rob) > - Link to v1: https://lore.kernel.org/r/20250705-iommu-fix-prr-v1-1-ef725033651c@oss.qualcomm.com > --- > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > index 62874b18f6459ad9a8b0542ab81c24e3e745c53d..53d88646476e9f193a6275d9c3ee3d084c215362 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > @@ -355,7 +355,8 @@ static int qcom_adreno_smmu_init_context(struct arm_smmu_domain *smmu_domain, > priv->set_prr_addr = NULL; > > if (of_device_is_compatible(np, "qcom,smmu-500") && > - of_device_is_compatible(np, "qcom,adreno-smmu")) { > + !of_device_is_compatible(np, "qcom,sm8250-smmu-500") && > + of_device_is_compatible(np, "qcom,adreno-smmu")) { > priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit; > priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr; > } > > --- > base-commit: 7244e36657076b597ac21d118be9c0b0f15fc622 > change-id: 20250705-iommu-fix-prr-600451b1d304 > > Best regards, > -- > With best wishes > Dmitry >
© 2016 - 2025 Red Hat, Inc.