Re: [PATCH v2 4/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits

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

On Wed, Aug 31, 2022 at 02:56:12PM +0000, Simon Ser wrote:
> On Wednesday, August 31st, 2022 at 09:50, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> 
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 86a292c3185a..cce1a1bea645 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -942,6 +942,10 @@ struct hdr_output_metadata {
> > > * Request that the page-flip is performed as soon as possible, ie. with no
> > > * delay due to waiting for vblank. This may cause tearing to be visible on
> > > * the screen.
> > > + *
> > > + * When used with atomic uAPI, the driver will return an error if the hardware
> > > + * doesn't support performing an asynchronous page-flip for this update.
> > > + * User-space should handle this, e.g. by falling back to a regular page-flip.
> > > */
> > > #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> > > #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> > 
> > Hi Simon,
> > 
> > recalling what Ville explained that enabling async flips might require
> > one more sync flip first, how is that supposed to work?
> > 
> > A TEST_ONLY commit is not allowed to change hardware state, and a
> > failing real commit is not allowed to change hardware state either
> > (right?), therefore a failing async flip cannot prepare the next flip
> > to be async, meaning async will never work.
> 
> I'd blame it on bad hw, and make it one special quirk in the driver,
> just like it does now.
> 
> Ville, thoughts?

I suppose it might be worth mentioning that special case here,
to avoid people getting confused why the first async flip was
accepted but took a full frame to complete.

-- 
Ville Syrjälä
Intel