Re: [PATCH] mailbox: imx: Fix TXDB_V2 sending
Jassi Brar <[email protected]> Thu, 22 May 2025 09:26:26 -0500
| Newsgroups | dev.linux.lists.mailbox,dev.linux.lists.imx,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CABb+yY0dqgPhe5_p+=cyRAbSwSL+qCZXV1G+QQ2kQh7Axh_7Tw@mail.gmail.com> |
On Thu, Apr 24, 2025 at 8:51=E2=80=AFPM Peng Fan (OSS) <[email protected]= m> wrote: > > From: Peng Fan <[email protected]> > > i.MX95 features several processing domains, Cortex-M7, Cortex-A55 > secure, Cortex-A55 non-secure. Each domain could communicate with > SCMI firmware with a dedicated MU. But the current NXP SCMI firmware > is not a RTOS, all processing logic codes are in interrupt context. > So if high priority Cortex-M7 is communicating with SCMI firmware and > requires a bit more time to handle the SCMI call, Linux MU TXDB_V2 > will be timeout with high possiblity in 1000us(the current value in > imx-mailbox.c). Per NXP SCMI firmware design, if timeout, there is > no recover logic, so SCMI agents should never timeout and always > wait until the check condition met. > > Based on the upper reason, enlarge the timeout value to 10ms which > is less chance to timeout, and retry if timeout really happends. > > Fixes: 5bfe4067d350 ("mailbox: imx: support channel type tx doorbell v2") > Signed-off-by: Peng Fan <[email protected]> > --- > drivers/mailbox/imx-mailbox.c | 21 +++++++++++++++------ > 1 file changed, 15 insertions(+), 6 deletions(-) > > diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.= c > index 6ef8338add0d..aef8d572a27c 100644 > --- a/drivers/mailbox/imx-mailbox.c > +++ b/drivers/mailbox/imx-mailbox.c > @@ -226,7 +226,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv= , > { > u32 *arg =3D data; > u32 val; > - int ret; > + int ret, count; > > switch (cp->type) { > case IMX_MU_TYPE_TX: > @@ -240,11 +240,20 @@ static int imx_mu_generic_tx(struct imx_mu_priv *pr= iv, > case IMX_MU_TYPE_TXDB_V2: > imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->= idx), > priv->dcfg->xCR[IMX_MU_GCR]); > - ret =3D readl_poll_timeout(priv->base + priv->dcfg->xCR[I= MX_MU_GCR], val, > - !(val & IMX_MU_xCR_GIRn(priv->dc= fg->type, cp->idx)), > - 0, 1000); > - if (ret) > - dev_warn_ratelimited(priv->dev, "channel type: %d= failure\n", cp->type); > + ret =3D -ETIMEDOUT; > + count =3D 0; > + while (ret) { Maybe while (ret && count < N) ... esp when you already increase the timeout from 1 to 10ms. cheers.