On Thu, Sep 2, 2021 at 10:46 PM Daniel Vetter [off-list ref] wrote:

On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:

quoted

On 02/09/2021 06:52, Randy Dunlap wrote:

quoted

On 9/1/21 10:48 PM, Anton Ivanov wrote:

quoted

On 02/09/2021 03:01, Randy Dunlap wrote:

quoted

boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
member named 'x86', so provide a default page protection mode
for CONFIG_UML.

Mends this build error:
../drivers/gpu/drm/ttm/ttm_module.c: In function
‘ttm_prot_from_caching’:
../drivers/gpu/drm/ttm/ttm_module.c:59:24: error: ‘struct
cpuinfo_um’ has no member named ‘x86’
   else if (boot_cpu_data.x86 > 3)
                         ^

Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for
page-based iomem")
Signed-off-by: Randy Dunlap <redacted>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Jeff Dike <redacted>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: linux-um@lists.infradead.org
Cc: David Airlie <redacted>
Cc: Daniel Vetter <redacted>
---
  drivers/gpu/drm/ttm/ttm_module.c |    4 ++++
  1 file changed, 4 insertions(+)

--- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
+++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c

@@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
      if (caching == ttm_cached)
          return tmp;
+#ifdef CONFIG_UML
+    tmp = pgprot_noncached(tmp);
+#else
  #if defined(__i386__) || defined(__x86_64__)
      if (caching == ttm_write_combined)
          tmp = pgprot_writecombine(tmp);

@@ -69,6 +72,7 @@ pgprot_t ttm_prot_from_caching(enum ttm_
  #if defined(__sparc__)
      tmp = pgprot_noncached(tmp);
  #endif
+#endif
      return tmp;
  }

Patch looks OK.

I have a question though - why all of DRM is not !UML in config. Not
like we can use them.

I have no idea about that.
Hopefully one of the (other) UML maintainers can answer you.

Touche.

We will discuss that and possibly push a patch to !UML that part of the
tree. IMHO it is not applicable.

I thought kunit is based on top of uml, and we do want to eventually adopt
that. Especially for helper libraries like ttm.

UML is not actually a dependency for KUnit, so it's definitely
possible to test things which aren't compatible with UML. (In fact,
there's even now some tooling support to use qemu instead on a number
of architectures.)

That being said, the KUnit tooling does use UML by default, so if it's
not too difficult to keep some level of UML support, it'll make it a
little easier (and faster) for people to run any KUnit tests.

Cheers,
-- David

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um