From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs Date: Mon, 7 Dec 2015 13:37:44 +0100 Message-ID: <20151207123744.GZ13177@ulmo> References: <1449218769-16577-1-git-send-email-daniel.vetter@ffwll.ch> <1449218769-16577-21-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1097726328==" Return-path: In-Reply-To: <1449218769-16577-21-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Intel Graphics Development , DRI Development List-Id: intel-gfx@lists.freedesktop.org --===============1097726328== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y46NoIcKQuicSz3X" Content-Disposition: inline --Y46NoIcKQuicSz3X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 04, 2015 at 09:46:01AM +0100, Daniel Vetter wrote: > While typing these I noticed that ->dirty is a bit a can of worms > and even supports blt/fill semantics ... shocked me a bit. >=20 > Oh well it's defined in a way that nothing bad (just a bit of inefficienc= y) > will happen for drivers which supports this. So I didn't bother copying > the detailed spec into the new kerneldoc. >=20 > Signed-off-by: Daniel Vetter > --- > include/drm/drm_crtc.h | 50 +++++++++++++++++++++++++++++++++++++++++---= ------ > 1 file changed, 41 insertions(+), 9 deletions(-) >=20 > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index 72a7e096dd42..551484fb55e5 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -162,23 +162,55 @@ struct drm_tile_group { > u8 group_data[8]; > }; > =20 > +/** > + * struct drm_framebuffer_funcs - framebuffer hooks > + */ > struct drm_framebuffer_funcs { > - /* note: use drm_framebuffer_remove() */ > + /** > + * @destroy: > + * > + * Clean up framebuffer resources, specifically also unreference the > + * backing storage. The core guarantees to call this function for every > + * framebuffer succesfully created by fb_create in "successfully" and "->fb_create()"? > + /** > + * @create_handle: > + * > + * Create a buffer handle in the driver-specific buffer manager (either > + * GEM or TTM) valid for the passed-in struct &drm_file. This is used by > + * the core to implement the GETFB ioctl, which returns (for s/ioctl/IOCTL/? > + * sufficiently priviledged user) also a native buffer handle. This can "users" > + * be used for seamless transitions between modesetting clients by > + * copying the current screen contents to a private buffer and blending > + * between that and the new contents. > + * > + * RETURNS: > + * > + * 0 on success or a negative error code on failure. > + */ > int (*create_handle)(struct drm_framebuffer *fb, > struct drm_file *file_priv, > unsigned int *handle); > - /* > + /** > + * @dirty: > + * > * Optional callback for the dirty fb ioctl. > * > - * Userspace can notify the driver via this callback > - * that a area of the framebuffer has changed and should > - * be flushed to the display hardware. > + * Userspace can notify the driver via this callback that a area of the "an area" > + * framebuffer has changed and should be flushed to the display > + * hardware. This can also be used internally, e.g. by the fbdev > + * emulation, though that's not (yet) the case currently. Nit: I'd drop "(yet) " because of "currently". > + * > + * See documentation in drm_mode.h for the struct drm_mode_fb_dirty_cmd > + * for more information as all the semantics and arguments have a one to > + * one mapping on this function. Perhaps "for more information on struct drm_mode_fb_dirty_cmd as all the =2E..". Oh and I guess also &drm_mode_fb_dirty_cmd for the cross-reference? Again, fine if this is all fixed-up in a follow-up patch, since this is all from moving the documentation: Reviewed-by: Thierry Reding --Y46NoIcKQuicSz3X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWZX2YAAoJEN0jrNd/PrOhNCMP/3xEeTlh0NQsRYN2AEuxCKjH Evg74V72z3G/FhFo4Hyxn1r/+suwnJrbFWpn23zMw2mIxRriwp8Kilm0rM1EQBp4 ZCjg7xgDGYUEOjM8NAfF2RmnsZz1OwLG3BXOBmvTcYl2cDC+93XuUtBgLLZgK4/L sSgFEl6hdstzYaNZBy80HSUhNEWvaev7IxKoc2EMfW+eYOU9hEq8WkKJT8Z6KFQN xuAMJHEKbUdC/cfvSTyrrgAg7mYFw1yJSuK0Dt58+Uyw+ocG/0aZJx/5iZunGjSh KBbvoV5wRH6sXbAiT6OM47Fwy8JRH+eJ00wWDeeeEcy3LdVpSZesIK9rytIBmYB3 GKdF0x2hKjxKvc69Pkv7WxL38LYmCaJNzvobdPm09/bk93BpjEn3eN47z6n2/CHj xXf4aqaqW6MY+JMBrdZXPfJokGJOCKrQcghsL9PkD1vVIBak3CvB+PdfhHpMqsnx 2FkhB5xt4tht9H8/F22XUKXwBjqMhe+p1haKfcNDGcXXns95RzOQQsWBTpUsloFC 5+rFF+2AhcjsVtNCyuHuNXrMxbSM8IeBl2W9gKr1V1ePrY338qIO42ZUehgpjqL1 WPDBcEcRUrTIp1lVmzYQoupphuaJB0RTpXdOIE+imQpsdGdNt7YcQ3K3gqBJhxuS jnmBCpgONTG0oVC/Ur+1 =XXy6 -----END PGP SIGNATURE----- --Y46NoIcKQuicSz3X-- --===============1097726328== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK --===============1097726328==--