Re: [v3,5/5] drm/xe: Enable 32bits build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/18/24 06:28, Lucas De Marchi wrote:
On Sun, Mar 17, 2024 at 09:14:14AM -0700, Guenter Roeck wrote:
Hi,

On Thu, Jan 18, 2024 at 04:16:12PM -0800, Lucas De Marchi wrote:
Now that all the issues with 32bits are fixed, enable it again.

Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
---
 drivers/gpu/drm/xe/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
index 1b57ae38210d..1b0ef91a5d2c 100644
--- a/drivers/gpu/drm/xe/Kconfig
+++ b/drivers/gpu/drm/xe/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_XE
     tristate "Intel Xe Graphics"
-    depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT
+    depends on DRM && PCI && MMU && (m || (y && KUNIT=y))

I am curious about changes like this. Enabling 32-bit builds results in
build failures for mips_allmodconfig because the driver redefines END.
END is also used as macro in assembler code, the define happens to be
included for mips builds, and it would be difficult to change it there.

Unlike the i915 code, DRM_XE is not marked as depending on x86. This means
it will be built for pretty much all "allmodconfig" builds for all
architectures. Yet, there have been recent complaints about "allmodconfig"
builds of drm code causing build failures on "oddball" architectures.
Is there an assumption that DRM_XE (or DRM in general) is manually
excluded from all architectures where it fails to build ? If so, would

for all the reports we've been receiving we fixed the build and improved
CI to try to avoid the regressions. DRM_XE doesn't really depend on x86,
but I see your point of filtering out the "oddball architectures" or just
expose the ones we know it builds against. Yet, I don't see that
approach done in the wild in other drivers. At least on the build side, we
constantly check the reports from lkp like

https://lore.kernel.org/all/202403152008.KlwyYggO-lkp@xxxxxxxxx/

which also includes mips:

     mips                              allnoconfig   gcc
     mips                             allyesconfig   gcc

is that not sufficient? allyesconfig should be covering it afaics


All I can say is that drivers/gpu/drm/xe/xe_lrc.c doesn't build for
mips builds in the mainline kernel. This is for both allmodconfig and
allyesconfig. Both automatically build 32-bit kernels. Those builds are
only enabled with this commit. The problem is also seen with 64-bit
builds, but those are not enabled with allmodconfig/alldefconfig.
I don't know what and how exactly 0-day runs its tests, but the failure
is also seen in the drm-xe-next branch.

I am going to blame this on my environment and just exclude DRM_XE
from mips test builds going forward.

Thanks,
Guenter




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux