Received: by 10.223.185.116 with SMTP id b49csp3528686wrg; Tue, 13 Feb 2018 03:53:21 -0800 (PST) X-Google-Smtp-Source: AH8x224JjfHWJx2Pz5G9ZH0Ez8BR3yi/enRZD2gjkAgLHJU7REXCcmWZtUJL+g1x61M16wjvsNwI X-Received: by 2002:a17:902:34a:: with SMTP id 68-v6mr921561pld.276.1518522801116; Tue, 13 Feb 2018 03:53:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518522801; cv=none; d=google.com; s=arc-20160816; b=Sk3DCMRh4q+PA74GmtAuVwsj2JmZ/rFguh2ApcWEO/C67QM63Q/BZ1xGQby/XQ4boW Qilo9QoKeh1s0O6NFQP/84qKZCfi4JrIhXwY24lrgc6wvKO7u4vaYSBPz5WPHjrMkwn4 Fu5CuFKmfcc7iyO6OizDqUGZ8+zFeXb8EmWlcQEBCc00C3C/xKsxnnKgp9OQLaimkSIN rN6+0iJhFvNvZQwnhrTgOUMNJxN8nR81pQIZE2D34aaDcbsPJ7ZIVY3Zatf6SSdh+EkF NP4EERwrvTPEjtLkNL372f+WkZNMLeUqEpfU7qZFb1Ad8lUTezhateDGEdUoO/aogruL yJLA== 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=T59SLwI4s/rwD3LmeVLqYkaSolVax0T1GC6u50AaPFE=; b=BrBZac3ltqgwHI4UDZH3+Nf7sTfyQKaQ8MZFwRN0DHtT/d63aV7yw6VnZ5sshpS7Qs 9tAcOutC4Pg9OfBr1E7fb32Ua4vf4ew7PEnMdjO3bZIqvoKpGbLF3wNymdeRrPtihvt8 ucFHgQTLYj5QyY/flS043EogAf3xhGihTvBtuzIsm6J4bWv73JHolm6jMYOn3Sv+3opZ YMtxvg2N9D1bN/UJGPO0VEfRGXbaxMspc+gGPk81QipoN4CZ+B/Z8w2Y3kn6K4xGCtD0 2YxsTtrGviU0QTyAh/sDaDVifSr5mRuEueWjqmIgd+e87yILLc9ALh8GcMxsv8YhNvGv 77Kg== 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 y5si6344308pfg.267.2018.02.13.03.53.06; Tue, 13 Feb 2018 03:53:21 -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 S934966AbeBMLwJ (ORCPT + 99 others); Tue, 13 Feb 2018 06:52:09 -0500 Received: from bmailout2.hostsharing.net ([83.223.90.240]:34159 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934456AbeBMLwH (ORCPT ); Tue, 13 Feb 2018 06:52:07 -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 bmailout2.hostsharing.net (Postfix) with ESMTPS id 6BCC42800B3E2; Tue, 13 Feb 2018 12:52:06 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 280ED10680; Tue, 13 Feb 2018 12:52:06 +0100 (CET) Date: Tue, 13 Feb 2018 12:52:06 +0100 From: Lukas Wunner To: Liviu Dudau Cc: Tejun Heo , Lai Jiangshan , Alex Deucher , Dave Airlie , Ben Skeggs , dri-devel@lists.freedesktop.org, Peter Wu , nouveau@lists.freedesktop.org, Lyude Paul , Hans de Goede , Pierre Moreau , linux-kernel@vger.kernel.org, Ismo Toijala , intel-gfx@lists.freedesktop.org, Archit Taneja Subject: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Message-ID: <20180213115206.GA16075@wunner.de> References: <20180213105506.GF9111@e110455-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180213105506.GF9111@e110455-lin.cambridge.arm.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 Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote: > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: > > DRM drivers poll connectors in 10 sec intervals. The poll worker is > > stopped on ->runtime_suspend with cancel_delayed_work_sync(). However > > the poll worker invokes the DRM drivers' ->detect callbacks, which call > > pm_runtime_get_sync(). If the poll worker starts after runtime suspend > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish > > with the intention of runtime resuming the device afterwards. The result > > is a circular wait between poll worker and autosuspend worker. > > I think I understand the problem you are trying to solve, but I'm > struggling to understand where malidp makes any specific mistakes. First > of all, malidp is only a display engine, so there is no GPU attached to > it, but that is only a small clarification. Second, malidp doesn't use > directly any of the callbacks that you are referring to, it uses the > drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any > issues there (as they might well be) I think they would apply to a lot > more drivers and the fix will involve more than just malidp, i915 and > msm. I don't know if malidp makes any specific mistakes and didn't mean to cast it in a negative light, sorry. So a lot of DRM drivers acquire a runtime PM ref in the connector ->detect hook because they can't probe connectors while runtime suspended. E.g. for a PCI device, probing might require mmio access, which isn't possible outside of power state D0. There are no ->detect hooks declared in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe during runtime suspend. hdlcd_drv.c and malidp_drv.c both enable output polling. Output polling is only necessary if you don't get HPD interrupts. You're not disabling polling upon runtime suspend. Thus, if a runtime PM ref is acquired during polling (such as in a ->detect hook), the GPU will be runtime resumed every 10 secs. You may want to verify that's not the case. If you decide that you do want to stop polling during runtime suspend because it runtime resumes the GPU continuously, you'll need the helper introduced in this series. So by cc'ing you I just wanted to keep you in the loop about an issue that may potentially affect your driver. Let me know if there are any questions. Thanks, Lukas