From: Brian Norris <briannorris@chromium.org>
To: "Heiko Stübner" <heiko@sntech.de>,
"Sean Paul" <seanpaul@chromium.org>,
"Michel Dänzer" <michel.daenzer@mailbox.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Sandy Huang" <hjc@rock-chips.com>,
linux-rockchip@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable"
Date: Fri, 6 Jan 2023 10:08:53 -0800 [thread overview]
Message-ID: <Y7hjte/w8yP2TPlB@google.com> (raw)
In-Reply-To: <Y7hgLUXOrD7QwKs1@phenom.ffwll.local>
Hi Daniel,
On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mode activates automatically
> > (e.g., after some period of unchanging display output). In such cases,
> > the display pipe is still considered "on", and user-space is not aware
> > that we went into self-refresh mode. Thus, users may expect that
> > vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
> > properly.
> >
> > However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
> > vblank enabled here.
> >
> > Add a new exception, such that we allow CRTCs to be "disabled" (with
> > self-refresh active) with vblank interrupts still enabled.
> >
> > Cc: <stable@vger.kernel.org> # dependency for subsequent patch
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> >
> > drivers/gpu/drm/drm_atomic_helper.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index d579fd8f7cb8..7b5eddadebd5 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1207,6 +1207,12 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
> >
> > if (!drm_dev_has_vblank(dev))
> > continue;
> > + /*
> > + * Self-refresh is not a true "disable"; let vblank remain
> > + * enabled.
> > + */
> > + if (new_crtc_state->self_refresh_active)
> > + continue;
>
> This very fishy, because we check in crtc_needs_disable whether this
> output should stay on due to self-refresh. Which means you should never
> end up in here.
That's not what crtc_needs_disable() does w.r.t. self-refresh. In fact,
it's the opposite; see, for example, the
|new_state->self_refresh_active| clause. That clause means that if we're
entering self-refresh, we *intend* to disable (i.e., we return 'true').
That's because like I mention above, the self-refresh helpers overload
what "disable" means.
I'll also add my caveat again that I'm a bit new to DRM, so feel free to
continue to correct me if I'm wrong :) Or perhaps Sean Paul could
provide second opinions, as I believe he wrote this stuff.
> And yes vblank better work in self refresh :-) If it doesn't, then you
> need to fake it with a timer, that's at least what i915 has done for
> transparent self-refresh.
OK! Then that sounds like it at least ACKs my general idea for this
series. (Michel and I poked at a few ideas in the thread at [1] and
landed on approx. this solution, or else a fake/timer like you suggest.)
> We might need a few more helpers. Also, probably more igt, or is this
> something igt testing has uncovered? If so, please cite the igt testcase
> which hits this.
The current patch only fixes a warning that comes when I try to do the
second patch. The second patch is a direct product of an IGT test
failure (a few of kms_vblank's subtests), and I linked [1] the KernelCI
report there.
Brian
[1] Link: https://lore.kernel.org/dri-devel/Y5itf0+yNIQa6fU4@sirena.org.uk/
Reported-by: "kernelci.org bot" <bot@kernelci.org>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: "Heiko Stübner" <heiko@sntech.de>,
"Sean Paul" <seanpaul@chromium.org>,
"Michel Dänzer" <michel.daenzer@mailbox.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Sandy Huang" <hjc@rock-chips.com>,
linux-rockchip@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable"
Date: Fri, 6 Jan 2023 10:08:53 -0800 [thread overview]
Message-ID: <Y7hjte/w8yP2TPlB@google.com> (raw)
In-Reply-To: <Y7hgLUXOrD7QwKs1@phenom.ffwll.local>
Hi Daniel,
On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mode activates automatically
> > (e.g., after some period of unchanging display output). In such cases,
> > the display pipe is still considered "on", and user-space is not aware
> > that we went into self-refresh mode. Thus, users may expect that
> > vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work
> > properly.
> >
> > However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave
> > vblank enabled here.
> >
> > Add a new exception, such that we allow CRTCs to be "disabled" (with
> > self-refresh active) with vblank interrupts still enabled.
> >
> > Cc: <stable@vger.kernel.org> # dependency for subsequent patch
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> >
> > drivers/gpu/drm/drm_atomic_helper.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index d579fd8f7cb8..7b5eddadebd5 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1207,6 +1207,12 @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
> >
> > if (!drm_dev_has_vblank(dev))
> > continue;
> > + /*
> > + * Self-refresh is not a true "disable"; let vblank remain
> > + * enabled.
> > + */
> > + if (new_crtc_state->self_refresh_active)
> > + continue;
>
> This very fishy, because we check in crtc_needs_disable whether this
> output should stay on due to self-refresh. Which means you should never
> end up in here.
That's not what crtc_needs_disable() does w.r.t. self-refresh. In fact,
it's the opposite; see, for example, the
|new_state->self_refresh_active| clause. That clause means that if we're
entering self-refresh, we *intend* to disable (i.e., we return 'true').
That's because like I mention above, the self-refresh helpers overload
what "disable" means.
I'll also add my caveat again that I'm a bit new to DRM, so feel free to
continue to correct me if I'm wrong :) Or perhaps Sean Paul could
provide second opinions, as I believe he wrote this stuff.
> And yes vblank better work in self refresh :-) If it doesn't, then you
> need to fake it with a timer, that's at least what i915 has done for
> transparent self-refresh.
OK! Then that sounds like it at least ACKs my general idea for this
series. (Michel and I poked at a few ideas in the thread at [1] and
landed on approx. this solution, or else a fake/timer like you suggest.)
> We might need a few more helpers. Also, probably more igt, or is this
> something igt testing has uncovered? If so, please cite the igt testcase
> which hits this.
The current patch only fixes a warning that comes when I try to do the
second patch. The second patch is a direct product of an IGT test
failure (a few of kms_vblank's subtests), and I linked [1] the KernelCI
report there.
Brian
[1] Link: https://lore.kernel.org/dri-devel/Y5itf0+yNIQa6fU4@sirena.org.uk/
Reported-by: "kernelci.org bot" <bot@kernelci.org>
next prev parent reply other threads:[~2023-01-06 18:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-06 1:40 [PATCH 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable" Brian Norris
2023-01-06 1:40 ` Brian Norris
2023-01-06 1:40 ` Brian Norris
2023-01-06 1:40 ` [PATCH 2/2] drm/rockchip: vop: Leave vblank enabled in self-refresh Brian Norris
2023-01-06 1:40 ` Brian Norris
2023-01-06 1:40 ` Brian Norris
2023-01-06 11:42 ` Michel Dänzer
2023-01-06 11:42 ` Michel Dänzer
2023-01-07 1:21 ` Brian Norris
2023-01-07 1:21 ` Brian Norris
2023-01-07 1:21 ` Brian Norris
2023-01-06 7:04 ` [PATCH 1/2] drm/atomic: Allow vblank-enabled + self-refresh "disable" Greg KH
2023-01-06 7:04 ` Greg KH
2023-01-06 7:04 ` Greg KH
2023-01-06 17:49 ` Daniel Vetter
2023-01-06 17:49 ` Daniel Vetter
2023-01-06 17:49 ` Daniel Vetter
2023-01-06 17:53 ` Daniel Vetter
2023-01-06 17:53 ` Daniel Vetter
2023-01-06 17:53 ` Daniel Vetter
2023-01-06 18:08 ` Brian Norris [this message]
2023-01-06 18:08 ` Brian Norris
2023-01-06 18:20 ` Daniel Vetter
2023-01-06 18:20 ` Daniel Vetter
2023-01-06 18:20 ` Daniel Vetter
2023-01-06 19:25 ` Brian Norris
2023-01-06 19:25 ` Brian Norris
2023-01-06 18:17 ` Daniel Vetter
2023-01-06 18:17 ` Daniel Vetter
2023-01-06 19:33 ` Brian Norris
2023-01-06 19:33 ` Brian Norris
2023-01-06 20:30 ` Daniel Vetter
2023-01-06 20:30 ` Daniel Vetter
2023-01-06 20:30 ` Daniel Vetter
2023-01-06 21:30 ` Brian Norris
2023-01-06 21:30 ` Brian Norris
2023-01-06 22:44 ` Daniel Vetter
2023-01-06 22:44 ` Daniel Vetter
2023-01-06 22:44 ` Daniel Vetter
2023-01-11 15:03 ` Ville Syrjälä
2023-01-11 15:03 ` Ville Syrjälä
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=Y7hjte/w8yP2TPlB@google.com \
--to=briannorris@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=michel.daenzer@mailbox.org \
--cc=seanpaul@chromium.org \
--cc=stable@vger.kernel.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.