From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Dong Aisheng <b29396@freescale.com>, linux-can@vger.kernel.org
Cc: mkl@pengutronix.de, wg@grandegger.com, varkabhadram@gmail.com,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/7] can: m_can: update to support CAN FD features
Date: Wed, 29 Oct 2014 20:21:28 +0100 [thread overview]
Message-ID: <54513E38.4020703@hartkopp.net> (raw)
In-Reply-To: <1414579527-31100-6-git-send-email-b29396@freescale.com>
Hello Dong,
thanks for your update to support CAN FD with the 3.0.x M_CAN IP core.
AFAIK from the last CAN in Automation (CiA) Plugfest which took place in
Nuremberg yesterday, there are two more IP cores on the way:
v3.0.1 / v3.0.2 (the current spec from the Bosch website)
v3.1.0 which will support per-frame CAN/CANFD switching in the tx path
(the FDF/(former)EDL bit and the BRS bit appear in the TX buffer element at
the bit position you know from reading the RX FIFO element)
v3.2.0 which will support the final(?) ISO specification with a bitstuffing
counter before the CRC in the frame on the wire.
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
Regarding the CAN FD support in this patch I have some remarks in the text ...
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> /* Rx Buffer Element */
> +/* R0 */
> #define RX_BUF_ESI BIT(31)
> #define RX_BUF_XTD BIT(30)
> #define RX_BUF_RTR BIT(29)
> +/* R1 */
> +#define RX_BUF_ANMF BIT(31)
> +#define RX_BUF_EDL BIT(21)
> +#define RX_BUF_BRS BIT(20)
>
> /* Tx Buffer Element */
> +/* R0 */
> #define TX_BUF_XTD BIT(30)
> #define TX_BUF_RTR BIT(29)
>
> @@ -327,11 +357,12 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
> m_can_write(priv, M_CAN_ILE, 0x0);
> }
>
> -static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
> +static void m_can_read_fifo(const struct net_device *dev, struct canfd_frame *cf,
> u32 rxfs)
> {
> struct m_can_priv *priv = netdev_priv(dev);
> u32 id, fgi;
> + int i;
>
> /* calculate the fifo get index for where to read data */
> fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
> @@ -341,15 +372,23 @@ static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
> else
> cf->can_id = (id >> 18) & CAN_SFF_MASK;
>
> + if (id & RX_BUF_ESI) {
> + cf->flags |= CANFD_ESI;
> + netdev_dbg(dev, "ESI Error\n");
> + }
> +
> if (id & RX_BUF_RTR) {
> cf->can_id |= CAN_RTR_FLAG;
When RX_BUF_EDL is set you should not check for RX_BUF_RTR as RTR is not
allowed for CAN FD.
> } else {
> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
> - cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
> - *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(0));
> - *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(1));
> + cf->len = can_dlc2len(get_canfd_dlc((id >> 16) & 0x0F));
> +
> + if (id & RX_BUF_BRS)
> + cf->flags |= CANFD_BRS;
> +
> + for (i = 0; i < cf->len; i += 4)
> + *(u32 *)(cf->data + i) =
> + m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i / 4));
> }
>
> /* acknowledge rx fifo 0 */
> @@ -361,7 +400,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> struct m_can_priv *priv = netdev_priv(dev);
> struct net_device_stats *stats = &dev->stats;
> struct sk_buff *skb;
> - struct can_frame *frame;
> + struct canfd_frame *frame;
> u32 pkts = 0;
> u32 rxfs;
>
> @@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> if (rxfs & RXFS_RFL)
> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
>
> - skb = alloc_can_skb(dev, &frame);
> + skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
> if (!skb) {
> stats->rx_dropped++;
> return pkts;
> @@ -384,7 +423,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> m_can_read_fifo(dev, frame, rxfs);
>
> stats->rx_packets++;
> - stats->rx_bytes += frame->can_dlc;
> + stats->rx_bytes += frame->len;
>
> netif_receive_skb(skb);
>
The rest of your entire patch set looks very good from my perspective.
Best regards,
Oliver
next prev parent reply other threads:[~2014-10-29 19:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 10:45 [PATCH 1/7] can: m_can: fix possible sleep in napi poll Dong Aisheng
2014-10-29 10:45 ` [PATCH 2/7] can: m_can: fix the incorrect error messages Dong Aisheng
2014-11-03 16:25 ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 3/7] can: m_can: add .ndo_change_mtu function Dong Aisheng
2014-11-03 16:49 ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 4/7] can: m_can: add a bit delay after setting CCCR_INIT bit Dong Aisheng
2014-11-03 16:52 ` Marc Kleine-Budde
2014-10-29 10:45 ` [PATCH 5/7] can: clear ctrlmode when close candev Dong Aisheng
2014-11-03 16:28 ` Marc Kleine-Budde
2014-11-03 18:25 ` Oliver Hartkopp
2014-11-03 20:47 ` Marc Kleine-Budde
2014-11-04 8:27 ` Dong Aisheng
2014-10-29 10:45 ` [PATCH 6/7] can: m_can: update to support CAN FD features Dong Aisheng
2014-10-29 19:21 ` Oliver Hartkopp [this message]
2014-10-30 2:42 ` Dong Aisheng
2014-10-30 20:32 ` Oliver Hartkopp
2014-11-04 7:12 ` Dong Aisheng
2014-10-29 10:45 ` [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes Dong Aisheng
2014-11-03 16:48 ` Marc Kleine-Budde
2014-11-04 8:25 ` Dong Aisheng
2014-11-04 9:22 ` Marc Kleine-Budde
2014-11-04 9:27 ` Dong Aisheng
2014-11-04 10:33 ` Marc Kleine-Budde
2014-11-04 13:13 ` Oliver Hartkopp
2014-11-04 13:28 ` Marc Kleine-Budde
2014-11-05 2:07 ` Dong Aisheng
2014-11-05 2:03 ` Dong Aisheng
2014-11-03 16:24 ` [PATCH 1/7] can: m_can: fix possible sleep in napi poll Marc Kleine-Budde
2014-11-03 17:02 ` Marc Kleine-Budde
2014-11-03 18:37 ` Oliver Hartkopp
2014-11-03 20:49 ` Marc Kleine-Budde
2014-11-03 21:12 ` Oliver Hartkopp
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=54513E38.4020703@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=b29396@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=varkabhadram@gmail.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).