Received: by 10.223.185.116 with SMTP id b49csp3302673wrg; Tue, 13 Feb 2018 00:19:15 -0800 (PST) X-Google-Smtp-Source: AH8x226TiXxexxKdKj8PbDNW2OlRlMZhGUlfl449hQoxlPXuNycfHphlGINqolmWe1uG7+s+Llrp X-Received: by 10.98.231.25 with SMTP id s25mr428185pfh.177.1518509955526; Tue, 13 Feb 2018 00:19:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518509955; cv=none; d=google.com; s=arc-20160816; b=n2/5Id+2RJEXrKx9gDS+CdSWR+uyWVGe6WKt2LPb06NMaKD1W11pLMdW/yAaSJv1ZS PMJqV8lpxSemx3cSarH0omethlFNow4/NpJeu/OabVKkj9lt0XiqfoB832YnN5dzNi2S VHZPMLGMXLsFqMGSuke2tKdN4mnuh6Ue77AmuDeh8niTbWkWB9CRBCZKobcTrMo1r4Ly DOO40REGLNXdu0LJhL8Uv87ycBJiYS15hlUPxtEqzClN2/FNQqUBeNrSo+2cXXgts9Uq 2wXZuvZNAyAkzWEOdzP+6ycATRaI1ceuKsSNS7V+bYBv5rlEvy+ghd/3OqoiU/3vdI+P N8eA== 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=ciEecaTRoqGNMIRANw5eK3Swt3Ll/dRF8+2QflE+VvE=; b=wasDyfnU/9UzDJbLcNjdkliuLQndAxRb2ioJ6greWSbm2do1zrthio33MfUbNTlw4l +7uSPoThOJI2Gx6qNay+L+VNrputqsBJJfwAZy+aw9380hVYRh5gX+O5K91AdYBuuuc/ siogGfPyShjF7v5gKb+WopZ+KWc5i7C7S0x2H6jD41qVypRo4hSNgAmNNSD1U1yqtEj7 +F6BBa9HfKpQHPMbb09YT3W2wHL/sYtN+a2zovn4ltBBOy9xstHb7ECLnXBqEYzV0W4K 0yhP+3mNNxR2uwamKty2GwXaqWCrdFw4ngQPM+kYkMzvBK1sqsbuUv/Cuc64fqkfbIqo d2Cw== 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 k91-v6si1632247pld.361.2018.02.13.00.19.00; Tue, 13 Feb 2018 00:19:15 -0800 (PST) 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 S933719AbeBMIRR (ORCPT + 99 others); Tue, 13 Feb 2018 03:17:17 -0500 Received: from bmailout1.hostsharing.net ([83.223.95.100]:59127 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933651AbeBMIRP (ORCPT ); Tue, 13 Feb 2018 03:17:15 -0500 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 24ECE300002A8; Tue, 13 Feb 2018 09:17:14 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 0069AFC91; Tue, 13 Feb 2018 09:17:13 +0100 (CET) Date: Tue, 13 Feb 2018 09:17:13 +0100 From: Lukas Wunner To: Alex Deucher Cc: Mike Lothian , Ismo Toijala , Hans de Goede , nouveau , Intel Graphics Development , Lai Jiangshan , Linux Kernel Mailing List , Maling list - DRI developers , Alex Deucher , Ben Skeggs , Tejun Heo , Dave Airlie , Liviu Dudau , Peter Wu Subject: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Message-ID: <20180213081713.GA8239@wunner.de> References: <20180211192314.GA22869@wunner.de> <20180211194154.GB22869@wunner.de> <20180212033947.GA19049@wunner.de> <20180212094500.22nvzzzpy6vrbqgc@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote: > On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner wrote: > > On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote: > >> On 12 February 2018 at 03:39, Lukas Wunner wrote: > >> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote: > >> > > I've not been able to reproduce the original problem you're trying to > >> > > solve on amdgpu thats with or without your patch set and the above > >> > > "trigger" too > > > > Okay the reason you're not seeing deadlocks is because the output poll > > worker is not enabled. And the output poll worker is not enabled > > because your discrete GPU doesn't have any outputs: > > > > [ 0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero! > > > > The outputs are only polled if there are connectors which have the > > DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set. > > And that only ever seems to be the case for VGA and DVI. > > > > We know based on bugzilla reports that hybrid graphics laptops do exist > > which poll outputs with radeon and nouveau. If there are no laptops > > supported by amdgpu whose discrete GPU has polled connectors, then > > patch [5/5] would be unnecessary. That is for Alex to decide. > > Most hybrid laptops don't have display connectors on the dGPU and we > only use polling on analog connectors, so you are not likely to run > into this on recent laptops. That said, I don't know if there is some > OEM system out there with a VGA port on the dGPU in a hybrid laptop. > I guess another option is to just disable polling on hybrid laptops. If we don't know for sure, applying patch [5/5] would seem to be the safest approach. (Assuming it doesn't break anything else.) Right now runtime PM is only used on hybrid graphics dGPUs by nouveau, radeon and amdgpu. Would it be conceivable that its use is expanded beyond that in the future? E.g. on a desktop machine, if DPMS is off on all screens, why keep the GPU in D0? If that is conceivable, chances that analog connectors are present are higher, and then the patch would be necessary again. (Of course this would mean that analog screens wouldn't light up automatically if they're attached while the GPU is in D3hot, but the user may forbid runtime PM via sysfs if that is unwanted.) Thanks, Lukas