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