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 11:25:41 -0800 [thread overview]
Message-ID: <Y7h1tVRI8qsBK9D8@google.com> (raw)
In-Reply-To: <Y7hmeBBRqgnwQ2O6@phenom.ffwll.local>
On Fri, Jan 06, 2023 at 07:20:40PM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 10:08:53AM -0800, Brian Norris wrote:
> > 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.)
>
> Yeah once I stopped looking at this the wrong way round it does make sense
> what you're doing. See my other reply, I think with just this series here
> the vblanks still stall out? Or does your hw actually keep generating
> vblank irq with the display off?
I might not be understanding all of the IGT tests that I've run through,
but the display is not actually off -- it's sitting on a still frame.
But yes, IRQs still come, and I see no hangs.
This is also ref'd in patch 2:
bed030a49f3e drm/rockchip: Don't fully disable vop on self refresh
So, we're not even doing that much to power-down the CRTC/VOP. That's
probably why IRQs are still active, contrary to your expectation?
NB: this is how Rockchip Chromebooks implemented PSR from essentially
day 1.
> > On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> > > 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.
>
> Ah yeah that makes sense. Would be good to cite that in this patch too,
> because I guess the same kms_vblank tests can also hit this warning here?
Well, before this series: no, those tests don't hit this warning. The
warning is only uncovered after patch 2. If I do just patch 2, it's
super-trivial to hit the warning. You just have to turn the display on
and go idle long enough for PSR to activate once. I suppose that can
count as "caught by a test", with a little stretch of the imagination.
At any rate, I'll improve this description to refer precisely to the
"next patch" (as Greg suggested already), and that might involve
describing this test case a little.
Brian
next prev parent reply other threads:[~2023-01-06 19:26 UTC|newest]
Thread overview: 16+ 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 ` [PATCH 2/2] drm/rockchip: vop: Leave vblank enabled in self-refresh Brian Norris
2023-01-06 11:42 ` Michel Dänzer
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 17:49 ` Daniel Vetter
2023-01-06 17:53 ` Daniel Vetter
2023-01-06 18:08 ` Brian Norris
2023-01-06 18:20 ` Daniel Vetter
2023-01-06 19:25 ` Brian Norris [this message]
2023-01-06 18:17 ` Daniel Vetter
2023-01-06 19:33 ` Brian Norris
2023-01-06 20:30 ` Daniel Vetter
2023-01-06 21:30 ` Brian Norris
2023-01-06 22:44 ` Daniel Vetter
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=Y7h1tVRI8qsBK9D8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox