All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 5/5] drm/atomic-helpers: make mode_set hooks optional
Date: Sun, 22 Feb 2015 20:17:04 +0200	[thread overview]
Message-ID: <1702272.0DLRK3sWoy@avalon> (raw)
In-Reply-To: <3330807.tW96iQzFTQ@avalon>

Hi Daniel,

On Sunday 22 February 2015 19:53:23 Laurent Pinchart wrote:
> On Sunday 22 February 2015 12:24:20 Daniel Vetter wrote:
> > With runtime PM the hw might still be off while doing the ->mode_set
> > callbacks - runtime PM get/put should only happen in the
> > enable/disable hooks to properly support DPMS. Which essentially makes
> > these callbacks useless for drivers support runtime PM, so make them
> > optional. Again motivated by discussions with Laurent.
> > 
> > Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> I think we should go one step further and remove .mode_set() completely for
> drivers converted to atomic updates. There are two cases to consider:
> 
> - Drivers that implement runtime PM can't use the .mode_set() callback for
> the reason explained above. Those drivers will thus not implement
> .mode_set() and will perform mode setting related hardware configuration in
> .enable().
> 
> - Drivers that don't implement runtime PM (we probably want to discourage
> this globally, but that's a different topic) can use the .mode_set()
> callbacks, but they could equally well perform mode setting in .enable() as
> the runtime PM- enabled drivers, without any drawback.
> 
> To increase consistency, I thus believe we should get rid of .mode_set()
> completely for drivers converted to atomic updates.

On second thought, I've confused .mode_set() and .mode_set_nofb(). .mode_set() 
still makes sense for encoders, but the above reasoning should apply in my 
opinion for the CRTC .mode_set_nofb().

> However, this patch is good as a first step, so if you want to apply it
> already,
> 
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> > ---
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
> >  include/drm/drm_crtc_helper.h       | 3 ++-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c index 9fd3466bf277..5e10bcb7d98d
> > 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -723,7 +723,7 @@ crtc_set_mode(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> > 
> >  		funcs = crtc->helper_private;
> > 
> > -		if (crtc->state->enable) {
> > +		if (crtc->state->enable && funcs->mode_set_nofb) {
> > 
> >  			DRM_DEBUG_ATOMIC("modeset on [CRTC:%d]\n",
> >  			
> >  					 crtc->base.id);
> > 
> > @@ -759,7 +759,8 @@ crtc_set_mode(struct drm_device *dev, struct
> > drm_atomic_state *old_state) * Each encoder has at most one connector
> > (since we always steal * it away), so we won't call call mode_set hooks
> > twice.
> > 
> >  		 */
> > 
> > -		funcs->mode_set(encoder, mode, adjusted_mode);
> > +		if (funcs->mode_set)
> > +			funcs->mode_set(encoder, mode, adjusted_mode);
> > 
> >  		if (encoder->bridge && encoder->bridge->funcs->mode_set)
> >  		
> >  			encoder->bridge->funcs->mode_set(encoder->bridge,
> > 
> > diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> > index c250a22b39ab..92d5135b55d2 100644
> > --- a/include/drm/drm_crtc_helper.h
> > +++ b/include/drm/drm_crtc_helper.h
> > @@ -89,6 +89,7 @@ struct drm_crtc_helper_funcs {
> > 
> >  	int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
> >  	
> >  			struct drm_display_mode *adjusted_mode, int x, int y,
> >  			struct drm_framebuffer *old_fb);
> > 
> > +	/* Actually set the mode for atomic helpers, optional */
> > 
> >  	void (*mode_set_nofb)(struct drm_crtc *crtc);
> >  	
> >  	/* Move the crtc on the current fb to the given position *optional* 
*/
> > 
> > @@ -119,7 +120,7 @@ struct drm_crtc_helper_funcs {
> > 
> >   * @mode_fixup: try to fixup proposed mode for this connector
> >   * @prepare: part of the disable sequence, called before the CRTC modeset
> >   * @commit: called after the CRTC modeset
> > 
> > - * @mode_set: set this mode
> > + * @mode_set: set this mode, optional for atomic helpers
> > 
> >   * @get_crtc: return CRTC that the encoder is currently attached to
> >   * @detect: connection status detection
> >   * @disable: disable encoder when not in use (overrides DPMS off)

-- 
Regards,

Laurent Pinchart

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-02-22 18:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-22 11:24 [PATCH 1/5] drm: Add DRM_DEBUG_ATOMIC Daniel Vetter
2015-02-22 11:24 ` [PATCH 2/5] drm: If available use atomic state in getcrtc ioctl Daniel Vetter
2015-02-22 16:10   ` [Intel-gfx] " Rob Clark
2015-02-22 11:24 ` [PATCH 3/5] drm/atomic: Rename drm_atomic_helper_commit_pre_planes() state argument Daniel Vetter
2015-02-22 16:11   ` Rob Clark
2015-02-22 11:24 ` [PATCH 4/5] drm/atomic-helper: Rename commmit_post/pre_planes Daniel Vetter
2015-02-22 16:13   ` Rob Clark
2015-02-22 18:05   ` Laurent Pinchart
2015-02-22 11:24 ` [PATCH 5/5] drm/atomic-helpers: make mode_set hooks optional Daniel Vetter
2015-02-22 16:33   ` shuang.he
2015-02-22 17:53   ` Laurent Pinchart
2015-02-22 18:17     ` Laurent Pinchart [this message]
2015-02-23 10:23       ` Daniel Vetter
2015-02-22 16:09 ` [PATCH 1/5] drm: Add DRM_DEBUG_ATOMIC Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1702272.0DLRK3sWoy@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.