From: Bjorn Andersson <andersson@kernel.org>
To: Johan Hovold <johan@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Chris Lew <quic_clew@quicinc.com>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org,
Bjorn Andersson <quic_bjorande@quicinc.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org>
Subject: Re: [PATCH v2 2/2] soc: qcom: pmic_glink: Handle GLINK intent allocation rejections
Date: Thu, 24 Oct 2024 12:49:29 -0500 [thread overview]
Message-ID: <b7jydfdsyhn4xhrydsxmjayzvp3t3rwwrgnb45jzektbhotlmm@4czvpsdsjv4f> (raw)
In-Reply-To: <ZxnrnY0rMQRWmUtd@hovoldconsulting.com>
On Thu, Oct 24, 2024 at 08:39:25AM GMT, Johan Hovold wrote:
> On Wed, Oct 23, 2024 at 05:24:33PM +0000, Bjorn Andersson wrote:
> > Some versions of the pmic_glink firmware does not allow dynamic GLINK
> > intent allocations, attempting to send a message before the firmware has
> > allocated its receive buffers and announced these intent allocations
> > will fail.
>
> > Retry the send until intent buffers becomes available, or an actual
> > error occur.
>
> > Reported-by: Johan Hovold <johan@kernel.org>
> > Closes: https://lore.kernel.org/all/Zqet8iInnDhnxkT9@hovoldconsulting.com/#t
> > Cc: stable@vger.kernel.org # rpmsg: glink: Handle rejected intent request better
> > Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
> > Tested-by: Johan Hovold <johan+linaro@kernel.org>
> > Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>
> Thanks for the update. Still works as intended here.
>
Thanks for the confirmation.
> > int pmic_glink_send(struct pmic_glink_client *client, void *data, size_t len)
> > {
> > struct pmic_glink *pg = client->pg;
> > + bool timeout_reached = false;
> > + unsigned long start;
> > int ret;
> >
> > mutex_lock(&pg->state_lock);
> > - if (!pg->ept)
> > + if (!pg->ept) {
> > ret = -ECONNRESET;
> > - else
> > - ret = rpmsg_send(pg->ept, data, len);
> > + } else {
> > + start = jiffies;
> > + for (;;) {
> > + ret = rpmsg_send(pg->ept, data, len);
> > + if (ret != -EAGAIN)
> > + break;
> > +
> > + if (timeout_reached) {
> > + ret = -ETIMEDOUT;
> > + break;
> > + }
> > +
> > + usleep_range(1000, 5000);
>
> I ran some quick tests of this patch this morning (reproducing the issue
> five times), and with the above delay it seems a single resend is
> enough. Dropping the delay I once hit:
>
> [ 8.723479] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.723877] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.723921] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.723951] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.723981] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.724010] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
> [ 8.724046] qcom_pmic_glink pmic-glink: pmic_glink_send - resend
>
> which seems to suggest that a one millisecond sleep is sufficient for
> the currently observed issue.
>
> It would still mean up to 5k calls if you ever try to send a too large
> buffer or similar and spin here for five seconds however. Perhaps
> nothing to worry about at this point, but increasing the delay or
> lowering the timeout could be considered.
>
I did consider this as well, but this code-path is specific to
pmic-glink, so we shouldn't have any messages of size unexpected to the
other side...
If we do, then let's fix that. If I'm wrong in my assumptions, I'd be
happy to see this corrected, without my arbitrarily chosen timeout
values.
Thanks,
Bjorn
> > + timeout_reached = time_after(jiffies, start + PMIC_GLINK_SEND_TIMEOUT);
> > + }
> > + }
> > mutex_unlock(&pg->state_lock);
> >
> > return ret;
>
> Johan
next prev parent reply other threads:[~2024-10-24 17:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 17:24 [PATCH v2 0/2] soc: qcom: pmic_glink: Resolve failures to bring up pmic_glink Bjorn Andersson
2024-10-23 17:24 ` [PATCH v2 1/2] rpmsg: glink: Handle rejected intent request better Bjorn Andersson
2024-10-23 22:21 ` Chris Lew
2024-10-23 17:24 ` [PATCH v2 2/2] soc: qcom: pmic_glink: Handle GLINK intent allocation rejections Bjorn Andersson
2024-10-23 22:26 ` Chris Lew
2024-10-24 6:39 ` Johan Hovold
2024-10-24 17:49 ` Bjorn Andersson [this message]
2024-10-24 18:56 ` [PATCH v2 0/2] soc: qcom: pmic_glink: Resolve failures to bring up pmic_glink 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=b7jydfdsyhn4xhrydsxmjayzvp3t3rwwrgnb45jzektbhotlmm@4czvpsdsjv4f \
--to=andersson@kernel.org \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=johan+linaro@kernel.org \
--cc=johan@kernel.org \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=quic_bjorande@quicinc.com \
--cc=quic_clew@quicinc.com \
--cc=stable@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).