From: Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, "open list:IOMMU DRIVERS" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-arm-msm <linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> Subject: Re: [PATCH v8 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Date: Wed, 7 Mar 2018 22:52:22 +0900 [thread overview] Message-ID: <CAAFQd5BTdF176x5ycatCmCHrMyVX2OZqdXd-JGq06RyDUb0N3g@mail.gmail.com> (raw) In-Reply-To: <d0f2b3ed-136d-7704-2aef-1173a342a89c-5wv7dgnIgG8@public.gmane.org> On Wed, Mar 7, 2018 at 9:38 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote: > On 02/03/18 10:10, Vivek Gautam wrote: >> >> From: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> >> >> 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. >> >> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> >> [vivek: Cleanup pm runtime calls] >> Signed-off-by: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> >> --- >> drivers/iommu/arm-smmu.c | 96 >> ++++++++++++++++++++++++++++++++++++++++++++---- >> 1 file changed, 88 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index c8b16f53f597..3d6a1875431f 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -209,6 +209,8 @@ struct arm_smmu_device { >> struct clk_bulk_data *clks; >> int num_clks; >> + bool rpm_supported; >> + > > > Can we not automatically infer this from whether clocks and/or power domains > are specified or not, then just use pm_runtime_enabled() as the fast-path > check as Tomasz originally proposed? I wouldn't tie this to presence of clocks, since as a next step we would want to actually control the clocks separately. (As far as I understand, on QCom SoCs we might want to have runtime PM active for the translation to work, but clocks gated whenever access to SMMU registers is not needed.) Moreover, you might still have some super high scale thousand-core systems that require clocks to be prepare-enabled, but runtime PM would be undesirable for the reasons we discussed before. > > I worry that relying on statically-defined matchdata is just going to blow > up the driver and DT binding into a maintenance nightmare; I really don't > want to start needing separate definitions for e.g. "arm,juno-etr-mmu-401" > and "arm,juno-hdlcd-mmu-401" just because one otherwise-identical instance > within the SoC is in a separate controllable power domain while the others > aren't. I don't see a reason why both couldn't just have RPM supported regardless of whether there is a real power domain. It would effectively be just a no-op for those that don't have one. IMHO the only reason to avoid having the RPM enabled is the scalability issue we discussed before. Best regards, Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@chromium.org> To: Robin Murphy <robin.murphy@arm.com> Cc: Vivek Gautam <vivek.gautam@codeaurora.org>, Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Will Deacon <will.deacon@arm.com>, Rob Clark <robdclark@gmail.com>, "open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>, devicetree@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, jcrouse@codeaurora.org, Stephen Boyd <sboyd@codeaurora.org>, Sricharan R <sricharan@codeaurora.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Archit Taneja <architt@codeaurora.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org> Subject: Re: [PATCH v8 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Date: Wed, 7 Mar 2018 22:52:22 +0900 [thread overview] Message-ID: <CAAFQd5BTdF176x5ycatCmCHrMyVX2OZqdXd-JGq06RyDUb0N3g@mail.gmail.com> (raw) In-Reply-To: <d0f2b3ed-136d-7704-2aef-1173a342a89c@arm.com> On Wed, Mar 7, 2018 at 9:38 PM, Robin Murphy <robin.murphy@arm.com> wrote: > On 02/03/18 10:10, Vivek Gautam wrote: >> >> From: Sricharan R <sricharan@codeaurora.org> >> >> 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. >> >> Signed-off-by: Sricharan R <sricharan@codeaurora.org> >> [vivek: Cleanup pm runtime calls] >> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> >> --- >> drivers/iommu/arm-smmu.c | 96 >> ++++++++++++++++++++++++++++++++++++++++++++---- >> 1 file changed, 88 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index c8b16f53f597..3d6a1875431f 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -209,6 +209,8 @@ struct arm_smmu_device { >> struct clk_bulk_data *clks; >> int num_clks; >> + bool rpm_supported; >> + > > > Can we not automatically infer this from whether clocks and/or power domains > are specified or not, then just use pm_runtime_enabled() as the fast-path > check as Tomasz originally proposed? I wouldn't tie this to presence of clocks, since as a next step we would want to actually control the clocks separately. (As far as I understand, on QCom SoCs we might want to have runtime PM active for the translation to work, but clocks gated whenever access to SMMU registers is not needed.) Moreover, you might still have some super high scale thousand-core systems that require clocks to be prepare-enabled, but runtime PM would be undesirable for the reasons we discussed before. > > I worry that relying on statically-defined matchdata is just going to blow > up the driver and DT binding into a maintenance nightmare; I really don't > want to start needing separate definitions for e.g. "arm,juno-etr-mmu-401" > and "arm,juno-hdlcd-mmu-401" just because one otherwise-identical instance > within the SoC is in a separate controllable power domain while the others > aren't. I don't see a reason why both couldn't just have RPM supported regardless of whether there is a real power domain. It would effectively be just a no-op for those that don't have one. IMHO the only reason to avoid having the RPM enabled is the scalability issue we discussed before. Best regards, Tomasz
next prev parent reply other threads:[~2018-03-07 13:52 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-02 10:10 [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam [not found] ` <20180302101050.6191-1-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-03-02 10:10 ` [PATCH v8 1/5] iommu/arm-smmu: Destroy domain context in failure path Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam [not found] ` <20180302101050.6191-2-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-03-07 12:20 ` Robin Murphy 2018-03-07 12:20 ` Robin Murphy [not found] ` <d3500b33-8ce6-d767-7e9b-2fd75fea6cbb-5wv7dgnIgG8@public.gmane.org> 2018-03-08 5:32 ` Vivek Gautam 2018-03-08 5:32 ` Vivek Gautam 2018-03-02 10:10 ` [PATCH v8 2/5] iommu/arm-smmu: Add pm_runtime/sleep ops Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam 2018-03-02 10:10 ` [PATCH v8 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam 2018-03-07 12:38 ` Robin Murphy [not found] ` <d0f2b3ed-136d-7704-2aef-1173a342a89c-5wv7dgnIgG8@public.gmane.org> 2018-03-07 13:52 ` Tomasz Figa [this message] 2018-03-07 13:52 ` Tomasz Figa [not found] ` <CAAFQd5BTdF176x5ycatCmCHrMyVX2OZqdXd-JGq06RyDUb0N3g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-07 16:58 ` Robin Murphy 2018-03-07 16:58 ` Robin Murphy [not found] ` <30a2fa5e-3d8e-acb6-ab31-bec652f1be99-5wv7dgnIgG8@public.gmane.org> 2018-03-08 4:33 ` Tomasz Figa 2018-03-08 4:33 ` Tomasz Figa 2018-03-08 12:12 ` Robin Murphy [not found] ` <6fe36177-a8a5-5f17-bf65-1a53538221a4-5wv7dgnIgG8@public.gmane.org> 2018-03-09 4:50 ` Tomasz Figa 2018-03-09 4:50 ` Tomasz Figa [not found] ` <CAAFQd5BU+hU8aPyq6Rcaiwzu1sf7vcRNwnzt5LZZ+L01DnjqhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-09 17:36 ` Robin Murphy 2018-03-09 17:36 ` Robin Murphy 2018-03-02 10:10 ` [PATCH v8 4/5] iommu/arm-smmu: Add the device_link between masters and smmu Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam [not found] ` <20180302101050.6191-5-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-03-07 12:47 ` Robin Murphy 2018-03-07 12:47 ` Robin Murphy 2018-03-08 4:59 ` Vivek Gautam 2018-03-08 4:59 ` Vivek Gautam [not found] ` <CAFp+6iF1oM=fmRCqSG-SxcUVvvOLet_Y0p7pmGn+=B-LdMNiww-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-09 7:11 ` Vivek Gautam 2018-03-09 7:11 ` Vivek Gautam [not found] ` <CAFp+6iFzGYWZMLkNrN1ZJJ2xH4CxQsiU6oYboHDzL0jDwm+4VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-09 12:34 ` Robin Murphy 2018-03-09 12:34 ` Robin Murphy [not found] ` <f6822915-8921-c9cc-218a-f094ac5ed032-5wv7dgnIgG8@public.gmane.org> 2018-03-12 10:21 ` Vivek Gautam 2018-03-12 10:21 ` Vivek Gautam [not found] ` <f3011ef1-7ffe-8c2b-b9d6-3fb094789656-5wv7dgnIgG8@public.gmane.org> 2018-03-09 10:40 ` Vivek Gautam 2018-03-09 10:40 ` Vivek Gautam 2018-03-02 10:10 ` [PATCH v8 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant Vivek Gautam 2018-03-02 10:10 ` Vivek Gautam 2018-03-05 13:25 ` [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support Tomasz Figa 2018-03-05 13:25 ` Tomasz Figa [not found] ` <CAAFQd5AZoCgVts=DOET7js5VPi4ONM2m9R-WM6pWHud26XDVfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-03-05 17:19 ` Vivek Gautam 2018-03-05 17:19 ` Vivek Gautam
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAAFQd5BTdF176x5ycatCmCHrMyVX2OZqdXd-JGq06RyDUb0N3g@mail.gmail.com \ --to=tfiga-f7+t8e8rja9g9huczpvpmw@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \ --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.