From: Eric Anholt <hidden> Date: 2021-03-26 23:13:43
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
Signed-off-by: Eric Anholt <redacted>
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI isn't throwing the string of CP errors on the
faults in any of the ~10 jobs I've run so far.
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
From: Eric Anholt <hidden> Date: 2021-03-26 23:14:15
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt <redacted>
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI isn't throwing the string of CP errors on the
faults in any of the ~10 jobs I've run so far.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt <redacted>
Acked-by: Bjorn Andersson <redacted>
@Will, can you pick this together with the driver patch? (So that they
land in order)
Regards,
Bjorn
quoted hunk
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI isn't throwing the string of CP errors on the
faults in any of the ~10 jobs I've run so far.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Will Deacon <will@kernel.org> Date: 2021-03-29 14:48:14
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Eric Anholt <hidden> Date: 2021-03-29 17:56:56
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
In my past experience with DT, software looking at the (existing)
board-specific compatibles has been a typical mechanism used to
resolve something like this "ok, but you need to actually get down to
what board is involved here to figure out how to play along with the
rest of Linux that later attaches to other DT nodes". Do you have a
preferred mechanism here?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Clark <hidden> Date: 2021-03-30 04:00:28
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-03-30 09:35:47
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
quoted
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
Well it depends on what "doesn't have separate pagetables support yet"
means. I can't tell if it's a hardware issue, a firmware issue or a driver
issue.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Clark <hidden> Date: 2021-03-30 15:01:03
On Tue, Mar 30, 2021 at 2:34 AM Will Deacon [off-list ref] wrote:
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
quoted
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
quoted
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
Well it depends on what "doesn't have separate pagetables support yet"
means. I can't tell if it's a hardware issue, a firmware issue or a driver
issue.
Just a driver issue (and the fact that currently we don't have
physical access to a device... debugging a5xx per-process-pgtables by
pushing untested things to the CI farm is kind of a difficult way to
work)
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-03-30 15:32:15
On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
On Tue, Mar 30, 2021 at 2:34 AM Will Deacon [off-list ref] wrote:
quoted
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
quoted
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
quoted
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
Well it depends on what "doesn't have separate pagetables support yet"
means. I can't tell if it's a hardware issue, a firmware issue or a driver
issue.
Just a driver issue (and the fact that currently we don't have
physical access to a device... debugging a5xx per-process-pgtables by
pushing untested things to the CI farm is kind of a difficult way to
work)
But then in that case, this is using the compatible string to identify a
driver issue, no?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Clark <hidden> Date: 2021-03-30 16:05:01
On Tue, Mar 30, 2021 at 8:31 AM Will Deacon [off-list ref] wrote:
On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
quoted
On Tue, Mar 30, 2021 at 2:34 AM Will Deacon [off-list ref] wrote:
quoted
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
quoted
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
quoted
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
Well it depends on what "doesn't have separate pagetables support yet"
means. I can't tell if it's a hardware issue, a firmware issue or a driver
issue.
Just a driver issue (and the fact that currently we don't have
physical access to a device... debugging a5xx per-process-pgtables by
pushing untested things to the CI farm is kind of a difficult way to
work)
But then in that case, this is using the compatible string to identify a
driver issue, no?
Well, I suppose yes.. but OTOH it is keeping the problem out of the
dtb. Once per-process pgtables works for a5xx, there would be no dtb
change, just a change to the quirk behavior in arm-smmu-qcom.
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 30, 2021 at 08:03:36AM -0700, Rob Clark wrote:
quoted
On Tue, Mar 30, 2021 at 2:34 AM Will Deacon [off-list ref] wrote:
quoted
On Mon, Mar 29, 2021 at 09:02:50PM -0700, Rob Clark wrote:
quoted
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon [off-list ref] wrote:
quoted
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
quoted
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
What do you mean by "doesn't have separate pagetables support yet"? The
compatible string doesn't feel like the right way to determine this.
the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..
Well it depends on what "doesn't have separate pagetables support yet"
means. I can't tell if it's a hardware issue, a firmware issue or a driver
issue.
Just a driver issue (and the fact that currently we don't have
physical access to a device... debugging a5xx per-process-pgtables by
pushing untested things to the CI farm is kind of a difficult way to
work)
But then in that case, this is using the compatible string to identify a
driver issue, no?
No the compatible addition identifies the hardware, the implementation
then uses this information to know that it needs to behave "differently"
on this platform.
When/if someone decides to add the necessary support in the driver they
can remove the driver quirk, but it doesn't invalidate the specific
compatible.
Regards,
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
Signed-off-by: Eric Anholt <redacted>
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI isn't throwing the string of CP errors on the
faults in any of the ~10 jobs I've run so far.
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
From: Will Deacon <will@kernel.org> Date: 2021-06-08 11:42:46
On Fri, 26 Mar 2021 16:13:02 -0700, Eric Anholt wrote:
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.