Received: by 10.192.165.148 with SMTP id m20csp570561imm; Wed, 25 Apr 2018 04:27:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+25o2ird04QhxnsTjvagyFvgxIG5lIk0jLKYU52esKY8lZupmIksku8SrQ53PLs03rReM/ X-Received: by 10.98.10.131 with SMTP id 3mr27195608pfk.112.1524655646628; Wed, 25 Apr 2018 04:27:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524655646; cv=none; d=google.com; s=arc-20160816; b=p4e5x6Yo7RYrRrux9J3hrsyaTmiFFyfVy17L5XN5SqtmH3+Yh8Bnc4+ttvYPyP6wjv Cg14RIRIU47/XeHGV2hC8ztRLR9A90CoM62ERuopKqH45Bcp+yn+7xm9nX/0ez1sdmJk TcWpJut+GKntAQkgqufVz82vQWLEYHPdTUrynockQ6JU5AvOc2cJ3AmRwZFUEGySqVoR S0oOfzXwZRLYVH9/kYwGXbfRdv/Z+j6XhxIGEzUHxm9QcYoMPTSbCiPLE87PZ+meXP9X BLmLYx091MNRrInFf9CszG2ZfFL8PetzsvP/UrEwjS+HT8crC2T8nYhYxukr56TGB1r6 kZgw== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:to:from:date :arc-authentication-results; bh=qUaYJqY4bUdegzrH1D/Ky7VyV8Q/j9roTHyVTBw2vzI=; b=NX/07jPQxEoEf99ftwfExv0doOlRvT/tFknj018Tet84KImqh1XqZWBmCeOrlbQ15B 3N7g+YbOv2V76uw2yNtFl+vxKbgVl/yzOgDog1Jdf5cbSwWGjlS2rd4HwHCa8TMXcFpZ kNtc0+4lI0FqPObLhiRf6Y62NtDUFt6yz5WHxez8rlSxurag1xYsF4O9d60F6U++dgTI 41iB425j9NCB7TPQrz88vm/2+uJbHW8BGJmcwI2qjq+ohbTlSu3c7eatrzER5ftgfIZG eImMfsdBCNPZHNVy6gWyydbtLMZSy57oRUuWHQN+oWZPznA4VktpsnW7+X47zsQWCpyE gzCg== 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si16113214ply.517.2018.04.25.04.27.12; Wed, 25 Apr 2018 04:27:26 -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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753655AbeDYL0N (ORCPT + 99 others); Wed, 25 Apr 2018 07:26:13 -0400 Received: from foss.arm.com ([217.140.101.70]:38332 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752964AbeDYL0H (ORCPT ); Wed, 25 Apr 2018 07:26:07 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1DEB81435; Wed, 25 Apr 2018 04:26:07 -0700 (PDT) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B623A3F4FF; Wed, 25 Apr 2018 04:26:06 -0700 (PDT) Received: by e110455-lin.cambridge.arm.com (Postfix, from userid 1000) id 1B99668048D; Wed, 25 Apr 2018 12:26:05 +0100 (BST) Date: Wed, 25 Apr 2018 12:26:05 +0100 From: Liviu Dudau To: Ayan Kumar Halder , brian.starkey@arm.com, airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" Subject: Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions Message-ID: <20180425112604.GP14661@e110455-lin.cambridge.arm.com> References: <1524593567-5559-1-git-send-email-ayan.halder@arm.com> <1524593567-5559-6-git-send-email-ayan.halder@arm.com> <20180425071722.GN25142@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180425071722.GN25142@phenom.ffwll.local> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote: > On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote: > > malidp_pm_suspend_late checks if the runtime status is not suspended > > and if so, invokes malidp_runtime_pm_suspend which disables the > > display engine/core interrupts and the clocks. It sets the runtime status > > as suspended. > > > > The difference between suspend() and suspend_late() is as follows:- > > 1. suspend() makes the device quiescent. In our case, we invoke the DRM > > helper which disables the CRTC. This would have invoked runtime pm > > suspend but the system suspend process disables runtime pm. > > 2. suspend_late() It continues the suspend operations of the drm device > > which was started by suspend(). In our case, it performs the same functionality > > as runtime_suspend(). > > > > The complimentary functions are resume() and resume_early(). In the case of > > resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks > > and the interrupts. It sets the runtime status as active. If the device was > > in runtime suspend mode before system suspend was called, pm_runtime_work() > > will put the device back in runtime suspended mode( after the complete system > > has been resumed). > > > > Signed-off-by: Ayan Kumar Halder > > > > Afaiui we still haven't bottomed out on the discussion on v1. Did you get > hold of Rafael? No, there was no reply from him. Lets try again: Rafael, we are debating on what the proper approach is for handling the suspend/resume callbacks for a DRM driver that is likely to not be runtime suspended when the power-down happens (because we are driving the display output). We are using in this patch the LATE_SYSTEM_SLEEP_PM_OPS in order to do the work that we also do during runtime suspend, which is turning off the output and the clocks driving it. The reason for doing that is because the PM core takes a runtime reference during system suspend for all devices that are not already runtime suspended, so our runtime_pm_suspend() hook is never called. Daniel's argument is that we should not be doing this from LATE hooks, but from the normal suspend hooks, however kernel doc seems to suggest otherwise. Best regards, Liviu > -Daniel > > > --- > > Changes in v3:- > > - Rebased on top of earlier v3 patches, > > > > Changes in v2:- > > - Removed the change id and modified the commit message > > --- > > drivers/gpu/drm/arm/malidp_drv.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c > > index 82221ea..c53b46a 100644 > > --- a/drivers/gpu/drm/arm/malidp_drv.c > > +++ b/drivers/gpu/drm/arm/malidp_drv.c > > @@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct device *dev) > > return 0; > > } > > > > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev) > > +{ > > + if (!pm_runtime_status_suspended(dev)) { > > + malidp_runtime_pm_suspend(dev); > > + pm_runtime_set_suspended(dev); > > + } > > + return 0; > > +} > > + > > +static int __maybe_unused malidp_pm_resume_early(struct device *dev) > > +{ > > + malidp_runtime_pm_resume(dev); > > + pm_runtime_set_active(dev); > > + return 0; > > +} > > + > > static const struct dev_pm_ops malidp_pm_ops = { > > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \ > > + SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, malidp_pm_resume_early) \ > > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, NULL) > > }; > > > > -- > > 2.7.4 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯