From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753911AbcKJAge (ORCPT ); Wed, 9 Nov 2016 19:36:34 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:32768 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbcKJAgb (ORCPT ); Wed, 9 Nov 2016 19:36:31 -0500 MIME-Version: 1.0 In-Reply-To: <9cf5829a-baac-9297-b231-17212d0195b1@samsung.com> References: <1475136751-31340-1-git-send-email-m.szyprowski@samsung.com> <1475136751-31340-3-git-send-email-m.szyprowski@samsung.com> <20161006173756.GK3296@wotan.suse.de> <87aeb58b-bda0-93c5-e51d-ab9be0b9d518@samsung.com> <20161108221437.GC13978@wotan.suse.de> <9cf5829a-baac-9297-b231-17212d0195b1@samsung.com> From: "Rafael J. Wysocki" Date: Thu, 10 Nov 2016 01:36:29 +0100 X-Google-Sender-Auth: djrGenHkoDVW6-H47_RisvO9vzM Message-ID: Subject: Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support To: Marek Szyprowski , "Luis R. Rodriguez" Cc: Linux PM , Linux Kernel Mailing List , "open list:AMD IOMMU (AMD-VI)" , Linux Samsung SoC , Joerg Roedel , Inki Dae , Kukjin Kim , =?UTF-8?Q?Krzysztof_Koz=C5=82owski?= , Bartlomiej Zolnierkiewicz , "Rafael J. Wysocki" , Mark Brown , Greg Kroah-Hartman , Tomeu Vizoso , Lukas Wunner , Kevin Hilman , Tobias Jakobi , Laurent Pinchart , Lars-Peter Clausen , Dmitry Torokhov , Grant Likely , Mauro Carvalho Chehab Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 9, 2016 at 4:07 PM, Marek Szyprowski wrote: > Hi Luis, > > > On 2016-11-08 23:14, Luis R. Rodriguez wrote: >> >> On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote: >>> >>> Hi Luis >>> >>> >>> On 2016-10-06 19:37, Luis R. Rodriguez wrote: >>>> >>>> On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote: >>>>> >>>>> This patch uses recently introduced device links to track the runtime >>>>> pm >>>>> state of the master's device. This way each SYSMMU controller is >>>>> runtime >>>>> activated when its master's device is active >>>> >>>> instead of? >>> >>> instead of keeping SYSMMU controller runtime active all the time. >> >> I thought Rafael's work was for suspend/resume, not for runtime suspend. >> Is it for both ? > > > Yes, it solves both problems, although the suspend/resume was easy to > workaround just by using LATE_SLEEP_OPS. Right, but that's just in this particular case, because the dependency chain is of length 2. :-) If you had a longer chain, you might in theory use the _noirq() stage somehow, but that has limitations. >> Because as far as I can tell this was painted to help >> with suspend/resume ? It helps with three things, (async) suspend/resume, runtime PM and shutdown (that last part is the hardest to figure out). The ordering in which all of these are carried out is analogous and cannot be determined correctly by the device registration ordering itself in general (which has been a known fact for years, but some localized workarounds were put in some places to work around that). Moreover, even if the list ordering (of dpm_list, for instance) is correct, it still doesn't guarantee the right ordering of actions that are carried out asynchronously. They are all started in the list order, but they may be running in parallel with each other and complete at different times. For this reason, there needs to be a way to ensure that, say, the suspend operations for consumer devices complete before their suppliers will become unavailable and so on. Both runtime PM and system suspend/resume have this problem. It is not present in the system shutdown case, but it still helps to get a correct list ordering (ie. such that won't cause supplier devices to be shut down before their consumers) in this case too. Thanks, Rafael