Received: by 10.223.185.116 with SMTP id b49csp874174wrg; Wed, 14 Feb 2018 08:15:08 -0800 (PST) X-Google-Smtp-Source: AH8x226rUby/DCMwgk9hNXkXDaK01BGw2OuYl9Cyg61ugKhtAPea94D4x72N8Q/KthB4kfaWRlZD X-Received: by 2002:a17:902:34f:: with SMTP id 73-v6mr4805975pld.55.1518624908223; Wed, 14 Feb 2018 08:15:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518624908; cv=none; d=google.com; s=arc-20160816; b=033ixCHuvQ5CHfDW+miTUWva40KsvzL7DnLO7eyU7XKZFByOOwiU6xSM7CkX8/bXvu cgTmSx6hMzEpXjQhRL8qsE2gAt9lIK8xUJrzLCKBOCMy/y4VH8Ssv7xZ7o28CH0iQVaK n7FPmEJvPjhmrenPhxgJjaiZtZexVepBFkOtRwGeMBa+wMLORftyUiOhlUklw9sNkbU5 Ld/HdcSK0VzbNptsDcbrVQHFnjKNFOl4spEiPkWLRGolxFGvkJs6in9Oue1OxCXUhiba aZSbN87HOPzeRBHzkKYbvhg4F5OqIdzKEkPreL6VolrEdN4Q397wXzs55JVWn6oCSfHG c8rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=r7AdxZjo0Zuf+gTcQCkBX5IQfkwgpGxy1JA1DWUmqKo=; b=AbVpNe8VJaJygEg5j/1LZN5kbzOHTADKtRR0q/UAyfRofdDhpMJY1enkcfKOm6ySVD exxLOoaDSqdnSfnBq4S3DLaPX3gHQ0xHIL2DCou9oK02Uiwd9KzLVOwiDUSstJhbJIV6 JtrbBhb3KIc03UwjCPQg5/Z7ZRRkh8cjfGAt6T49PhoQnQMsuPCPEQbqNP1iqc17ZlTN gllKvlrrtYgq2hKiq8pWzHGMwxLFsouJW/o6W9GDBovh/ddvmF7V+YnLBV0aMT21Cul6 Os1RUV8x4jA8Zg5sGOaXicxxTdalHYjCuv5wr0I9FiwAuql/OEmi3/PR+ny2foIzcdej bNrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A3GNlMIh; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f34-v6si1796186ple.102.2018.02.14.08.14.29; Wed, 14 Feb 2018 08:15:08 -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=@gmail.com header.s=20161025 header.b=A3GNlMIh; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032183AbeBNQM1 (ORCPT + 99 others); Wed, 14 Feb 2018 11:12:27 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:40763 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030349AbeBNQMZ (ORCPT ); Wed, 14 Feb 2018 11:12:25 -0500 Received: by mail-io0-f194.google.com with SMTP id t22so25695672ioa.7; Wed, 14 Feb 2018 08:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=r7AdxZjo0Zuf+gTcQCkBX5IQfkwgpGxy1JA1DWUmqKo=; b=A3GNlMIhW06s9xF674LCplufXn3SnKOHHctWFPxePrZYunxht7LUs/bCOUpLfy1O92 YDm/CINfn3hiGl5zA6KcyiZlqKkUH3IyDjGdWdrcRnOfTy3+L5xRIsitjFrpjMSsYiEd NewM+mXBvb0k4S03Wfkl6mwkdm98HL45t+CwbTWoPQPDVJ32yOORHAyrZif7TcT4sw7U jSe8bPqntOUX8uiQz1lhQNl8xYnYqag2MJpyEp5EWEjk/Aa7xEVS+2CBeuLj2bJv68Sw PLfkQG+mD9X9Xad+s0gncLM1B1s/yZ6hMDY6t/p4DxobNQCyojyMEhwxIkYh8JWh99iu gwcg== 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; bh=r7AdxZjo0Zuf+gTcQCkBX5IQfkwgpGxy1JA1DWUmqKo=; b=nqaw1MnOtZGyN9Wx5Zsik+V7Ur4ZLRdieRp6nJwzr1WzkYboq3be4oheAMA6UvZ1Gu e+ECT5EQLa7kX6z6Yw4MM+vSJw2hQer7GJ4evn/nmbBCQCI/I45pL9soWgzdMTyW/CJ8 aBsSCQ/yiO9Wi/dcWwSuTuBU6dtUANkM46zogQ5Hh5LVqhHN8AOjerqXAwtqFTfBX19V Al6A24YxV5jFFTY3BfDrcFnQDVzBAGH/I2P1LdD8m7Q0O9tcticbSmroVAh4olCUthMC PZfDrdrAMzC0iKlYpPcYRnuqaM43k9hXfcQB/XI8zK/ClpP5vjOUCFNDj1Cy1Xcyt/Nx rGjw== X-Gm-Message-State: APf1xPDn4QvimdKz2cPxa+4tbOk6q6Rva1n719MTjRlZEk04lLpkVJpx dgTB3n+LMIxBgxmvOJ2QGf67YDHAJN8FJrdRYXADwg== X-Received: by 10.107.203.5 with SMTP id b5mr5509472iog.144.1518624744141; Wed, 14 Feb 2018 08:12:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.111.93 with HTTP; Wed, 14 Feb 2018 08:12:23 -0800 (PST) In-Reply-To: <20180214154850.GA25422@jcrouse-lnx.qualcomm.com> References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <1517999482-17317-7-git-send-email-vivek.gautam@codeaurora.org> <20180213164205.GA7599@jcrouse-lnx.qualcomm.com> <20180214154850.GA25422@jcrouse-lnx.qualcomm.com> From: Rob Clark Date: Wed, 14 Feb 2018 11:12:23 -0500 Message-ID: Subject: Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers To: Tomasz Figa , Vivek Gautam , Mark Rutland , devicetree@vger.kernel.org, linux-pm@vger.kernel.org, David Airlie , Will Deacon , "Rafael J. Wysocki" , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , dri-devel , Linux Kernel Mailing List , Rob Herring , Greg KH , freedreno , Robin Murphy , 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 10:48 AM, Jordan Crouse wrote: > On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote: >> >> - When submitting commands to the GPU, the GPU driver will >> pm_runtime_get_sync() on the GPU device, which will automatically do >> the same on all the linked suppliers, which would also include the >> SMMU itself. The role of device links here is exactly that the GPU >> driver doesn't have to care which other devices need to be brought up. > > This is true. Assuming that the device link works correctly we would not need > to explicitly power the SMMU which makes my point entirely moot. Just to point out what motivated this patchset, the biggest problem is iommu_unmap() because that can happen when GPU is not powered on (or in the v4l2 case, because some other device dropped it's reference to the dma-buf allowing it to be free'd). Currently we pm get/put the GPU device around unmap, but it is kinda silly to boot up the GPU just to unmap a buffer. (Semi-related, I would also like to batch map/unmap's, I just haven't gotten around to implementing it yet.. but that would be another case where a single get_supplier()/put_supplier() outside of the iommu would make sense instead of pm_get/put() inside the iommu driver's ->unmap().) If you really dislike the get/put_supplier() approach, then perhaps we need iommu_pm_get()/iommu_pm_put() operations that the iommu user could use to accomplish the same thing? BR, -R