All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Guo <shawn.guo@linaro.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing
Date: Fri, 16 Oct 2020 16:54:08 +0800	[thread overview]
Message-ID: <20201016085407.GA5182@dragon> (raw)
In-Reply-To: <CAKMK7uHvDK6Cd2BBvUV-xtArD73gQVAp0ETBw=tLXrYUfOS-zw@mail.gmail.com>

On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo <shawn.guo@linaro.org> wrote:
> >
> > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > WARN_ON_ONCE() for atomic drivers to warn the case that vsync is enabled
> > before a mode has been set on CRTC.  This happens sometimes during the
> > initial mode setting of a CRTC.  It also happens on Android running HWC2
> > backed with drm_hwcomposer, where HWC2::SetVsyncEnabled could be called
> > before the atomic mode setting on CRTC happens.
> >
> > In this case, there is nothing really bad to happen as kernel function
> > returns as no-op.  So using WARN() version might be overkilled,
> > considering some user space crash reporting services may treat kernel
> > WARNINGS as crashes.  Let's drop WARN_ON_ONCE() and change drm_dbg_core()
> > to drm_warn_once() for warning undefined mode timing.
> 
> This indicates a bug in your driver. Please fix it there, not by
> shutting up the core code complaining about that. Either you're
> getting vblank timestamps when the vblank isn't set up yet
> (drm_crtc_vblank_on/off) or there's some other race going on in your
> driver code resulting in this.

Thanks for the comment, Daniel.

I'm hitting this warning on an Android running drm_hwcomposer.  I'm
indeed getting vblank timestamps request before drm_crtc_vblank_on() is
called.  I'm not sure this is a bug or race condition in the driver
code, as both vblank timestamps and on/off requests are coming from user
space ioctl for my case.  @Sean, that means the problem is in Android
drm_hwcomposer code?

Shawn
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-16  8:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16  7:12 [PATCH] drm/drm_vblank: use drm_warn_once() to warn undefined mode timing Shawn Guo
2020-10-16  7:58 ` Daniel Vetter
2020-10-16  8:54   ` Shawn Guo [this message]
2020-10-16  9:30     ` Daniel Vetter
2020-10-16 11:46       ` Shawn Guo
2020-10-19 15:48         ` Daniel Vetter
2020-10-21  9:11           ` Shawn Guo

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=20201016085407.GA5182@dragon \
    --to=shawn.guo@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=seanpaul@chromium.org \
    --cc=tzimmermann@suse.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.