From: <Thomas.Kopp@microchip.com>
To: <mkl@pengutronix.de>, <marex@denx.de>
Cc: <linux-can@vger.kernel.org>, <fedor.ross@ifm.com>,
<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<lgirdwood@gmail.com>, <mani@kernel.org>, <broonie@kernel.org>,
<pabeni@redhat.com>, <wg@grandegger.com>
Subject: RE: [PATCH] can: mcp251xfd: Increase poll timeout
Date: Fri, 5 May 2023 07:07:03 +0000 [thread overview]
Message-ID: <BL3PR11MB64846C83ACD04E9330B0FE66FB729@BL3PR11MB6484.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230505-kilt-exclusion-fd2a2423deb1-mkl@pengutronix.de>
> The datasheet "MCP25xxFD Family Reference Manual" says it needs an idle
> bus.
Technically what's needed is an idle condition on the bus as specified in the ISO. i.e. 11 consecutive sampled recessive bits after a full frame (if one is currently in transmission).
> > This seems to be necessary when configuring low
> > bit rates like 10 Kbit/s for example. Otherwise during polling for
> > the CAN controller to enter 'Normal CAN 2.0 mode' the timeout limit
> > is exceeded and the configuration fails with:
> >
> > $ ip link set dev can1 up type can bitrate 10000
> > [ 731.911072] mcp251xfd spi2.1 can1: Controller failed to enter mode CAN
> 2.0 Mode (6) and stays in Configuration Mode (4) (con=0x068b0760,
> osc=0x00000468).
> > [ 731.927192] mcp251xfd spi2.1 can1: CRC read error at address 0x0e0c
> (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> > [ 731.938101] A link change request failed with some changes committed
> already. Interface can1 may have been left with an inconsistent configuration,
> please check.
> > RTNETLINK answers: Connection timed out
> >
> > Fixes: 55e5b97f003e8 ("can: mcp25xxfd: add driver for Microchip
> MCP25xxFD SPI CAN")
> > Signed-off-by: Fedor Ross <fedor.ross@ifm.com>
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > ---
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>
> > Cc: Liam Girdwood <lgirdwood@gmail.com>
> > Cc: Manivannan Sadhasivam <mani@kernel.org>
> > Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> > Cc: Marek Vasut <marex@denx.de>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Paolo Abeni <pabeni@redhat.com>
> > Cc: Thomas Kopp <thomas.kopp@microchip.com>
> > Cc: Wolfgang Grandegger <wg@grandegger.com>
> > Cc: linux-can@vger.kernel.org
> > ---
> > drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> > index 68df6d4641b5c..9908843798cef 100644
> > --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> > +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> > @@ -227,6 +227,7 @@ static int
> > __mcp251xfd_chip_set_mode(const struct mcp251xfd_priv *priv,
> > const u8 mode_req, bool nowait)
> > {
> > + const struct can_bittiming *bt = &priv->can.bittiming;
> > u32 con = 0, con_reqop, osc = 0;
> > u8 mode;
> > int err;
> > @@ -251,7 +252,8 @@ __mcp251xfd_chip_set_mode(const struct
> mcp251xfd_priv *priv,
> >
> FIELD_GET(MCP251XFD_REG_CON_OPMOD_MASK,
> > con) == mode_req,
> > MCP251XFD_POLL_SLEEP_US,
> > - MCP251XFD_POLL_TIMEOUT_US);
> > + max(MCP251XFD_POLL_TIMEOUT_US,
> > + 576 * USEC_PER_SEC / bt->bitrate));
>
> Let's use CANFD_FRAME_LEN_MAX * BITS_PER_BYTE instead of 576. I can fix
> this while applying.
>
So, I'd suggest CANFD_FRAME_LEN_MAX * BITS_PER_BYTE + 11 + stuffbits, as far as I can tell the CANFD_FRAME_LEN_MAX ignores stuffbits, so as an overapproximation something like (CANFD_FRAME_LEN_MAX * BITS_PER_BYTE) * 1.2 + 11. It's unlikely that it will actually be necessary but it makes it clear where the numbers are coming from.
Best Regards,
Thomas
next prev parent reply other threads:[~2023-05-05 7:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 19:50 [PATCH] can: mcp251xfd: Increase poll timeout Marek Vasut
2023-05-05 6:50 ` Marc Kleine-Budde
2023-05-05 7:07 ` Thomas.Kopp [this message]
2023-05-05 7:58 ` Marc Kleine-Budde
2023-05-05 8:21 ` Thomas.Kopp
2023-05-05 8:39 ` Marc Kleine-Budde
2023-05-10 6:26 ` Thomas.Kopp
2023-05-10 7:50 ` Vincent Mailhol
2023-05-10 9:17 ` Thomas.Kopp
2023-05-10 10:02 ` Vincent Mailhol
2023-05-10 10:39 ` Thomas.Kopp
2023-05-10 11:19 ` Vincent Mailhol
2023-05-17 7:15 ` Marc Kleine-Budde
2023-06-11 12:15 ` Marek Vasut
2023-06-14 18:53 HMS Incident Management
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=BL3PR11MB64846C83ACD04E9330B0FE66FB729@BL3PR11MB6484.namprd11.prod.outlook.com \
--to=thomas.kopp@microchip.com \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fedor.ross@ifm.com \
--cc=kuba@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=mani@kernel.org \
--cc=marex@denx.de \
--cc=mkl@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=wg@grandegger.com \
/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 NNTP newsgroup(s).