All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	Stefan Christ <s.christ@phytec.de>
Subject: Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC
Date: Fri, 10 Feb 2017 16:06:05 +0200	[thread overview]
Message-ID: <20170210140605.GC31595@intel.com> (raw)
In-Reply-To: <b10828a704107b4825762c3b7419bd82a5b59147.1486031436.git-series.maxime.ripard@free-electrons.com>

On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> From: Stefan Christ <s.christ@phytec.de>
> 
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Code is based on
>     https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> 
> Signed-off-by: Stefan Christ <s.christ@phytec.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++-
>  include/drm/drm_fb_helper.h     |  5 ++-
>  2 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b541feea..39a3532e311c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info: fbdev registered by the helper
> + * @cmd: ioctl command
> + * @arg: ioctl argument
> + *
> + * A helper to implement the standard fbdev ioctl. Only
> + * FBIO_WAITFORVSYNC is implemented for now.
> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg)
> +{
> +	struct drm_fb_helper *fb_helper = info->par;
> +	struct drm_device *dev = fb_helper->dev;
> +	unsigned int i;
> +	int ret = 0;
> +
> +	drm_modeset_lock_all(dev);
> +	if (!drm_fb_helper_is_bound(fb_helper)) {
> +		drm_modeset_unlock_all(dev);
> +		return -EBUSY;
> +	}
> +
> +	switch (cmd) {
> +	case FBIO_WAITFORVSYNC:
> +		for (i = 0; i < fb_helper->crtc_count; i++) {

FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
to do this for all the crtcs. Though what that crtc means for fb is
rather poorly defined.

> +			struct drm_mode_set *mode_set;
> +			struct drm_crtc *crtc;
> +
> +			mode_set = &fb_helper->crtc_info[i].mode_set;
> +			crtc = mode_set->crtc;
> +
> +			/*
> +			 * Only call drm_crtc_wait_one_vblank for crtcs that
> +			 * are currently enabled.
> +			 */
> +			if (!crtc->enabled)
> +				continue;
> +
> +			ret = drm_crtc_vblank_get(crtc);
> +			if (!ret) {
> +				drm_crtc_wait_one_vblank(crtc);
> +				drm_crtc_vblank_put(crtc);
> +			}

This looks quite sub-optimal. It should rather do something along the
lines of what drm_atomic_helper_wait_for_vblanks() does.

> +		}
> +		goto unlock;
> +	default:
> +		ret = -ENOTTY;
> +	}
> +
> +unlock:
> +	drm_modeset_unlock_all(dev);
> +	return ret;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> +
> +/**
>   * drm_fb_helper_check_var - implementation for ->fb_check_var
>   * @var: screeninfo to check
>   * @info: fbdev registered by the helper
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 975deedd593e..460be9d9fa98 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -230,7 +230,8 @@ struct drm_fb_helper {
>  	.fb_blank	= drm_fb_helper_blank, \
>  	.fb_pan_display	= drm_fb_helper_pan_display, \
>  	.fb_debug_enter = drm_fb_helper_debug_enter, \
> -	.fb_debug_leave = drm_fb_helper_debug_leave
> +	.fb_debug_leave = drm_fb_helper_debug_leave, \
> +	.fb_ioctl	= drm_fb_helper_ioctl
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
>  void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
> @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
>  
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg);
> +
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
> -- 
> git-series 0.8.11
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	David Airlie <airlied@linux.ie>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Sean Paul <seanpaul@chromium.org>,
	Stefan Christ <s.christ@phytec.de>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC
Date: Fri, 10 Feb 2017 16:06:05 +0200	[thread overview]
Message-ID: <20170210140605.GC31595@intel.com> (raw)
In-Reply-To: <b10828a704107b4825762c3b7419bd82a5b59147.1486031436.git-series.maxime.ripard@free-electrons.com>

On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> From: Stefan Christ <s.christ@phytec.de>
> 
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Code is based on
>     https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> 
> Signed-off-by: Stefan Christ <s.christ@phytec.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 55 ++++++++++++++++++++++++++++++++++-
>  include/drm/drm_fb_helper.h     |  5 ++-
>  2 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b541feea..39a3532e311c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info: fbdev registered by the helper
> + * @cmd: ioctl command
> + * @arg: ioctl argument
> + *
> + * A helper to implement the standard fbdev ioctl. Only
> + * FBIO_WAITFORVSYNC is implemented for now.
> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg)
> +{
> +	struct drm_fb_helper *fb_helper = info->par;
> +	struct drm_device *dev = fb_helper->dev;
> +	unsigned int i;
> +	int ret = 0;
> +
> +	drm_modeset_lock_all(dev);
> +	if (!drm_fb_helper_is_bound(fb_helper)) {
> +		drm_modeset_unlock_all(dev);
> +		return -EBUSY;
> +	}
> +
> +	switch (cmd) {
> +	case FBIO_WAITFORVSYNC:
> +		for (i = 0; i < fb_helper->crtc_count; i++) {

FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
to do this for all the crtcs. Though what that crtc means for fb is
rather poorly defined.

> +			struct drm_mode_set *mode_set;
> +			struct drm_crtc *crtc;
> +
> +			mode_set = &fb_helper->crtc_info[i].mode_set;
> +			crtc = mode_set->crtc;
> +
> +			/*
> +			 * Only call drm_crtc_wait_one_vblank for crtcs that
> +			 * are currently enabled.
> +			 */
> +			if (!crtc->enabled)
> +				continue;
> +
> +			ret = drm_crtc_vblank_get(crtc);
> +			if (!ret) {
> +				drm_crtc_wait_one_vblank(crtc);
> +				drm_crtc_vblank_put(crtc);
> +			}

This looks quite sub-optimal. It should rather do something along the
lines of what drm_atomic_helper_wait_for_vblanks() does.

> +		}
> +		goto unlock;
> +	default:
> +		ret = -ENOTTY;
> +	}
> +
> +unlock:
> +	drm_modeset_unlock_all(dev);
> +	return ret;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> +
> +/**
>   * drm_fb_helper_check_var - implementation for ->fb_check_var
>   * @var: screeninfo to check
>   * @info: fbdev registered by the helper
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 975deedd593e..460be9d9fa98 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -230,7 +230,8 @@ struct drm_fb_helper {
>  	.fb_blank	= drm_fb_helper_blank, \
>  	.fb_pan_display	= drm_fb_helper_pan_display, \
>  	.fb_debug_enter = drm_fb_helper_debug_enter, \
> -	.fb_debug_leave = drm_fb_helper_debug_leave
> +	.fb_debug_leave = drm_fb_helper_debug_leave, \
> +	.fb_ioctl	= drm_fb_helper_ioctl
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
>  void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
> @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
>  
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg);
> +
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
> -- 
> git-series 0.8.11
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2017-02-10 14:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 10:31 [PATCH v2 0/2] drm: Support framebuffer panning Maxime Ripard
2017-02-02 10:31 ` Maxime Ripard
2017-02-02 10:31 ` [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Maxime Ripard
2017-02-02 10:31   ` Maxime Ripard
2017-02-09 17:04   ` Daniel Vetter
2017-02-09 17:04     ` Daniel Vetter
2017-02-10 15:27     ` Maxime Ripard
2017-02-10 15:27       ` Maxime Ripard
2017-02-12 12:28   ` Laurent Pinchart
2017-02-12 12:28     ` Laurent Pinchart
2017-02-13 10:54     ` Maxime Ripard
2017-02-13 10:54       ` Maxime Ripard
2017-02-13 11:20       ` Daniel Stone
2017-02-13 11:20         ` Daniel Stone
2017-02-14 20:09         ` Daniel Vetter
2017-02-14 20:09           ` Daniel Vetter
2017-02-14 21:25           ` Laurent Pinchart
2017-02-14 21:25             ` Laurent Pinchart
2017-02-15 12:51             ` Maxime Ripard
2017-02-15 12:51               ` Maxime Ripard
2017-02-17 11:30               ` Laurent Pinchart
2017-02-15 12:38         ` Maxime Ripard
2017-02-15 12:38           ` Maxime Ripard
2017-02-17 11:23           ` Laurent Pinchart
2017-02-17 11:23             ` Laurent Pinchart
2017-02-02 10:31 ` [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard
2017-02-02 10:31   ` Maxime Ripard
2017-02-09 17:01   ` Daniel Vetter
2017-02-09 17:01     ` Daniel Vetter
2017-02-09 17:38     ` Daniel Stone
2017-02-09 17:38       ` Daniel Stone
2017-02-09 19:06       ` Daniel Vetter
2017-02-09 19:06         ` Daniel Vetter
2017-02-10 14:06   ` Ville Syrjälä [this message]
2017-02-10 14:06     ` Ville Syrjälä
2017-02-13 10:35     ` Maxime Ripard
2017-02-13 10:35       ` Maxime Ripard
2017-02-13 14:45       ` Ville Syrjälä
2017-02-13 14:45         ` Ville Syrjälä
2017-02-15 14:06         ` Maxime Ripard
2017-02-15 14:06           ` Maxime Ripard

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=20170210140605.GC31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=s.christ@phytec.de \
    /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.