From: Chris Lew <quic_clew@quicinc.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: <linux-remoteproc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks
Date: Mon, 20 May 2024 21:08:51 -0700 [thread overview]
Message-ID: <a944418a-1699-44fa-bdfc-2e57129adea1@quicinc.com> (raw)
In-Reply-To: <3521519f-34b8-472d-be37-f0e64bba24fc@kernel.org>
On 5/19/2024 10:36 AM, Krzysztof Kozlowski wrote:
> On 17/05/2024 00:58, Chris Lew wrote:
>> Add hwlocks property to describe the hwspinlock that remoteproc can try
>> to bust on behalf of the remoteproc's smem.
>
> Sorry, as you wrote, the lock is part of smem, not here. Drivers do not
> crash, so if your crashes as you imply in the cover letter, then first
> fix the driver.
>
Hi Krzysztof,
Sorry for the confusion, I dont think I meant that the smem driver will
ever crash. The referred to crash in the cover letter is a crash in the
firmware running on the remoteproc. The remoteproc could crash for any
unexpected reason, related or unrelated to smem, while holding the tcsr
mutex. I want to ensure that all resources that a remoteproc might be
using are released as part of remoteproc stop.
The SMEM driver manages the lock/unlock operations on the tcsr mutex
from the Linux CPU's perspective. This case is for cleaning up from the
remote side's perspective.
In this case it's the hwspinlock used to synchronize SMEM, but it's
conceivable that firmware running on the remoteproc has additional locks
that need to be busted in order for the system to continue executing
until the firmware is reinitialized.
We did consider tying this to the SMEM instance, but the entitiy
relating to firmware is the remoteproc instance.
> Best regards,
> Krzysztof
>
next prev parent reply other threads:[~2024-05-21 4:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 22:58 [PATCH 0/7] Add support for hwspinlock bust Chris Lew
2024-05-16 22:58 ` [PATCH 1/7] hwspinlock: Introduce refcount Chris Lew
2024-05-17 8:58 ` Bryan O'Donoghue
2024-05-17 18:32 ` Chris Lew
2024-05-16 22:58 ` [PATCH 2/7] hwspinlock: Enable hwspinlock sharing Chris Lew
2024-05-16 22:58 ` [PATCH 3/7] hwspinlock: Introduce hwspin_lock_bust() Chris Lew
2024-05-17 8:07 ` Bryan O'Donoghue
2024-05-17 8:47 ` Bryan O'Donoghue
2024-05-16 22:58 ` [PATCH 4/7] hwspinlock: qcom: implement bust operation Chris Lew
2024-05-16 22:58 ` [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks Chris Lew
2024-05-19 17:36 ` Krzysztof Kozlowski
2024-05-21 4:08 ` Chris Lew [this message]
2024-05-21 7:36 ` Krzysztof Kozlowski
2024-05-21 19:17 ` Bjorn Andersson
2024-05-22 7:26 ` Krzysztof Kozlowski
2024-05-22 17:50 ` Bjorn Andersson
2024-05-23 6:15 ` Krzysztof Kozlowski
2024-05-24 19:23 ` Bjorn Andersson
2024-05-25 16:45 ` Krzysztof Kozlowski
2024-05-16 22:58 ` [PATCH 6/7] remoteproc: qcom_q6v5_pas: Add hwspinlock bust on stop Chris Lew
2024-05-17 7:19 ` Mukesh Ojha
2024-05-17 7:21 ` Mukesh Ojha
2024-05-17 17:25 ` Chris Lew
2024-05-17 9:08 ` Bryan O'Donoghue
2024-05-17 17:20 ` Chris Lew
2024-05-21 17:38 ` Konrad Dybcio
2024-05-21 21:08 ` Chris Lew
2024-05-16 22:58 ` [PATCH 7/7] arm64: dts: qcom: sm8650: Add hwlock to remoteproc Chris Lew
2024-05-22 7:27 ` Krzysztof Kozlowski
2024-05-22 17:51 ` Bjorn Andersson
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=a944418a-1699-44fa-bdfc-2e57129adea1@quicinc.com \
--to=quic_clew@quicinc.com \
--cc=andersson@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=boqun.feng@gmail.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=longman@redhat.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox