Received: by 10.223.185.116 with SMTP id b49csp3285201wrg; Tue, 13 Feb 2018 00:05:09 -0800 (PST) X-Google-Smtp-Source: AH8x226gJuRDYWUOZcirW4XQjqEL69pybP5ToCb7B1+K0KqUM3p9w5zpvNYdvzRgbx2x84e1QVm5 X-Received: by 10.98.170.15 with SMTP id e15mr388338pff.207.1518509109872; Tue, 13 Feb 2018 00:05:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518509109; cv=none; d=google.com; s=arc-20160816; b=ctNC0Hs/DquNN8l1YruAcD+CpxMstphC9SYTarPBUUDvV1Nfm3KJHryiFlrkjAvVQn +e5A8BSClEOEdtOgMZbpUTEHSIN1FxXqT0V9iwl7dTX+vJJQX5ujErC8xuZS0F6QwRxs zwDM3uHQ3DI9MdLPaT6sPWEPuknOfUrGI/dpjfKMxjs2GkQHdcjp38SGb5pYp/ELDq8u AxnnQjafI69C3UcJIBRqDnrqhyyLZJz9Rtny7x/dS0vx+k88RWXOEsQmBcBLrze1F7v4 1zQRg3c+Npvpcv1UTfEK+u4Z27n8rSYSniBqhQTKB/LgViLBoSncLY16NNg3tixbbO0g P8pA== 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=KSEe8sooJZLGzHQBewQf9xocluTnQeakksjHEwUXMI4=; b=qWTRasb2yi2TEySSZaNo9aDiQfYP8qzu31T6lipZnulsJwnIivG8ypgXIo6GKGqC8D b7qrPuz0NxEf8QvS8CpJxF9DgGzIv2NI/KtulgRpTFD3rwknYHDe0I+0oA9Uydr9irw0 dz7ftOjjICuUnKnQ+wDRNIgKr2ePTDenZp0Ab8t519Qh576li1dnGnXz/g5jpc7/xgYg DhuolB28fnXwtR58NzGYRuUi8MHkbv8YBXsfGUYTJwmdt1mmkRSyAu0pFX6pvLFssS/f dDAgL+ywvEqJ5ADBaiXLcuhH514cUbAhlbFzKZDhAmohP2PLCQXQ9oEZWWfd306+8N3i HjZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=KYEFY77a; 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 65si3592684pft.320.2018.02.13.00.04.54; Tue, 13 Feb 2018 00:05:09 -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=KYEFY77a; 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 S933680AbeBMIEO (ORCPT + 99 others); Tue, 13 Feb 2018 03:04:14 -0500 Received: from mail-vk0-f66.google.com ([209.85.213.66]:39947 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933550AbeBMIEM (ORCPT ); Tue, 13 Feb 2018 03:04:12 -0500 Received: by mail-vk0-f66.google.com with SMTP id o17so3059462vke.7 for ; Tue, 13 Feb 2018 00:04:12 -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=KSEe8sooJZLGzHQBewQf9xocluTnQeakksjHEwUXMI4=; b=KYEFY77aaUalXsbMaHvDxC1wsIkf0mwtGqeQP/sYKXzDlWR3s2YOcOaTeDiJnHVIN6 vRyWx1Fl8iXqA1VoAa2Fo4VB+BlAeX648KFBlJAEigtg/+HPDTzSkbI4d9EHlsY29Bxw WpzbKVuZVSg+KFM58GGsvF117GXJIDMsVWLUo= 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=KSEe8sooJZLGzHQBewQf9xocluTnQeakksjHEwUXMI4=; b=Dp1cz5EIVQ29unhRUqa7Mjqm6Wh7+YwxSj9HWIIg3/FWFAWsVnamgKwFIpNapDCBn4 GzMce/ZEWw6dYrAKPIOfdpu2wTPT2unb7gdYlNHQLAgZYNMAmWC4Z2yYjXkLbLcHncUj 77vNv8yXCXkbRM+u5Tt+iIcli1FK2lwBnQdhPQsx9uAJq+Ki0wrtX7BjYMsY9deYt5gW Feq433Zdi4nElSsjcCe/z5lL5JkwNp8Cjt+A/EQqZpZdggdrL9vMQrONmSMgiFPUpdG3 1kN8AJpByt2srweQGA03f+kihWT9aF7pzegaow4UMj81zhGaSHbbaJUeR2NgX5XHJYr/ aAoA== X-Gm-Message-State: APf1xPDTV7UiR+86ieYzWxOeaERSfWiK4WktVESCYg4ojwu7DsScQv0X 1rfPV2ZvEqDDSafiRqrM2nBO7LX/168= X-Received: by 10.31.224.135 with SMTP id x129mr340098vkg.180.1518509051797; Tue, 13 Feb 2018 00:04:11 -0800 (PST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com. [209.85.217.181]) by smtp.gmail.com with ESMTPSA id i74sm2631627vke.18.2018.02.13.00.04.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 00:04:10 -0800 (PST) Received: by mail-ua0-f181.google.com with SMTP id i5so11055500uai.10 for ; Tue, 13 Feb 2018 00:04:09 -0800 (PST) X-Received: by 10.159.43.143 with SMTP id y15mr350562uai.96.1518509049327; Tue, 13 Feb 2018 00:04:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.0.68 with HTTP; Tue, 13 Feb 2018 00:03:48 -0800 (PST) In-Reply-To: <1517999482-17317-3-git-send-email-vivek.gautam@codeaurora.org> References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <1517999482-17317-3-git-send-email-vivek.gautam@codeaurora.org> From: Tomasz Figa Date: Tue, 13 Feb 2018 17:03:48 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops To: Vivek Gautam Cc: "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Rob Herring , Mark Rutland , "Rafael J. Wysocki" , Robin Murphy , Will Deacon , Rob Clark , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, dri-devel , freedreno@lists.freedesktop.org, David Airlie , Greg KH , sboyd@codeaurora.org, linux-arm-msm@vger.kernel.org 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 Hi Vivek, Thanks for the patch. Please see some comments inline. On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam wrote: > From: Sricharan R > > The smmu needs to be functional only when the respective > master's using it are active. The device_link feature > helps to track such functional dependencies, so that the > iommu gets powered when the master device enables itself > using pm_runtime. So by adapting the smmu driver for > runtime pm, above said dependency can be addressed. > > This patch adds the pm runtime/sleep callbacks to the > driver and also the functions to parse the smmu clocks > from DT and enable them in resume/suspend. > > Signed-off-by: Sricharan R > Signed-off-by: Archit Taneja > [vivek: Clock rework to request bulk of clocks] > Signed-off-by: Vivek Gautam > --- > drivers/iommu/arm-smmu.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 54 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > index 69e7c60792a8..9e2f917e16c2 100644 > --- a/drivers/iommu/arm-smmu.c > +++ b/drivers/iommu/arm-smmu.c > @@ -48,6 +48,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -205,6 +206,8 @@ struct arm_smmu_device { > u32 num_global_irqs; > u32 num_context_irqs; > unsigned int *irqs; > + struct clk_bulk_data *clocks; > + int num_clks; nit: Perhaps "num_clocks" to be consistent with "clocks"? > > u32 cavium_id_base; /* Specific to Cavium */ > > @@ -1897,10 +1900,12 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu) > struct arm_smmu_match_data { > enum arm_smmu_arch_version version; > enum arm_smmu_implementation model; > + const char * const *clks; > + int num_clks; nit: Perhaps s/clks/clocks/ here or s/clocks/clks/ in struct arm_smmu_device? > }; > > #define ARM_SMMU_MATCH_DATA(name, ver, imp) \ > -static struct arm_smmu_match_data name = { .version = ver, .model = imp } > +static const struct arm_smmu_match_data name = { .version = ver, .model = imp } > > ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU); > ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU); > @@ -2001,6 +2006,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev, > data = of_device_get_match_data(dev); > smmu->version = data->version; > smmu->model = data->model; > + smmu->num_clks = data->num_clks; > > parse_driver_options(smmu); > > @@ -2039,6 +2045,28 @@ static void arm_smmu_bus_init(void) > #endif > } > > +static int arm_smmu_init_clks(struct arm_smmu_device *smmu) > +{ > + int i; > + int num = smmu->num_clks; > + const struct arm_smmu_match_data *data; > + > + if (num < 1) > + return 0; > + > + smmu->clocks = devm_kcalloc(smmu->dev, num, > + sizeof(*smmu->clocks), GFP_KERNEL); > + if (!smmu->clocks) > + return -ENOMEM; > + > + data = of_device_get_match_data(smmu->dev); > + > + for (i = 0; i < num; i++) > + smmu->clocks[i].id = data->clks[i]; I'd argue that arm_smmu_device_dt_probe() is a better place for all the code above, since this function is called regardless of whether the device is probed from DT or not. Going further, arm_smmu_device_acpi_probe() could fill smmu->num_clks and ->clocks using ACPI-like way (as opposed to OF match data) if necessary. Best regards, Tomasz