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

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

 



On Mon, 6 Sept 2021 at 18:18, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, 06 Sep 2021, Dave Airlie <airlied@xxxxxxxxx> wrote:
> > From: Dave Airlie <airlied@xxxxxxxxxx>
> >
> > 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.



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux