Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1600126imm; Fri, 7 Sep 2018 03:07:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZb7Zfx6HyIPO4Jr+3OkBH3Y0W09taVT6acOzWnun2x0OyWQxXPxcOc/ey1vUpwvVwUCRCT X-Received: by 2002:a63:f616:: with SMTP id m22-v6mr7442878pgh.293.1536314829398; Fri, 07 Sep 2018 03:07:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536314829; cv=none; d=google.com; s=arc-20160816; b=J7+yyGfe09XTRIgRWjjJN3EFCMctxjZVlwby+p7zaemU62O2iE5M2Oq06LPnuhXWpK ZyOh9PcAfWd5RyoIzetMHZ7QNQ45e+7fNnJ/V+/4qsZvQCUwjto2tBouTvdioraF8bhG AuNL/ViHMv6SuPB2dD8FszmIUew3hFB/WAh5GCP7xQ9cCSC4dtfklsA2Rtiexgs2TZlV 4fhcWF1HtKVAzLFhSp0JH5j2/9wonnDmC/Ba5pDrGhP3w5zrn3dcBS0PdSt2JVPLRgya XHcOOFZ46YfClWTA7R8+OaBlmC8P90pqA+6TfGi1CZKFaFMVBclzw9e5JuR03qUCg79M rCYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature; bh=u9fvgg2VBTclPoqDdE2UyL4I4uq+3AqOjZ5213RhzUU=; b=wH+tUtgofvXUTN+t14k6JNhp74CyGkG5uwrxtMdPpZGPULbwB4AQBCoImRZTIIe9qI +/lvhjW8FCXMFuJ8i1PrhDG/Ht2czJ1DMEclid7L+3aqPro3qQsLHHuY0Pt4vPwLBp+4 wX8WTgue2ppimKDNl+CG241ESJ0YLSfUf9ecrjP8YHUvu1pXu13Rs5Un7wwuEIDul4d2 PNm9CpS7e//mn2p/w0AgShV0xOLD8ZEjWzcRGwlyYe1IS7Bpmy2Vik9NpXyr8aCB21uQ GysKNI8bwzzslXtRAJ+3LukHC5y3cRB88odEnSGPncqlCZggzpB6LKHt5aamw8J/Oocl bUAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=cma5reha; dkim=pass header.i=@codeaurora.org header.s=default header.b=LJpieiiK; 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 y26-v6si7753995pfn.111.2018.09.07.03.06.22; Fri, 07 Sep 2018 03:07:09 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=cma5reha; dkim=pass header.i=@codeaurora.org header.s=default header.b=LJpieiiK; 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 S1728452AbeIGOSV (ORCPT + 99 others); Fri, 7 Sep 2018 10:18:21 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38094 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727806AbeIGOSU (ORCPT ); Fri, 7 Sep 2018 10:18:20 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F34C46083C; Fri, 7 Sep 2018 09:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536313094; bh=NgwEYxA5lkHx+VNzqa6GL0iqQPzixkCvsKGpqHwJRjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cma5rehawuiwauYz/cGh7JG8TCiO65T9DgT9GmKTJPVkgJAAFdU2v7nGv8s6MJRoV hovyCCMjEUYmWzKGQ2x3FbYK6yiBzAS+UoYvK/vQUPCpJQmx4XcbSk7pL7Iuzee+tk 0pGqL8FNwpDCNl33KvQDsJvPG6K7ZpSFZBqhQmZw= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.79.41.39] (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.18.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vivek.gautam@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9A3026055B; Fri, 7 Sep 2018 09:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536313092; bh=NgwEYxA5lkHx+VNzqa6GL0iqQPzixkCvsKGpqHwJRjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LJpieiiKfOfNS6LTAsR/C/Mya3Y+WgTmCFg2QiBL2B5o3+KEN1ofa7ZQgHnCk5Kcz xRfDg8Y3v6glPqpgupLWfuasIsLPn3aJQVc0s4GK5LlCd0h1psm2CnsNO9mW0cDUE1 meFY35Vh8t7KTrJMuU0giB/qVjQocSIdIIc7V1aM= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9A3026055B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vivek.gautam@codeaurora.org Subject: Re: [PATCH v16 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Tomasz Figa Cc: "list@263.net:IOMMU DRIVERS" , Joerg Roedel , joro@8bytes.org, Rob Herring , Robin Murphy , Will Deacon , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, Linux Kernel Mailing List , Alex Williamson , Mark Rutland , "Rafael J. Wysocki" , Rob Clark , Linux PM , freedreno , sboyd@kernel.org, jcrouse@codeaurora.org, Sricharan R , Marek Szyprowski , Archit Taneja , linux-arm-msm References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-3-vivek.gautam@codeaurora.org> From: Vivek Gautam Message-ID: <3ccc3690-dc9d-56e7-e2d1-62e73a189bff@codeaurora.org> Date: Fri, 7 Sep 2018 15:08:02 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tomasz, On 9/7/2018 2:46 PM, Tomasz Figa wrote: > Hi Vivek, > > On Thu, Aug 30, 2018 at 11:46 PM Vivek Gautam > wrote: >> From: Sricharan R >> >> The smmu device probe/remove and add/remove master device callbacks >> gets called when the smmu is not linked to its master, that is without >> the context of the master device. So calling runtime apis in those places >> separately. >> Global locks are also initialized before enabling runtime pm as the >> runtime_resume() calls device_reset() which does tlb_sync_global() >> that ultimately requires locks to be initialized. >> >> Signed-off-by: Sricharan R >> [vivek: Cleanup pm runtime calls] >> Signed-off-by: Vivek Gautam >> Reviewed-by: Tomasz Figa >> Tested-by: Srinivas Kandagatla >> --- >> drivers/iommu/arm-smmu.c | 89 +++++++++++++++++++++++++++++++++++++++++++----- >> 1 file changed, 81 insertions(+), 8 deletions(-) > [snip] >> @@ -2215,10 +2281,17 @@ static int arm_smmu_device_remove(struct platform_device *pdev) >> if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS)) >> dev_err(&pdev->dev, "removing device with active domains!\n"); >> >> + arm_smmu_rpm_get(smmu); >> /* Turn the thing off */ >> writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); >> + arm_smmu_rpm_put(smmu); >> + >> + if (pm_runtime_enabled(smmu->dev)) >> + pm_runtime_force_suspend(smmu->dev); >> + else >> + clk_bulk_disable(smmu->num_clks, smmu->clks); >> >> - clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks); >> + clk_bulk_unprepare(smmu->num_clks, smmu->clks); > Aren't we missing pm_runtime_disable() here? We'll have the enable > count unbalanced if the driver is removed and probed again. pm_runtime_force_suspend() does a pm_runtime_disable() also if i am not wrong. And, as mentioned in a previous thread [1], we were seeing a warning which we avoided by keeping force_suspend(). [1] https://lkml.org/lkml/2018/7/8/124 Thanks Vivek > > Also, if we add pm_runtime_disable(), we can reorder things a bit and > simplify into: > > arm_smmu_rpm_get(smmu); > > /* Turn the thing off */ > writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); > > if (pm_runtime_enabled()) > pm_runtime_disable(); > arm_smmu_rpm_put(smmu); > > clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks); > > Best regards, > Tomasz