On Mon, 6 Sept 2021 at 18:18, Jani Nikula <[email protected]> wrote: > > On Mon, 06 Sep 2021, Dave Airlie <[email protected]> wrote: > > From: Dave Airlie <[email protected]> > > > > 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.
