Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933058AbdGTBEc (ORCPT ); Wed, 19 Jul 2017 21:04:32 -0400 Received: from mga05.intel.com ([192.55.52.43]:32232 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932107AbdGTBEb (ORCPT ); Wed, 19 Jul 2017 21:04:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,382,1496127600"; d="scan'208";a="1174568110" From: "Pandiyan, Dhinakaran" To: "paul.kocialkowski@linux.intel.com" CC: "dri-devel@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "Vetter, Daniel" , "airlied@linux.ie" Subject: Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq Thread-Topic: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq Thread-Index: AQHTAPQZaVFswTOl4E67LA2mCNCe1A== Date: Thu, 20 Jul 2017 01:04:12 +0000 Message-ID: <1500513858.21694.13.camel@dk-H97M-D3H> References: <20170626123229.27939-1-paul.kocialkowski@linux.intel.com> In-Reply-To: <20170626123229.27939-1-paul.kocialkowski@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.54.75.5] Content-Type: text/plain; charset="utf-8" Content-ID: <731C03F53BA3A5479753D38928CE3BA9@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v6K14cTx010625 Content-Length: 2563 Lines: 66 On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote: > After detecting an IRQ storm, hotplug detection will switch from > irq-based detection to poll-based detection. After a short delay or > when resetting storm detection from debugfs, detection will switch > back to being irq-based. > > However, it may occur that polling does not have enough time to detect > the current connector state when that second switch takes place. Some questions so that I understand this better. How short would this have to be for detect to not complete? Is there a way I can easily test this scenario? > Thus, > this sets the appropriate hotplug event bits for the concerned > connectors and schedules the hotplug work, that will ensure the > connectors states are in sync when switching back to irq. > Not sure I understand this correctly, looks like you are setting the event_bits even if there was no irq during the polling interval. Is that right? > Without this, no irq will be triggered and the hpd change will be lost. > > Signed-off-by: Paul Kocialkowski > --- > drivers/gpu/drm/i915/intel_hotplug.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c > index f1200272a699..29f55480b0bb 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -218,9 +218,13 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) > struct intel_connector *intel_connector = to_intel_connector(connector); > > if (intel_connector->encoder->hpd_pin == i) { > - if (connector->polled != intel_connector->polled) > + if (connector->polled != intel_connector->polled) { > DRM_DEBUG_DRIVER("Reenabling HPD on connector %s\n", > connector->name); > + > + dev_priv->hotplug.event_bits |= (1 << i); > + } > + > connector->polled = intel_connector->polled; > if (!connector->polled) > connector->polled = DRM_CONNECTOR_POLL_HPD; > @@ -232,6 +236,8 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) > dev_priv->display.hpd_irq_setup(dev_priv); > spin_unlock_irq(&dev_priv->irq_lock); > > + schedule_work(&dev_priv->hotplug.hotplug_work); How does this work with DP connectors? From what I understand, the event_bits are set for DP based on the return value from intel_dp_hpd_pulse(). But, doesn't this patch set the bits unconditionally? > + > intel_runtime_pm_put(dev_priv); > } >