Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965028AbaLKPXA (ORCPT ); Thu, 11 Dec 2014 10:23:00 -0500 Received: from mail-qa0-f48.google.com ([209.85.216.48]:56243 "EHLO mail-qa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933385AbaLKPW7 (ORCPT ); Thu, 11 Dec 2014 10:22:59 -0500 MIME-Version: 1.0 In-Reply-To: References: <1418286387-9663-1-git-send-email-tfiga@chromium.org> <1418286387-9663-3-git-send-email-tfiga@chromium.org> Date: Thu, 11 Dec 2014 16:22:57 +0100 Message-ID: Subject: Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM From: Ulf Hansson To: Tomasz Figa Cc: "open list:ARM/Rockchip SoC..." , "linux-pm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , iommu@lists.linux-foundation.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , Heiko Stuebner , Joerg Roedel , Kevin Hilman , Geert Uytterhoeven , Sylwester Nawrocki , Daniel Kurtz 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 11 December 2014 at 13:42, Tomasz Figa wrote: > Hi Ulf, > > On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson wrote: >> On 11 December 2014 at 09:26, Tomasz Figa wrote: >>> This patch modifies the rockchip-iommu driver to consider state of >>> the power domain the IOMMU is located in. When the power domain >>> is powered off, the IOMMU cannot be accessed and register programming >>> must be deferred until the power domain becomes enabled. > > [snip] > >>> @@ -988,11 +1107,28 @@ static int rk_iommu_probe(struct platform_device *pdev) >>> return -ENXIO; >>> } >>> >>> + pm_runtime_no_callbacks(dev); >>> + pm_runtime_enable(dev); >>> + >>> + /* Synchronize state of the domain with driver data. */ >>> + pm_runtime_get_sync(dev); >>> + iommu->is_powered = true; >> >> Doesn't the runtime PM status reflect the value of "is_powered", thus >> why do you need to have a copy of it? Could it perpahps be that you >> try to cope with the case when CONFIG_PM is unset? >> > > It's worth noting that this driver fully relies on status of other > devices in the power domain the IOMMU is in and does not enforce the > status on its own. So in general, as far as my understanding of PM > runtime subsystem, the status of the IOMMU device will be always > suspended, because nobody will call pm_runtime_get() on it (except the > get and put pair in probe). So is_powered is here to track status of > the domain, not the device. Feel free to suggest a better way, though. I see, thanks for clarifying. I think it makes sense as is, I have no better suggestion. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/