[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB60840829B69A0FBBCF40B465872FA@SJ1PR11MB6084.namprd11.prod.outlook.com>
Date: Wed, 5 Jul 2023 08:58:13 +0000
From: Kumari Pallavi <kumari.pallavi@...el.com>
To: "rcsekar@...sung.com" <rcsekar@...sung.com>,
"wg@...ndegger.com" <wg@...ndegger.com>,
"mkl@...gutronix.de" <mkl@...gutronix.de>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>
CC: "Sangannavar, Mallikarjunappa"
<mallikarjunappa.sangannavar@...el.com>,
"Nikula, Jarkko" <jarkko.nikula@...el.com>,
"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Thokala, Srikanth" <srikanth.thokala@...el.com>
Subject: RE: [RESEND] [PATCH 1/1] can: m_can: Control tx and rx flow to avoid
communication stall
Hi,
> -----Original Message-----
> From: Kumari Pallavi <kumari.pallavi@...el.com>
> Sent: Friday, June 23, 2023 2:29 PM
> To: rcsekar@...sung.com; wg@...ndegger.com; mkl@...gutronix.de;
> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com
> Cc: Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@...el.com>;
> Nikula, Jarkko <jarkko.nikula@...el.com>; linux-can@...r.kernel.org;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Kumari Pallavi
> <kumari.pallavi@...el.com>; Thokala, Srikanth <srikanth.thokala@...el.com>
> Subject: [RESEND] [PATCH 1/1] can: m_can: Control tx and rx flow to avoid
> communication stall
>
> In bi-directional CAN transfer using M_CAN IP, with the frame gap being set to
> '0', it leads to Protocol error in Arbitration phase resulting in communication
> stall.
> Discussed with Bosch M_CAN IP team and the stall issue can only be overcome
> by controlling the tx and rx packets flow as done by the patch.
>
> Rx packets would also be serviced when there is a tx interrupt. The solution has
> been tested extensively for more than 10 days, and no issues has been observed.
>
> Setup that is used to reproduce the issue:
>
> +---------------------+ +----------------------+
> |Intel ElkhartLake | |Intel ElkhartLake |
> | +--------+ | | +--------+ |
> | |m_can 0 | |<=======>| |m_can 0 | |
> | +--------+ | | +--------+ |
> +---------------------+ +----------------------+
>
> Steps to be run on the two Elkhartlake HW:
>
> 1. ip link set can0 type can bitrate 1000000 2. ip link set can0 txqueuelen 2048 3.
> ip link set can0 up 4. cangen -g 0 can0 5. candump can0
>
> cangen -g 0 can0 & candump can0 commands are used for transmit and receive
> on both the m_can HW simultaneously where -g is the frame gap between two
> frames.
>
> Signed-off-by: Kumari Pallavi <kumari.pallavi@...el.com>
> Signed-off-by: Srikanth Thokala <srikanth.thokala@...el.com>
> ---
> drivers/net/can/m_can/m_can.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index a5003435802b..94aa0ba89202 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -1118,7 +1118,7 @@ static irqreturn_t m_can_isr(int irq, void *dev_id)
> /* New TX FIFO Element arrived */
> if (m_can_echo_tx_event(dev) != 0)
> goto out_fail;
> -
> + m_can_write(cdev, M_CAN_IE, IR_ALL_INT &
> ~(IR_TEFN));
> if (netif_queue_stopped(dev) &&
> !m_can_tx_fifo_full(cdev))
> netif_wake_queue(dev);
> @@ -1787,6 +1787,7 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff
> *skb,
> }
> } else {
> cdev->tx_skb = skb;
> + m_can_write(cdev, M_CAN_IE, IR_ALL_INT & (IR_TEFN));
> return m_can_tx_handler(cdev);
> }
>
Kindly review the patch and please let us know if any comments!
Thanks,
Pallavi
> --
> 2.17.1
Powered by blists - more mailing lists