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? BR, Jani. -- Jani Nikula, Intel
