Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp14006imm; Thu, 2 Aug 2018 13:01:18 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeF2wrNGrrJ40SKRCmuRyUUS4BEmXfFJrjftS/S3oizM6xk7xQmVCwZ25RrhI72iNXljP5N X-Received: by 2002:a62:20d8:: with SMTP id m85-v6mr998367pfj.74.1533240077939; Thu, 02 Aug 2018 13:01:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533240077; cv=none; d=google.com; s=arc-20160816; b=TR/bWYqiCHSZmrTXFwhnrfGHm9TOtIK0akBd8hmKOqz/J/4TjqRHz4TUaRUE8oIkU2 t0Cgs1WK1W96kpPSohgZc8zgKoAC5prkhFP+V6R64XEIukPEV44a9TWSOKYgnj08xBBH CxHOYGJB43K/1jPSiZ/8ubqf4GdedXnkuT+WKDY1UwMJl8Txc56eoo9KPccLZ2AaM2IV Rw+nciBTFEGiGakl/jUekJonXe0Qbt04/0A/Okwm8j2QOgHEguhW3o79Bvaweufl8vIm nQySO4A7gFb5405LPUIbZL/WC2qkEorOLT3WrDJ+MV3z6LQmY4Rd5bnvr5UqT0kKBaGS BCmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=91l2h2t3/xKYaNP7soprXxqavel+FILehFZBfd4Z6ZI=; b=Fu8Ip34I5j+PjJsUJEBVl6PmUC5lJN+fP59/9llWGXf61tyxnkRn7OOh1xufEG35s1 wg0BYzK7LqwdDrCe3f70x5u4y+jVOWCFa7RQzhh2FhAHDRZjdN2MyL+fdW72Go68Hlam S6T8G11BdZwTMQ7wIOCCOAtUFEX4YnPjvdkysUJ/6aQ4BnO4kTZHrwmvcMSJtHeKlNoM cx3vg2AUdBhwDBf5AviPCrFf69MzkiVNBI/n2PoDW9JjBYQoaMoRlezD+f0/+afrdQAS EYJgjESUZr3LCNX3lBMqwqRtBt1NlZTO/01dOltV3l4HgjtYwbDkXkFoOKQaElEXjvYY cM/g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e20-v6si2781154pfm.177.2018.08.02.13.01.01; Thu, 02 Aug 2018 13:01:17 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729639AbeHBVws (ORCPT + 99 others); Thu, 2 Aug 2018 17:52:48 -0400 Received: from mail-qk0-f196.google.com ([209.85.220.196]:33900 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726828AbeHBVws (ORCPT ); Thu, 2 Aug 2018 17:52:48 -0400 Received: by mail-qk0-f196.google.com with SMTP id b66-v6so2494767qkj.1 for ; Thu, 02 Aug 2018 13:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=91l2h2t3/xKYaNP7soprXxqavel+FILehFZBfd4Z6ZI=; b=lRLmMKYWMWN+NGbd7l03evaepQz1wISV5/vrGwVOYKA1lq6GDAWnh2K+FO6Td70DNb lRAcfD0gbZVHKbkbRwLA2/SEqSWI5Sx3L8Qz6WRXcN+GjD2zE4Egsl2dmEWHdte9Rv+y qJt6opnwTCiGvL4pPB10CpDpwxTe/+VeYr9jK6gj1vjp/svugDgsVxqCAxohrH640VET Tn/VRH/jDfKMR6Ytq12IZRA3eswTFr2e9k0Wr+XFr812oo2EaCnnTdFW5I5wtmU9z6NF ErvI7/Hdr6T3IBeoDgaOlS7nGea2qB0HclUVIyKTOA1uM3Y4PJGl3PId8ZX+sU7URKlO 7Plw== X-Gm-Message-State: AOUpUlGcXLzm4Od5dKrd45s0jeCY8ovchsKMC7+ROGP8epCWaJFySz9y A05dCghgvA5fi6kfRPCshS1FQoXnBt0= X-Received: by 2002:a37:8643:: with SMTP id i64-v6mr978149qkd.194.1533240009490; Thu, 02 Aug 2018 13:00:09 -0700 (PDT) Received: from dhcp-10-20-1-11.bss.redhat.com ([144.121.20.162]) by smtp.gmail.com with ESMTPSA id v192-v6sm2824675qkb.0.2018.08.02.13.00.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 Aug 2018 13:00:08 -0700 (PDT) Message-ID: Subject: Re: [PATCH v4 8/8] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers From: Lyude Paul To: Lukas Wunner Cc: nouveau@lists.freedesktop.org, Karol Herbst , Ben Skeggs , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Thu, 02 Aug 2018 16:00:08 -0400 In-Reply-To: <20180802194041.GC6180@wunner.de> References: <20180801211459.7731-1-lyude@redhat.com> <20180801211459.7731-9-lyude@redhat.com> <20180802194041.GC6180@wunner.de> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-08-02 at 21:40 +0200, Lukas Wunner wrote: > On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote: > > We can't and don't need to try resuming the device from our hotplug > > handlers, but hotplug events are generally something we'd like to keep > > the device awake for whenever possible. So, grab a PM ref safely in our > > hotplug handlers using pm_runtime_get_noresume() and mark the device as > > busy once we're finished. > > Patch looks fine in principle, but doesn't seem to be sufficient to fix > the following race: > > 1. runtime_suspend commences > 2. user plugs in a display before the runtime_suspend worker disables > hotplug interrupts in nouveau_display_fini() > 3. hotplug is handled, display is lit up > 4. runtime_suspend worker waits for hotplug handler to finish > 5. GPU is runtime suspended and the newly plugged in display goes black > > The call to pm_runtime_mark_last_busy() has no effect in this situation > because rpm_suspend() doesn't look at the last_busy variable after the > call to rpm_callback(). What's necessary here is that runtime_suspend is > aborted and -EBUSY returned. So: that wasn't actually what this patch was meant to fix, this is just meant to make it a little more likely that the GPU won't fall asleep while doing connector probing, since there's no risk handling it here. That being said; I think there's some parts you're missing on this. Mainly that regardless of whether or not the GPU ends up getting runtime suspended here, a hotplug event has still been propogated to userspace. If fbcon isn't the one in charge in that scenario (e.g. we have gnome-shell, X, etc. running) then whoever is can still respond to the hotplug as usual, and the probing from userspace will result in waking the GPU back up again since nouveau_connector_detect() will grab a runtime PM ref since it's not being called from the hpd context. I don't think this is the case yet for MST connectors since they don't use nouveau_connector_detect(), and I'll see if I fix that as well in the next patch series. Now; what you pointed out made me realize I'm not sure that would apply when fbcon does happen to be the one in control, since fb_helper will have it's hotplug handling suspended at this point, which will mean that it won't respond to the connector change until the GPU is runtime resumed by something else. That definitely should get fixed. Also: let me know if any of this doesn't sound correct, there's so much to this I wouldn't be surprised if I missed something else > > Thanks, > > Lukas > > > > > Signed-off-by: Lyude Paul > > Cc: stable@vger.kernel.org > > Cc: Lukas Wunner > > Cc: Karol Herbst > > --- > > drivers/gpu/drm/nouveau/nouveau_connector.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > > b/drivers/gpu/drm/nouveau/nouveau_connector.c > > index 8409c3f2c3a1..5a8e8c1ad647 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c > > @@ -1152,6 +1152,11 @@ nouveau_connector_hotplug(struct nvif_notify > > *notify) > > const char *name = connector->name; > > struct nouveau_encoder *nv_encoder; > > > > + /* Resuming the device here isn't possible; but the suspend PM ops > > + * will wait for us to finish our work before disabling us so this > > + * should be enough > > + */ > > + pm_runtime_get_noresume(drm->dev->dev); > > nv_connector->hpd_task = current; > > > > if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) { > > @@ -1171,6 +1176,9 @@ nouveau_connector_hotplug(struct nvif_notify > > *notify) > > } > > > > nv_connector->hpd_task = NULL; > > + > > + pm_runtime_mark_last_busy(drm->dev->dev); > > + pm_runtime_put_autosuspend(drm->dev->dev); > > return NVIF_NOTIFY_KEEP; > > } > > > > -- > > 2.17.1 > > -- Cheers, Lyude Paul