On Wed, Nov 12, 2025 at 10:26:15AM +0200, Jani Nikula wrote: > On Tue, 11 Nov 2025, Ville Syrjälä <[email protected]> wrote: > > On Tue, Nov 11, 2025 at 10:43:15AM +0200, Jani Nikula wrote: > >> On Tue, 11 Nov 2025, Thomas Zimmermann <[email protected]> wrote: > >> > Am 10.11.25 um 17:17 schrieb Jani Nikula: > >> >> Use the higher level function where crtc is available. > >> >> > >> >> Signed-off-by: Jani Nikula <[email protected]> > >> > > >> > Reviewed-by: Thomas Zimmermann <[email protected]> > >> > > >> > Is there a long-term plan to replace drm_vblank_crtc() entirely? > >> > Otherwise this looks a bit pointless. > >> > >> Well, almost entirely. There are a few cases (plus the one that Ville > >> mentioned later in the series) that need to operate on dev + pipe > >> alone. The main point is that when you have a crtc and use that for the > >> source of pipe, you don't have to do range checks on the pipe. This > >> becomes gradually more evident in the series. > > > > I've actaully been thinking about doing the exact opposite. > > Ie. switch drm_vblank.c over to drm_vblank_crtc completely. > > > > That is one of those things that might help with implementing > > pipe/crtc virtualization in i915. We basically want all interrupt > > stuff (including vblanks) to be tied to our hardware pipes and > > not the uapi drm_crtc. So we'd make drm_vblank_crtc==pipe, and > > introduce some kind of dynamic drm_crtc<->drm_vblank_crtc mapping > > for the uapi facing parts of drm_vblank.c... > > Ugh, so you're saying the series at hand is counter-productive?
No, I think it's fine for the most part. The only worry would be anything that starts to depend on drm_crtc rather than drm_vblank_crtc, but I don't think you had a lot of that. -- Ville Syrjälä Intel
