All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	Matt Roper <matthew.d.roper@intel.com>,
	dri-devel@lists.freedesktop.org, daniel@ffwll.ch,
	airlied@gmail.com
Subject: Re: [v3,5/5] drm/xe: Enable 32bits build
Date: Mon, 18 Mar 2024 07:34:11 -0700	[thread overview]
Message-ID: <e6ebb8ee-406e-4d2d-9932-7b48ae3721e3@roeck-us.net> (raw)
In-Reply-To: <qm5q44hs7vmq6erio7ome323xemwrg5mrxhaozkwblf6qjjvow@dqwy2oz2rrrj>

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@intel.com>
>>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>> ---
>>>  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@intel.com/
> 
> 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


  reply	other threads:[~2024-03-18 14:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19  0:16 [PATCH v3 0/5] Fix 32bit build Lucas De Marchi
2024-01-19  0:16 ` [PATCH v3 1/5] drm/xe: Use _ULL for u64 division Lucas De Marchi
2024-01-19  0:16 ` [PATCH v3 2/5] drm/xe/mmio: Cast to u64 when printing Lucas De Marchi
2024-01-19  0:16 ` [PATCH v3 3/5] drm/xe/display: Avoid calling readq() Lucas De Marchi
2024-01-19  0:25   ` Matt Roper
2024-01-19  0:16 ` [PATCH v3 4/5] drm/xe: Fix cast on trace variable Lucas De Marchi
2024-01-19  0:16 ` [PATCH v3 5/5] drm/xe: Enable 32bits build Lucas De Marchi
2024-03-17 16:14   ` [v3,5/5] " Guenter Roeck
2024-03-18 13:28     ` Lucas De Marchi
2024-03-18 14:34       ` Guenter Roeck [this message]
2024-03-21 16:40       ` Guenter Roeck
2024-01-19  0:19 ` ✓ CI.Patch_applied: success for Fix 32bit build (rev2) Patchwork
2024-01-19  0:19 ` ✗ CI.checkpatch: warning " Patchwork
2024-01-19  0:20 ` ✓ CI.KUnit: success " Patchwork
2024-01-19  0:27 ` ✓ CI.Build: " Patchwork
2024-01-19  0:27 ` ✓ CI.Hooks: " Patchwork
2024-01-19  0:29 ` ✓ CI.checksparse: " Patchwork
2024-01-19  0:53 ` ✓ CI.BAT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e6ebb8ee-406e-4d2d-9932-7b48ae3721e3@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.