Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3981675imm; Mon, 6 Aug 2018 14:19:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpePVgF06qmYGN4CQmhFz8ZXGyUV0p+IQN9X5rSksskLuas3uUoASEgF1J3umsUQgpI9BCZf X-Received: by 2002:a62:1f06:: with SMTP id f6-v6mr19016834pff.140.1533590382929; Mon, 06 Aug 2018 14:19:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533590382; cv=none; d=google.com; s=arc-20160816; b=hX6A84Javf+F2UDCXtUsEfLmgolvYnVsWT0WLvHC8S4aLIvvAMudDgaWHauKWhKcEL EZOeg8YhoA5uaY3e4/ABnh89q4L3p8g2JPo5Kxw+z8OFngTEuBa48f9Whwrh8k76UPbk IZaxgJQf4r5eYzvoaWVMNBS6e02AKZueekEI1/6qSIjwIKkl2rBqjIH/KiiCO87bE6ft ssmDXPxGCrHN9LCVS/8eVT8qqRh7hIjz+H8YmL2CDKKIFlIfisD3IaoU8DwU5jIj6a9/ kCe4PqCtoZj1G+OttfcGiDX8rzYZmlCIl2YALLaGLaJQPawSXREjDze6nxRUsOYh8BfX rTNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=XlD+Mil/zAmD2rcO+ykMLmyja1yEHkjMjp9FdsfqVuo=; b=ruRDLSdy5uZpgBqZlUze1X1CIwt6HSnjlq4buADORrgKmZJfw4jrRWsvtV+gNY8HZL fN/UVjNiPC/xNFC9jDveYUoA+2ignSX8KxjuzQk+OhzgwXB+nZvCjODtBJUeQ8dau+AR bGbGiG3sXFs9BWziYbzhVfI88LNd/CoU8ur7O+QZwRSGZ7k6NTS9N9bLiMmunJKtxBEi 5LjLAME5g8zlby/7m31VoVbNN/IgDHWGYkuY+qjlNGt0aWzE6d0Gv7Bk9hXltWi/bcxB KZ3jD0IZNbUcgHE9yx+eYVrdZOQS2GylGqPggn0TsxwkJnPpyAADcNhO4ExxzHm+l8jq HnmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d11-v6si10875104pla.442.2018.08.06.14.19.27; Mon, 06 Aug 2018 14:19:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732201AbeHFVpe (ORCPT + 99 others); Mon, 6 Aug 2018 17:45:34 -0400 Received: from bmailout1.hostsharing.net ([83.223.95.100]:39409 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727585AbeHFVpe (ORCPT ); Mon, 6 Aug 2018 17:45:34 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 3C74D3004D18E; Mon, 6 Aug 2018 21:34:58 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 01E102FE97; Mon, 6 Aug 2018 21:34:57 +0200 (CEST) Date: Mon, 6 Aug 2018 21:34:57 +0200 From: Lukas Wunner To: Lyude Paul Cc: Daniel Vetter , David Airlie , nouveau@lists.freedesktop.org, Karol Herbst , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v3 3/8] drm/fb_helper: Introduce hotplug_suspend/resume() Message-ID: <20180806193457.GA7028@wunner.de> References: <20180731003954.19962-1-lyude@redhat.com> <20180731003954.19962-4-lyude@redhat.com> <20180806084322.GK3008@phenom.ffwll.local> <4e72a10062166d646ebd3eb28b6c186d4c00a63f.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e72a10062166d646ebd3eb28b6c186d4c00a63f.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote: > You did mention in the review of one of my other patches that we should avoid > disabling polling during runtime suspend, and you're definitely right. I feel > a bit silly for not remembering that since I was the one who made it so that > i915 does polling in runtime suspend for chips without RPM HPD detection in > the first place because it was causing people's displays not to come up on > vlv... > Anyway: I think if we just leave output polling enabled during runtime suspend > that might actually fix all of the fb_helper locking issues since we won't > need to wait on any of the output poll workers to finish, at least I think it > should: I'll confirm this when I get into the office Quoth Imre Deak: "In i915 polling is on during runtime suspend only if there are outputs without hotplug interrupt support. A special case is when an output has working HPD interrupts when in D0, but no interrupts when runtime suspended. For these we start polling (from a scheduled work) in the runtime suspend hook and stop it in the runtime resume hook (again from a scheduled work)." https://lkml.org/lkml/2018/2/12/330 nouveau only uses runtime PM on discrete GPUs in dual GPU laptops. Resuming the GPU from D3cold to D0 every few seconds to poll the outputs would waste too much power on such machines. The question is, why is polling running at all, since all modern laptops have HPD-capable ports such as DP? Thanks, Lukas