Re: [PATCH 06/24] drm/vblank: prefer drm_crtc_vblank_crtc() over drm_vblank_crtc()

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Nov 12, 2025 at 10:26:15AM +0200, Jani Nikula wrote:
> On Tue, 11 Nov 2025, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Nov 11, 2025 at 10:43:15AM +0200, Jani Nikula wrote:
> >> On Tue, 11 Nov 2025, Thomas Zimmermann <tzimmermann@suse.de> 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 <jani.nikula@intel.com>
> >> >
> >> > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> >
> >> > 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