From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752253AbdGMN50 (ORCPT ); Thu, 13 Jul 2017 09:57:26 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:44240 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751324AbdGMN5X (ORCPT ); Thu, 13 Jul 2017 09:57:23 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A89E7612BB 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 MIME-Version: 1.0 In-Reply-To: <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> References: <1499333825-7658-1-git-send-email-vivek.gautam@codeaurora.org> <1499333825-7658-4-git-send-email-vivek.gautam@codeaurora.org> <20170712225459.GZ22780@codeaurora.org> <5ee0bacd-e557-a6c4-a897-844fb12ea6ae@codeaurora.org> <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> From: Vivek Gautam Date: Thu, 13 Jul 2017 19:27:20 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Sricharan R , Stephen Boyd , robin.murphy@arm.com Cc: joro@8bytes.org, "robh+dt" , Mark Rutland , Will Deacon , Marek Szyprowski , Rob Clark , iommu@lists.linux-foundation.org, "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-clk@vger.kernel.org, linux-arm-msm@vger.kernel.org, Stanimir Varbanov , architt@codeaurora.org, "linux-arm-kernel@lists.infradead.org" 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 Thu, Jul 13, 2017 at 11:05 AM, Sricharan R wrote: > Hi Vivek, > > On 7/13/2017 10:43 AM, Vivek Gautam wrote: >> Hi Stephen, >> >> >> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>> On 07/06, Vivek Gautam wrote: >>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, >>>> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova, >>>> size_t size) >>>> { >>>> - struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >>>> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >>>> + struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>>> + size_t ret; >>>> if (!ops) >>>> return 0; >>>> - return ops->unmap(ops, iova, size); >>>> + pm_runtime_get_sync(smmu_domain->smmu->dev); >>> Can these map/unmap ops be called from an atomic context? I seem >>> to recall that being a problem before. >> >> That's something which was dropped in the following patch merged in master: >> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >> >> Looks like we don't need locks here anymore? > > Apart from the locking, wonder why a explicit pm_runtime is needed > from unmap. Somehow looks like some path in the master using that > should have enabled the pm ? Right, the master should have done a runtime_get(), and with device links the iommu will also resume. The master will call the unmap when it is attached to the iommu and therefore the iommu should be in resume state. We shouldn't have an unmap without the master attached anyways. Will investigate this further if we need the pm_runtime() calls around unmap or not. Best regards Vivek > > Regards, > Sricharan > > -- > "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project