Received: by 10.223.185.116 with SMTP id b49csp124233wrg; Tue, 13 Feb 2018 18:00:55 -0800 (PST) X-Google-Smtp-Source: AH8x227P4uo6w1SXC4Kd+b6CWUQZI+yDgReztx/+EgZXqTcLVP150+AIq7IkfnjyImVELma0Kuhd X-Received: by 10.99.66.195 with SMTP id p186mr2469257pga.378.1518573655349; Tue, 13 Feb 2018 18:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518573655; cv=none; d=google.com; s=arc-20160816; b=s9ILr5OVwGFArhNejjP7z54B0Yxuxw9eVOwoywn1t2O2VqhcE+uZruT2xs0wml5TIK n8p6AUtF8yWTySgBzPmepWht8EAcT6qGu3t/Mi4jnDQyZE1pUS+Z5fSWI0OAujApChP+ kDWlxcsagOdVCFFTb2wgA8VRTXcPW2g4lQUfeN45HthA3UxhpeEOXNjn9ramFljiHSxS aldghG1XLNj9wu10vWS4K8e9m5DNf/5hACMcdONSCvi0VxQoM29ud8qSqtpsYIjBkSFw GKLhwLJsd7/3Z9zNqSBrqvF4p875td5GT1Df6utGsT/eaTriMHglxFI7UxxrmGy85JsH bw6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=EkNRLVo36zk6zH5/pVJMpZM+bB8AbDDmSYvJIY5dMHs=; b=pu7NMouUqvVFqkt75+XBsjCRVpjXh2H0NN+bFKCnvdhdMoRumDkfCMkBiBJvQKCZa8 0UAfJTO2Zg66CSh+WInDeT4TNO/T+rI13OK9asU71CZNV/FJGyrwQRfNngaqgt7GRCRw Og1f3fGI6cqFtGvroKKdw0+8n978yhYlJ/DSlWlCkG6L5SbADCrGwoIpd0nE3M7/2s0u 9jB455E2yBq654YzWKbVkiAz9Rucq83CzZwzYtV99OtUURywC+ow97PkDQqts5DBp6AU hy8w4Z/oOxa7Nw5RMZH9XWdOxcUQ8a2ldbd1H2v/A1crVxhsBdT7aJg4oPAiDOSHZ1tc e7ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Qn8voTQt; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3-v6si2075251plb.79.2018.02.13.18.00.39; Tue, 13 Feb 2018 18:00:55 -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; dkim=pass header.i=@chromium.org header.s=google header.b=Qn8voTQt; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966454AbeBNB7z (ORCPT + 99 others); Tue, 13 Feb 2018 20:59:55 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:37802 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966401AbeBNB7x (ORCPT ); Tue, 13 Feb 2018 20:59:53 -0500 Received: by mail-ua0-f196.google.com with SMTP id q8so12796188uae.4 for ; Tue, 13 Feb 2018 17:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EkNRLVo36zk6zH5/pVJMpZM+bB8AbDDmSYvJIY5dMHs=; b=Qn8voTQt3bsvW6gdO3BYl5Slydf8TK5pAQ4QM2jywN6McrTpzJ7z+rTXphnHPJDi8K XA4H8qKquTrukwax7oyXWHzgRcHpD8l6iBVPQEbW3LTwtNt2/T9gDKJCynZfGKriDZ1B R1pWH3tCnlb5Hp8xrpSLYSg2cuOVfynHu/Nfg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EkNRLVo36zk6zH5/pVJMpZM+bB8AbDDmSYvJIY5dMHs=; b=T/XbOlDEj0jDmHV+K4TeuvU7msnvRw1nlDSLj+Is3X6hjxEKS/MdnF1OHrPiu0VVOJ FZSyuX9qleyj9iFpRtEUjg5ko1XbUxzgm81k4QTqCAtuQLKBPhZokDmi8m6frHm+vdPm CVhd3LHH3fhhtSRQYL03F9Ej8OkYAzFeuKOxPwuT/5nkrbzP4l5+9RfgoSLFNaddIvQO kQgNeMdAjQ/hBz4agvNf9k/sxJULqZ5pXR2m1FEsCXQ1ulBsQIFaI7YMFoOQx7RUtHMA /O0zJERqggvhE0RO6kl7gyEUemnJIUB2XZ66gH43GczJe6loDXC7TwyRHSYqQSIOCr+1 VEoA== X-Gm-Message-State: APf1xPBvk8KFeqtKPWOUlmOzq0cd6gwGbZ0TlsJW0TlJuh/l5hBx819N BXIPAAXasVvRRhvD+Lbhsc1q9t9kU2I= X-Received: by 10.159.55.239 with SMTP id q102mr3091846uaq.202.1518573592514; Tue, 13 Feb 2018 17:59:52 -0800 (PST) Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com. [209.85.217.172]) by smtp.gmail.com with ESMTPSA id g5sm3943514uac.43.2018.02.13.17.59.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 17:59:51 -0800 (PST) Received: by mail-ua0-f172.google.com with SMTP id y17so11018387uaa.13 for ; Tue, 13 Feb 2018 17:59:50 -0800 (PST) X-Received: by 10.159.43.143 with SMTP id y15mr3145897uai.96.1518573590099; Tue, 13 Feb 2018 17:59:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.0.68 with HTTP; Tue, 13 Feb 2018 17:59:29 -0800 (PST) In-Reply-To: References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <1517999482-17317-7-git-send-email-vivek.gautam@codeaurora.org> From: Tomasz Figa Date: Wed, 14 Feb 2018 10:59:29 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers To: Rob Clark Cc: Vivek Gautam , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Rob Herring , Mark Rutland , "Rafael J. Wysocki" , Robin Murphy , Will Deacon , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , devicetree@vger.kernel.org, Linux Kernel Mailing List , linux-pm@vger.kernel.org, dri-devel , freedreno , David Airlie , Greg KH , Stephen Boyd , linux-arm-msm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: > On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: >> Hi Vivek, >> >> Thanks for the patch. Please see my comments inline. >> >> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam >> wrote: >>> While handling the concerned iommu, there should not be a >>> need to power control the drm devices from iommu interface. >>> If these drm devices need to be powered around this time, >>> the respective drivers should take care of this. >>> >>> Replace the pm_runtime_get/put_sync() with >>> pm_runtime_get/put_suppliers() calls, to power-up >>> the connected iommu through the device link interface. >>> In case the device link is not setup these get/put_suppliers() >>> calls will be a no-op, and the iommu driver should take care of >>> powering on its devices accordingly. >>> >>> Signed-off-by: Vivek Gautam >>> --- >>> drivers/gpu/drm/msm/msm_iommu.c | 16 ++++++++-------- >>> 1 file changed, 8 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c >>> index b23d33622f37..1ab629bbee69 100644 >>> --- a/drivers/gpu/drm/msm/msm_iommu.c >>> +++ b/drivers/gpu/drm/msm/msm_iommu.c >>> @@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char * const *names, >>> struct msm_iommu *iommu = to_msm_iommu(mmu); >>> int ret; >>> >>> - pm_runtime_get_sync(mmu->dev); >>> + pm_runtime_get_suppliers(mmu->dev); >>> ret = iommu_attach_device(iommu->domain, mmu->dev); >>> - pm_runtime_put_sync(mmu->dev); >>> + pm_runtime_put_suppliers(mmu->dev); >> >> For me, it looks like a wrong place to handle runtime PM of IOMMU >> here. iommu_attach_device() calls into IOMMU driver's attach_device() >> callback and that's where necessary runtime PM gets should happen, if >> any. In other words, driver A (MSM DRM driver) shouldn't be dealing >> with power state of device controlled by driver B (ARM SMMU). > > Note that we end up having to do the same, because of iommu_unmap() > while DRM driver is powered off.. it might be cleaner if it was all > self contained in the iommu driver, but that would make it so other > drivers couldn't call iommu_unmap() from an irq handler, which is > apparently something that some of them want to do.. I'd assume that runtime PM status is already guaranteed to be active when the IRQ handler is running, by some other means (e.g. pm_runtime_get_sync() called earlier, when queuing some work to the hardware). Otherwise, I'm not sure how a powered down device could trigger an IRQ. So, if the master device power is already on, suppliers should be powered on as well, thanks to device links. Best regards, Tomasz