On Wed, Aug 17, 2022 at 11:07:46AM +0300, Jani Nikula wrote:
On Wed, 17 Aug 2022, Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
On Tue, 16 Aug 2022, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote:
On Thu, Aug 11, 2022 at 06:07:12PM +0300, Jani Nikula wrote:
In another long-overdue cleanup, add a display sub-struct to
drm_i915_private, and start moving display related members there. Start
with display funcs that need a rename anyway to not collide with the new
display member.
Add a new header under display/ for defining struct intel_display.
Rename struct drm_i915_display_funcs to intel_display_funcs while at it.
[...]
+struct intel_display_funcs {
in the same line as comment above. Maybe we could give this struct a
better name? Because it's already inside a intel_display.funcs.crtc
display->funcs.crtc->get_pipe_config()
display->funcs.crtc->get_initial_plane_nfig()
display->funcs.crtc->enable()
display->funcs.crtc->disable()
display->funcs.crtc->commit_modeset_enables()
and then call this `struct intel_crtc_funcs`.
This can be done later as this commit itself is basically moving things
with the same name inside a substruct.
I guess my question is, are the functions inside "crtc enough" to be
called intel_crtc_funcs? Though intel_display_funcs is really too
generic too.
Maybe I'll just go with crtc.
Mmh, except we already have a bunch of struct drm_crtc_funcs with
<platform>_crtc_funcs in intel_crtc.c. Too confusing.
struct intel_random_collection_of_display_funcs. :p
The easy choice *for now* would be to stick with the struct
intel_display_funcs and live with the display->funcs.display tautology.
Acked-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
thanks
Lucas De Marchi
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
