From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757426AbcH2M7D (ORCPT ); Mon, 29 Aug 2016 08:59:03 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34601 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757045AbcH2M7B (ORCPT ); Mon, 29 Aug 2016 08:59:01 -0400 Date: Mon, 29 Aug 2016 14:58:57 +0200 From: Daniel Vetter To: Peter Ujfalusi Cc: airlied@linux.ie, daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ville.syrjala@linux.intel.com, tomi.valkeinen@ti.com Subject: Re: [PATCH] drm: drm_probe_helper: Fix output_poll_work scheduling Message-ID: <20160829125857.GK10980@phenom.ffwll.local> Mail-Followup-To: Peter Ujfalusi , airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ville.syrjala@linux.intel.com, tomi.valkeinen@ti.com References: <20160829095022.12160-1-peter.ujfalusi@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160829095022.12160-1-peter.ujfalusi@ti.com> X-Operating-System: Linux phenom 4.6.0-1-amd64 User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote: > drm_kms_helper_poll_enable_locked() should check if we have delayed event > pending and if we have, schedule the work to run without delay. > > Currently the output_poll_work is only scheduled if any of the connectors > have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with > DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event > already registered to be handled. The detection will be delayd by > DRM_OUTPUT_POLL_PERIOD in any case. > Furthermore if none of the connectors are marked as POLL_CONNECT or > POLL_DISCONNECT because all connectors are either POLL_HPD or they are > always connected: the output_poll_work will not run at all even if we > have delayed event marked. > > When none of the connectors require polling, their initial status change > from unknown to connected/disconnected is not going to be handled until > the first kms application starts or if we have fb console enabled. > > With this change we can react more quickly to output status changes after > enabling the poll but most importantly it will correct the behavior when > none of the connector have POLL_CONNECT or POLL_DISCONNECT flag set - they > are either POLL_HPD or the .polled is 0. The initial status change is going > to be handled correctly as well. Don't we need to set delayed_event somewhere too first? At least I don't really understand how this speeds things up ... The patch itself looks like a valid bugfix, but the description confuses me a bit. I think if you delete the above paragraph (starting with "With this change we can react ...") then it's all good. -Daniel > > Signed-off-by: Peter Ujfalusi > --- > drivers/gpu/drm/drm_probe_helper.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c > index a0df377d7d1c..f6b64d7d3528 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev) > { > bool poll = false; > struct drm_connector *connector; > + unsigned long delay = DRM_OUTPUT_POLL_PERIOD; > > WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); > > @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev) > poll = true; > } > > + if (dev->mode_config.delayed_event) { > + poll = true; > + delay = 0; > + } > + > if (poll) > - schedule_delayed_work(&dev->mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD); > + schedule_delayed_work(&dev->mode_config.output_poll_work, delay); > } > EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked); > > -- > 2.9.3 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch