[Intel-gfx] [PATCH 01/10] drm/i915: move display funcs into a display struct.

Dave Airlie airlied at gmail.com
Mon Sep 6 19:44:49 UTC 2021


On Mon, 6 Sept 2021 at 18:18, Jani Nikula <jani.nikula at linux.intel.com> wrote:
>
> On Mon, 06 Sep 2021, Dave Airlie <airlied at gmail.com> wrote:
> > From: Dave Airlie <airlied at redhat.com>
> >
> > This is the first step in an idea to refactor the display code
> > into a bit more of a corner.
>
> So, do we want to make i915->display a pointer?
>
> If we do, and we're about to touch every place accessing the display
> struct, we might just as well have:
>
> struct drm_i915_private {
>         struct drm_i915_display _display;
>         struct drm_i915_display *display;
> };
>
> and initialize i915->display = &i915->_display, and make all access
> happen via the pointer. If we want to allocate it dynamically at some
> point, it'll be a *much* easier task.
>
> But the first question to figure out is whether we want to do that or
> not.

I think the advantage is that we can hide a lot more structs from the
main struct,
the disadvantage is additional pointer chasing, esp for the drm_device and other
i915_priv members.

Has anyone any non-anecdotal knowledge of how bad the latter problem
actually is?
Other drivers seem to do a lot of it and nobody has complained about it.

I'm happy to move to a pointer for it all to be honest,
Dave.


More information about the Intel-gfx mailing list