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 - 2026 Red Hat, Inc.