From: subramanian.mohan@intel.com
To: rcsekar@samsung.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: msp@baylibre.com, balbi@kernel.org, raymond.tan@intel.com,
jarkko.nikula@linux.intel.com, linux-can@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux@ew.tq-group.com, lst@pengutronix.de,
subramanian.mohan@intel.com, matthias.hahn@intel.com,
srinivasan.chinnadurai@intel.com
Subject: [PATCH 1/1] can: m_can: Control tx flow to avoid message stuck
Date: Wed, 8 Jan 2025 14:31:12 +0530 [thread overview]
Message-ID: <20250108090112.58412-1-subramanian.mohan@intel.com> (raw)
From: Subramanian Mohan <subramanian.mohan@intel.com>
The prolonged testing of passing can messages between
two Elkhartlake platforms resulted in message stuck
i.e Message did not receive at receiver side
Contolling TX i.e TEFN bit helped to resolve the message
stuck issue.
The current solution is enhanced/optimized from the below patch:
https://lore.kernel.org/lkml/20230623051124.64132-1-kumari.pallavi@intel.com/T/
Setup 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)Bus-Rate is 1 MBit/s
2)Busload during the test is about 40%
3)we initialize the CAN with following commands
4)ip link set can0 txqueuelen 100/1024/2048
5)ip link set can0 up type can bitrate 1000000
Python scripts are used send and receive the can messages
between the EHL systems.
Signed-off-by: Hahn Matthias <matthias.hahn@intel.com>
Signed-off-by: Subramanian Mohan <subramanian.mohan@intel.com>
---
drivers/net/can/m_can/m_can.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 97cd8bbf2e32..0a2c9a622842 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1220,7 +1220,7 @@ static void m_can_coalescing_update(struct m_can_classdev *cdev, u32 ir)
static int m_can_interrupt_handler(struct m_can_classdev *cdev)
{
struct net_device *dev = cdev->net;
- u32 ir = 0, ir_read;
+ u32 ir = 0, ir_read, new_interrupts;
int ret;
if (pm_runtime_suspended(cdev->dev))
@@ -1283,6 +1283,9 @@ static int m_can_interrupt_handler(struct m_can_classdev *cdev)
ret = m_can_echo_tx_event(dev);
if (ret != 0)
return ret;
+
+ new_interrupts = cdev->active_interrupts & ~(IR_TEFN);
+ m_can_interrupt_enable(cdev, new_interrupts);
}
}
@@ -1989,6 +1992,7 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
struct m_can_classdev *cdev = netdev_priv(dev);
unsigned int frame_len;
netdev_tx_t ret;
+ u32 new_interrupts;
if (can_dev_dropped_skb(dev, skb))
return NETDEV_TX_OK;
@@ -2008,8 +2012,11 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
if (cdev->is_peripheral)
ret = m_can_start_peripheral_xmit(cdev, skb);
- else
+ else {
+ new_interrupts = cdev->active_interrupts | IR_TEFN;
+ m_can_interrupt_enable(cdev, new_interrupts);
ret = m_can_tx_handler(cdev, skb);
+ }
if (ret != NETDEV_TX_OK)
netdev_completed_queue(dev, 1, frame_len);
--
2.35.3
next reply other threads:[~2025-01-08 9:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 9:01 subramanian.mohan [this message]
2025-01-09 15:43 ` [PATCH 1/1] can: m_can: Control tx flow to avoid message stuck Markus Schneider-Pargmann
[not found] ` <PH7PR11MB58625A0D029BB135A9F506C8F71F2@PH7PR11MB5862.namprd11.prod.outlook.com>
2025-01-15 13:04 ` Mohan, Subramanian
2025-01-15 15:21 ` Markus Schneider-Pargmann
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=20250108090112.58412-1-subramanian.mohan@intel.com \
--to=subramanian.mohan@intel.com \
--cc=balbi@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@ew.tq-group.com \
--cc=lst@pengutronix.de \
--cc=matthias.hahn@intel.com \
--cc=msp@baylibre.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raymond.tan@intel.com \
--cc=rcsekar@samsung.com \
--cc=srinivasan.chinnadurai@intel.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