Received-SPF: pass (google.com: domain of linux-kernel+bounces-25536-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CAPM=9twKBmO2Svky-zeP+KS8qWHFj9zrgeBqW9y__tUwcAYZhw@mail.gmail.com>
 <CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com>
In-Reply-To: <CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com>
From: Dave Airlie <airlied@gmail.com>
Date: Mon, 15 Jan 2024 06:00:05 +1000
Message-ID: <CAPM=9tyiH_+jMZT9hYWaQN8=nByZvJd-0bkv6sRxAsWJm_eZGQ@mail.gmail.com>
Subject: Re: [git pull] drm for 6.8
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel <dri-devel@lists.freedesktop.org>, 
	LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 13 Jan 2024 at 05:33, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, 10 Jan 2024 at 11:49, Dave Airlie <airlied@gmail.com> wrote:
> >
> > Let me know if there are any issues,
>
> Your testing is seriously lacking.
>
> This doesn't even build. The reason seems to be that commit
> b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with
> ref_tracker library") changed the 'intel_wakeref_t' type from a
> 'depot_stack_handle_t' to 'unsigned long', and as a result did this:
>
> -       drm_dbg(&i915->drm, "async_put_wakeref %u\n",
> +       drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
>                 power_domains->async_put_wakeref);
>
> meanwhile, the Xe driver has this:
>
>   drivers/gpu/drm/xe/compat-i915-headers/intel_wakeref.h:
>         typedef bool intel_wakeref_t;
>
> which has never been valid, but now the build fails with

This was a bad cross of trees, the fix was in a pull request in my
inbox about an hour after I sent the PR, it just wasn't marked urgent
and it passes all my usual test builds.

It turns out there is a Kconfig bug without EXPERT that was masking
this in my builds, hope to get that fix in soon.


>
>   drivers/gpu/drm/i915/display/intel_display_power.c: In function
> =E2=80=98print_async_put_domains_state=E2=80=99:
>   drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error:
> format =E2=80=98%lu=E2=80=99 expects argument of type =E2=80=98long unsig=
ned int=E2=80=99, but
> argument 5 has type =E2=80=98int=E2=80=99 [-Werror=3Dformat=3D]
>
> because the drm header files have this disgusting thing where a
> *header* file includes a *C* file:
>
>   In file included from ./include/drm/drm_mm.h:51,
>                  from drivers/gpu/drm/xe/xe_bo_types.h:11,
>                  from drivers/gpu/drm/xe/xe_bo.h:11,
>                  from
> ./drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11,
>                  from ./drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h=
:15,
>                  from drivers/gpu/drm/i915/display/intel_display_power.c:=
8:
>
> nasty.


>
> I made it build by fixing that broken Xe compat header file, but this
> is definitely *NOT* how things should have worked. How did this ever
> get to me without any kind of build testing?
>
> And why the %^!@$% does a header file include a C file? That's wrong
> regardless of this bug.

Huh? display_power.c includes i915_drv.h includes i915_gem_object.h
include xe_bo.h include xe_bo_types.h include drm_mm.h?

I'm not seeing the c in h, you reading that backtrace correctly?

It was built test in a few scenarios by different people and in CI,
but it does appear the Kconfig screwup was masking people from seeing
the actual bug. We had a report a few days ago and a fix was posted,
just not marked as urgent and since I never saw the build fails here I
didn't escalate it.

Dave.