[git pull] drm for 6.8

[Dave Airlie]

On Sat, 13 Jan 2024 at 05:33, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> On Wed, 10 Jan 2024 at 11:49, Dave Airlie <airlied at 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
> ‘print_async_put_domains_state’:
>   drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error:
> format ‘%lu’ expects argument of type ‘long unsigned int’, but
> argument 5 has type ‘int’ [-Werror=format=]
>
> 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.