2021-03-04 07:22:44

by Dario Binacchi

[permalink] [raw]
Subject: [PATCH v4 0/6] can: c_can: add support to 64 message objects


The D_CAN controller supports up to 128 messages. Until now the driver
only managed 32 messages although Sitara processors and DRA7 SOC can
handle 64.

The series was tested on a beaglebone board.

Note:
I have not changed the type of tx_field (belonging to the c_can_priv
structure) to atomic64_t because I think the atomic_t type has size
of at least 32 bits on x86 and arm, which is enough to handle 64
messages.
http://marc.info/?l=linux-can&m=139746476821294&w=2 reports the results
of tests performed just on x86 and arm architectures.

Changes in v4:
- Restore IF_RX interface.
- Add a comment to clarify why IF_RX interface is used instead of IF_TX.
- Use GENMASK() for setting msg_obj_rx_mask.
- Use BIT() for setting single bits and GENMASK() for setting masks.

Changes in v3:
- Use unsigned int instead of int as type of the msg_obj_* fields
in the c_can_priv structure.
- Replace (u64)1 with 1UL in msg_obj_rx_mask setting.
- Use unsigned int instead of int as type of the msg_obj_num field
in c_can_driver_data and c_can_pci_data structures.

Changes in v2:
- Fix compiling error reported by kernel test robot.
- Add Reported-by tag.
- Pass larger size to alloc_candev() routine to avoid an additional
memory allocation/deallocation.
- Add message objects number to PCI driver data.

Dario Binacchi (6):
can: c_can: remove unused code
can: c_can: fix indentation
can: c_can: add a comment about IF_RX interface's use
can: c_can: use 32-bit write to set arbitration register
can: c_can: prepare to up the message objects number
can: c_can: add support to 64 message objects

drivers/net/can/c_can/c_can.c | 90 ++++++++++++++++----------
drivers/net/can/c_can/c_can.h | 32 ++++-----
drivers/net/can/c_can/c_can_pci.c | 6 +-
drivers/net/can/c_can/c_can_platform.c | 6 +-
4 files changed, 78 insertions(+), 56 deletions(-)

--
2.17.1


2021-03-04 07:22:52

by Dario Binacchi

[permalink] [raw]
Subject: [PATCH v4 2/6] can: c_can: fix indentation

Commit 524369e2391f ("can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig option")
left behind wrong indentation, fix it.

Signed-off-by: Dario Binacchi <[email protected]>
---

(no changes since v1)

drivers/net/can/c_can/c_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index a962ceefd44a..dbcc1c1c92d6 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -786,7 +786,7 @@ static u32 c_can_adjust_pending(u32 pend)
static inline void c_can_rx_object_get(struct net_device *dev,
struct c_can_priv *priv, u32 obj)
{
- c_can_object_get(dev, IF_RX, obj, priv->comm_rcv_high);
+ c_can_object_get(dev, IF_RX, obj, priv->comm_rcv_high);
}

static inline void c_can_rx_finalize(struct net_device *dev,
--
2.17.1

2021-03-04 07:22:59

by Dario Binacchi

[permalink] [raw]
Subject: [PATCH v4 3/6] can: c_can: add a comment about IF_RX interface's use

After reading the commit 640916db2bf7 ("can: c_can: Make it SMP safe")
it may sound strange to see the IF_RX interface used by the
can_inval_tx_object function. A comment was added to avoid any
misunderstanding.

Signed-off-by: Dario Binacchi <[email protected]>

---

Changes in v4:
- Restore IF_RX interface.
- Add a comment to clarify why IF_RX interface is used instead of IF_TX.

drivers/net/can/c_can/c_can.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index dbcc1c1c92d6..6c6d0d0ff7b8 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -732,6 +732,12 @@ static void c_can_do_tx(struct net_device *dev)
idx--;
pend &= ~(1 << idx);
obj = idx + C_CAN_MSG_OBJ_TX_FIRST;
+
+ /*
+ * We use IF_RX interface instead of IF_TX because we are
+ * called from c_can_poll(), which runs inside NAPI. We are
+ * not trasmitting.
+ */
c_can_inval_tx_object(dev, IF_RX, obj);
can_get_echo_skb(dev, idx, NULL);
bytes += priv->dlc[idx];
--
2.17.1

2021-03-04 07:23:08

by Dario Binacchi

[permalink] [raw]
Subject: [PATCH v4 4/6] can: c_can: use 32-bit write to set arbitration register

The arbitration register is already set up with 32-bit writes in the
other parts of the code except for this point.

Signed-off-by: Dario Binacchi <[email protected]>
---

(no changes since v1)

drivers/net/can/c_can/c_can.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 6c6d0d0ff7b8..77b9aee56154 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -297,8 +297,7 @@ static void c_can_inval_msg_object(struct net_device *dev, int iface, int obj)
{
struct c_can_priv *priv = netdev_priv(dev);

- priv->write_reg(priv, C_CAN_IFACE(ARB1_REG, iface), 0);
- priv->write_reg(priv, C_CAN_IFACE(ARB2_REG, iface), 0);
+ priv->write_reg32(priv, C_CAN_IFACE(ARB1_REG, iface), 0);
c_can_inval_tx_object(dev, iface, obj);
}

--
2.17.1

2021-03-04 17:51:50

by Marc Kleine-Budde

[permalink] [raw]
Subject: Re: [PATCH v4 0/6] can: c_can: add support to 64 message objects

On 02.03.2021 22:54:29, Dario Binacchi wrote:
>
> The D_CAN controller supports up to 128 messages. Until now the driver
> only managed 32 messages although Sitara processors and DRA7 SOC can
> handle 64.
>
> The series was tested on a beaglebone board.
>
> Note:
> I have not changed the type of tx_field (belonging to the c_can_priv
> structure) to atomic64_t because I think the atomic_t type has size
> of at least 32 bits on x86 and arm, which is enough to handle 64
> messages.
> http://marc.info/?l=linux-can&m=139746476821294&w=2 reports the results
> of tests performed just on x86 and arm architectures.

Applied to linux-can-next/testing.

I've added some cleanup patches to the series. I'll send it around soon,
please test.

regards,
Marc

--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Attachments:
(No filename) (1.02 kB)
signature.asc (499.00 B)
Download all attachments