On Tue, 2021-04-27 at 10:51 +0300, Jani Nikula wrote: > On Tue, 27 Apr 2021, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Tue, Apr 27, 2021 at 12:07:21AM +0000, Souza, Jose wrote: > > > On Mon, 2021-04-26 at 21:56 +0300, Ville Syrjala wrote: > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > The pipe crc code slipped theough the net when we tried to > > > > eliminate all crtc->index==pipe abuses. Remedy that. > > > > > > > > And while at it get rid of those nasty intel_crtc+drm_crtc > > > > pointer aliases. > > > > > > intel_crtc is broadly used, > > > > Not anymore. We've cleaned up almost all of it. Looks like only ~40 left > > vs. ~600 the other name. Probably a good time to clean up the rest > > finally. > > Ack. > > > > > > also we have the same for other structs like intel_connector, in my option that is better than _crtc x crtc. > > > > The _crtc is explicitly ugly to make sure people leave it well > > alone. Otherwise we can never get rid of these horrible aliasing > > pointers. It should only make an appearance in core/helper vfuncs > > and such. At some point I was even pondering some kind of macro > > magic to create semi-automatic wrappers so that we could always > > just use the intel_ types in our vfunc implementations. > > > > intel_crtc we've cleaned up the most I think, intel_encoder a bit less > > perhaps, and intel_connector not really at all. Hence you see a lot more > > of intel_connector floating around. We also don't usually use the intel_ > > types for connector states. Mainly because most of the time you don't > > need anyting from there. > > Ack. Fair enough then Reviewed-by: José Roberto de Souza <jose.souza@xxxxxxxxx> > > > BR, > Jani. > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
