From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Taniya Das <tdas@codeaurora.org>, srimuc <srimuc@codeaurora.org>,
linux-arm-msm@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu/arm-smmu: Add clk_bulk_{prepare/unprepare} to system pm callbacks
Date: Tue, 27 Jul 2021 16:05:12 +0530 [thread overview]
Message-ID: <ee409973019e7412d221001955045cea@codeaurora.org> (raw)
In-Reply-To: <c23a16d8-e39c-253f-5631-cffa94a1d532@arm.com>
Hi Robin,
On 2021-07-27 16:03, Robin Murphy wrote:
> On 2021-07-27 11:25, Robin Murphy wrote:
>> On 2021-07-27 10:33, Sai Prakash Ranjan wrote:
>>> Some clocks for SMMU can have parent as XO such as
>>> gpu_cc_hub_cx_int_clk
>>> of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states
>>> in
>>> such cases, we would need to drop the XO clock vote in unprepare call
>>> and
>>> this unprepare callback for XO is in RPMh (Resource Power
>>> Manager-Hardened)
>>> clock driver which controls RPMh managed clock resources for new QTI
>>> SoCs
>>> and is a blocking call.
>>>
>>> Given we cannot have a sleeping calls such as clk_bulk_prepare() and
>>> clk_bulk_unprepare() in arm-smmu runtime pm callbacks since the iommu
>>> operations like map and unmap can be in atomic context and are in
>>> fast
>>> path, add this prepare and unprepare call to drop the XO vote only
>>> for
>>> system pm callbacks since it is not a fast path and we expect the
>>> system
>>> to enter deep sleep states with system pm as opposed to runtime pm.
>>>
>>> This is a similar sequence of clock requests (prepare,enable and
>>> disable,unprepare) in arm-smmu probe and remove.
>>
>> Nope. We call arm_smmu_rpm_get(), which may resume the device, from
>> atomic contexts. clk_prepare() may sleep. This doesn't work.
>
> Urgh, or maybe I skimmed the commit message too lightly *and* managed
> to totally misread the patch, sorry :(
>
> I'll wake up some more and try again later...
>
No worries, we took our time looking through that many times before
posting this :)
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Taniya Das <tdas@codeaurora.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>,
srimuc <srimuc@codeaurora.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu/arm-smmu: Add clk_bulk_{prepare/unprepare} to system pm callbacks
Date: Tue, 27 Jul 2021 16:05:12 +0530 [thread overview]
Message-ID: <ee409973019e7412d221001955045cea@codeaurora.org> (raw)
In-Reply-To: <c23a16d8-e39c-253f-5631-cffa94a1d532@arm.com>
Hi Robin,
On 2021-07-27 16:03, Robin Murphy wrote:
> On 2021-07-27 11:25, Robin Murphy wrote:
>> On 2021-07-27 10:33, Sai Prakash Ranjan wrote:
>>> Some clocks for SMMU can have parent as XO such as
>>> gpu_cc_hub_cx_int_clk
>>> of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states
>>> in
>>> such cases, we would need to drop the XO clock vote in unprepare call
>>> and
>>> this unprepare callback for XO is in RPMh (Resource Power
>>> Manager-Hardened)
>>> clock driver which controls RPMh managed clock resources for new QTI
>>> SoCs
>>> and is a blocking call.
>>>
>>> Given we cannot have a sleeping calls such as clk_bulk_prepare() and
>>> clk_bulk_unprepare() in arm-smmu runtime pm callbacks since the iommu
>>> operations like map and unmap can be in atomic context and are in
>>> fast
>>> path, add this prepare and unprepare call to drop the XO vote only
>>> for
>>> system pm callbacks since it is not a fast path and we expect the
>>> system
>>> to enter deep sleep states with system pm as opposed to runtime pm.
>>>
>>> This is a similar sequence of clock requests (prepare,enable and
>>> disable,unprepare) in arm-smmu probe and remove.
>>
>> Nope. We call arm_smmu_rpm_get(), which may resume the device, from
>> atomic contexts. clk_prepare() may sleep. This doesn't work.
>
> Urgh, or maybe I skimmed the commit message too lightly *and* managed
> to totally misread the patch, sorry :(
>
> I'll wake up some more and try again later...
>
No worries, we took our time looking through that many times before
posting this :)
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-07-27 10:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 9:33 [PATCH] iommu/arm-smmu: Add clk_bulk_{prepare/unprepare} to system pm callbacks Sai Prakash Ranjan
2021-07-27 9:33 ` Sai Prakash Ranjan
2021-07-27 10:25 ` Robin Murphy
2021-07-27 10:25 ` Robin Murphy
2021-07-27 10:25 ` Robin Murphy
2021-07-27 10:33 ` Robin Murphy
2021-07-27 10:33 ` Robin Murphy
2021-07-27 10:33 ` Robin Murphy
2021-07-27 10:35 ` Sai Prakash Ranjan [this message]
2021-07-27 10:35 ` Sai Prakash Ranjan
2021-08-02 16:12 ` Will Deacon
2021-08-02 16:12 ` Will Deacon
2021-08-02 16:12 ` Will Deacon
2021-08-03 1:14 ` Rob Clark
2021-08-03 1:14 ` Rob Clark
2021-08-03 1:14 ` Rob Clark
2021-08-03 6:06 ` Sai Prakash Ranjan
2021-08-03 6:06 ` Sai Prakash Ranjan
2021-08-10 6:51 ` Sai Prakash Ranjan
2021-08-10 6:51 ` Sai Prakash Ranjan
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=ee409973019e7412d221001955045cea@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rnayak@codeaurora.org \
--cc=robin.murphy@arm.com \
--cc=srimuc@codeaurora.org \
--cc=tdas@codeaurora.org \
--cc=will@kernel.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: link
Be 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.