From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760997AbdAEInt (ORCPT ); Thu, 5 Jan 2017 03:43:49 -0500 Received: from mail-wj0-f194.google.com ([209.85.210.194]:35275 "EHLO mail-wj0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760951AbdAEIn2 (ORCPT ); Thu, 5 Jan 2017 03:43:28 -0500 Date: Thu, 5 Jan 2017 09:43:24 +0100 From: Daniel Vetter To: Peter Ujfalusi Cc: daniel.vetter@intel.com, jani.nikula@linux.intel.com, seanpaul@chromium.org, airlied@linux.ie, gleb@fastmail.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, freedesktop-bugs@PaulSD.com Subject: Re: [PATCH] drm: Schedule the output_poll_work with 1s delay if we have delayed event Message-ID: <20170105084324.n33j6jrprnhbg736@phenom.ffwll.local> Mail-Followup-To: Peter Ujfalusi , daniel.vetter@intel.com, jani.nikula@linux.intel.com, seanpaul@chromium.org, airlied@linux.ie, gleb@fastmail.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, freedesktop-bugs@PaulSD.com References: <20170104120053.31882-1-peter.ujfalusi@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104120053.31882-1-peter.ujfalusi@ti.com> X-Operating-System: Linux phenom 4.8.0-1-amd64 User-Agent: NeoMutt/20161126 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 04, 2017 at 02:00:53PM +0200, Peter Ujfalusi wrote: > Instead of scheduling the work to handle the initial delayed event, use 1s > delay. > > When the delayed event is handled w/o delay - in a similar matter when the > poll had been initialized before drm_helper_probe_single_connector_modes() > is called - it triggers a race in Optimus setups. > > Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling") > Cc: stable@vger.kernel.org # v4.9 > Signed-off-by: Peter Ujfalusi > --- > Hi, > > related bug report: https://bugs.freedesktop.org/show_bug.cgi?id=98690 > > Regards, > Peter > > drivers/gpu/drm/drm_probe_helper.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c > index 98ed110e28ed..f30c14b0a72f 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -146,8 +146,9 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev) > drm_connector_list_iter_put(&conn_iter); > > if (dev->mode_config.delayed_event) { > + /* Use short (1s) delay to handle the initial delayed event */ > poll = true; > - delay = 0; > + delay = HZ; This smells a bit like duct-tape papering over some other race. Lack of locking or something else. Most likely some drivers enable polling a bit too early in their load sequence. And if we can't figure this out, then we need some really big FIXME: here that this papers over driver races. -Daniel > } > > if (poll) > -- > 2.11.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch