On Tue 30 Mar 10:31 CDT 2021, Will Deacon 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?

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