From: Sam Ravnborg <sam@ravnborg.org>
To: Sean Paul <sean@poorly.run>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
David Airlie <airlied@linux.ie>,
Sean Paul <seanpaul@chromium.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 01/11] drm: Add atomic variants of enable/disable to encoder helper funcs
Date: Tue, 11 Jun 2019 20:53:52 +0200 [thread overview]
Message-ID: <20190611185352.GA16305@ravnborg.org> (raw)
In-Reply-To: <20190611160844.257498-2-sean@poorly.run>
Hi Sean.
Nits below.
>
> + /**
> + * @atomic_disable:
> + *
...
> + *
> + * This callback is a variant of @disable that provides the atomic state
> + * to the driver. It takes priority over @disable during atomic commits.
> + *
> + * This hook is used only by atomic helpers. Atomic drivers don't need
> + * to implement it if there's no need to disable anything at the encoder
> + * level. To ensure that runtime PM handling (using either DPMS or the
> + * new "ACTIVE" property) works @atomic_disable must be the inverse of
> + * @atomic_enable.
> + */
> + void (*atomic_disable)(struct drm_encoder *encoder,
> + struct drm_atomic_state *state);
> +
> + /**
> + * @atomic_enable:
> + *
...
> + *
> + * This callback is a variant of @enable that provides the atomic state
> + * to the driver. It is called in place of @enable during atomic
> + * commits.
The wording in this paragrap is not the same as the similar paragraph
above.
One says "it takes priority over"
Another says "called in place of"
Maybe be a bit more explicit and say that "if atomic_{dis,en}able is
define then {dis,en}able is not called?
> + *
> + * This hook is used only by atomic helpers, for symmetry with @disable.
I do not get the "for symmetry with @disable."?
> + * Atomic drivers don't need to implement it if there's no need to
> + * enable anything at the encoder level. To ensure that runtime PM
> + * handling (using either DPMS or the new "ACTIVE" property) works
> + * @enable must be the inverse of @disable for atomic drivers.
Did you want to say "@atomic_enable must be the inverse of @atomic_disable for atomic drivers."?
> + */
> + void (*atomic_enable)(struct drm_encoder *encoder,
> + struct drm_atomic_state *state);
> +
> /**
> * @disable:
> *
> @@ -695,6 +740,9 @@ struct drm_encoder_helper_funcs {
> * handling (using either DPMS or the new "ACTIVE" property) works
> * @disable must be the inverse of @enable for atomic drivers.
> *
> + * For atomic drivers also consider @atomic_disable and save yourself
> + * from having to read the NOTE below!
Maybe, if this is so, say that atomic drivers shall alwyas use the
atomic_* variants?
And then add a TODO entry to make it so for the other atomic drivers?
> + *
> * NOTE:
> *
> * With legacy CRTC helpers there's a big semantic difference between
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-06-11 18:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 16:08 [PATCH v5 00/11] drm: Add self refresh helpers Sean Paul
2019-06-11 16:08 ` [PATCH v5 01/11] drm: Add atomic variants of enable/disable to encoder helper funcs Sean Paul
2019-06-11 18:53 ` Sam Ravnborg [this message]
2019-06-11 20:22 ` Sean Paul
2019-06-11 20:49 ` [PATCH v6 " Sean Paul
2019-06-11 16:08 ` [PATCH v5 02/11] drm: Add drm_atomic_get_(old|new_connector_for_encoder() helpers Sean Paul
2019-06-11 18:57 ` Sam Ravnborg
2019-06-11 20:51 ` [PATCH v6 02/11] drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers Sean Paul
2019-06-11 16:08 ` [PATCH v5 03/11] drm: Add atomic variants for bridge enable/disable Sean Paul
2019-06-11 16:08 ` [PATCH v5 04/11] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state Sean Paul
2019-06-11 17:58 ` Laurent Pinchart
2019-06-11 16:08 ` [PATCH v5 05/11] drm: Add helpers to kick off self refresh mode in drivers Sean Paul
2019-06-11 20:56 ` Sam Ravnborg
2019-06-12 14:19 ` Sean Paul
2019-06-12 14:50 ` [PATCH v6] " Sean Paul
2019-06-11 16:08 ` [PATCH v5 06/11] drm/rockchip: Use dirtyfb helper Sean Paul
2019-06-11 17:39 ` Daniel Vetter
2019-06-11 18:09 ` Sean Paul
2019-06-11 16:08 ` [PATCH v5 07/11] drm/rockchip: Check for fast link training before enabling psr Sean Paul
2019-07-25 18:08 ` Sean Paul
2019-07-25 18:39 ` Heiko Stuebner
2019-07-26 18:52 ` Sean Paul
2019-06-11 16:08 ` [PATCH v5 08/11] drm/rockchip: Use the helpers for PSR Sean Paul
2019-06-11 16:08 ` [PATCH v5 09/11] drm/rockchip: Use vop_win in vop_win_disable instead of vop_win_data Sean Paul
2019-06-11 16:08 ` [PATCH v5 10/11] drm/rockchip: Don't fully disable vop on self refresh Sean Paul
2019-06-11 16:08 ` [PATCH v5 11/11] drm/rockchip: Use drm_atomic_helper_commit_tail_rpm Sean Paul
2019-06-13 19:05 ` [PATCH v5 00/11] drm: Add self refresh helpers Sean Paul
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=20190611185352.GA16305@ravnborg.org \
--to=sam@ravnborg.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=maxime.ripard@bootlin.com \
--cc=sean@poorly.run \
--cc=seanpaul@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox