From: kurt.van.dijck@eia.be (Kurt Van Dijck)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 09/13] can: pruss CAN driver.
Date: Fri, 11 Feb 2011 16:20:26 +0100 [thread overview]
Message-ID: <20110211152026.GC373@e-circ.dyndns.org> (raw)
In-Reply-To: <1297435892-28278-10-git-send-email-subhasish@mistralsolutions.com>
Hi,
I looked a bit at the TX path:
On Fri, Feb 11, 2011 at 08:21:28PM +0530, Subhasish Ghosh wrote:
> +static int omapl_pru_can_set_bittiming(struct net_device *ndev)
> +{
> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
> + struct can_bittiming *bt = &priv->can.bittiming;
> + long bit_error = 0;
> +
> + if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES) {
> + dev_warn(priv->dev, "WARN: Triple"
> + "sampling not set due to h/w limitations");
You should not have enabled CAN_CTRLMODE_3_SAMPLES in the first place?
> + }
> + if (pru_can_calc_timing(priv->dev, priv->can.clock.freq,
> + bt->bitrate) != 0)
> + return -EINVAL;
> + bit_error =
> + (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
> + bt->bitrate) * 1000) / bt->bitrate;
> + if (bit_error) {
> + bit_error =
> + (((priv->timer_freq / (priv->timer_freq / bt->bitrate)) -
> + bt->bitrate) * 1000000) / bt->bitrate;
> + printk(KERN_INFO "\nBitrate error %ld.%ld%%\n",
> + bit_error / 10000, bit_error % 1000);
> + } else
> + printk(KERN_INFO "\nBitrate error 0.0%%\n");
> +
> + return 0;
> +}
I wonder how much of this code is duplicated from drivers/net/can/dev.c ?
> +static netdev_tx_t omapl_pru_can_start_xmit(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
> + struct can_frame *cf = (struct can_frame *)skb->data;
> + int count;
> + u8 *data = cf->data;
> + u8 dlc = cf->can_dlc;
> + u8 *ptr8data = NULL;
> +
most drivers start with:
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
> + netif_stop_queue(ndev);
why would you stop when you just resumed the queue?
> + if (cf->can_id & CAN_EFF_FLAG) /* Extended frame format */
> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) =
> + (cf->can_id & CAN_EFF_MASK) | PRU_CANMID_IDE;
> + else /* Standard frame format */
> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) =
> + (cf->can_id & CAN_SFF_MASK) << 18;
> +
> + if (cf->can_id & CAN_RTR_FLAG) /* Remote transmission request */
> + *((u32 *) &priv->can_tx_hndl.strcanmailbox) |= CAN_RTR_FLAG;
> +
> + ptr8data = &priv->can_tx_hndl.strcanmailbox.u8data7 + (dlc - 1);
> + for (count = 0; count < (u8) dlc; count++) {
> + *ptr8data-- = *data++;
> + }
> + *((u32 *) &priv->can_tx_hndl.strcanmailbox.u16datalength) = (u32) dlc;
> +/*
> + * search for the next available mbx
> + * if the next mbx is busy, then try the next + 1
> + * do this until the head is reached.
> + * if still unable to tx, stop accepting any packets
> + * if able to tx and the head is reached, then reset next to tail, i.e mbx0
> + * if head is not reached, then just point to the next mbx
> + */
> + for (; priv->tx_next <= priv->tx_head; priv->tx_next++) {
> + priv->can_tx_hndl.ecanmailboxnumber =
> + (can_mailbox_number) priv->tx_next;
> + if (-1 == pru_can_write_data_to_mailbox(priv->dev,
> + &priv->can_tx_hndl)) {
> + if (priv->tx_next == priv->tx_head) {
> + priv->tx_next = priv->tx_tail;
> + if (!netif_queue_stopped(ndev))
If you get here, the queue is not stopped. This test is therefore useless.
> + netif_stop_queue(ndev); /* IF stalled */
> + dev_err(priv->dev,
> + "%s: no tx mbx available", __func__);
> + return NETDEV_TX_BUSY;
> + } else
> + continue;
> + } else {
> + /* set transmit request */
> + pru_can_tx(priv->dev, priv->tx_next, CAN_TX_PRU_1);
> + pru_can_tx_mode_set(priv->dev, false, ecanreceive);
> + pru_can_tx_mode_set(priv->dev, true, ecantransmit);
> + pru_can_start_abort_tx(priv->dev, PRU_CAN_START);
> + priv->tx_next++;
> + can_put_echo_skb(skb, ndev, 0);
> + break;
> + }
> + }
> + if (priv->tx_next > priv->tx_head) {
> + priv->tx_next = priv->tx_tail;
> + }
> + return NETDEV_TX_OK;
> +}
> +
> +
> +irqreturn_t omapl_tx_can_intr(int irq, void *dev_id)
> +{
> + struct net_device *ndev = dev_id;
> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
> + struct net_device_stats *stats = &ndev->stats;
> + u32 bit_set, mbxno;
> +
> + pru_can_get_intr_status(priv->dev, &priv->can_tx_hndl);
> + if ((PRU_CAN_ISR_BIT_CCI & priv->can_tx_hndl.u32interruptstatus)
> + || (PRU_CAN_ISR_BIT_SRDI & priv->can_tx_hndl.u32interruptstatus)) {
> + __can_debug("tx_int_status = 0x%X\n",
> + priv->can_tx_hndl.u32interruptstatus);
> + can_free_echo_skb(ndev, 0);
> + } else {
> + for (bit_set = 0; ((priv->can_tx_hndl.u32interruptstatus & 0xFF)
> + >> bit_set != 0); bit_set++)
> + ;
> + if (0 == bit_set) {
> + __can_err("%s: invalid mailbox number\n", __func__);
> + can_free_echo_skb(ndev, 0);
> + } else {
> + mbxno = bit_set - 1; /* mail box numbering starts from 0 */
> + if (PRU_CAN_ISR_BIT_ESI & priv->can_tx_hndl.
> + u32interruptstatus) {
> + /* read gsr and ack pru */
> + pru_can_get_global_status(priv->dev, &priv->can_tx_hndl);
> + omapl_pru_can_err(ndev,
> + priv->can_tx_hndl.
> + u32interruptstatus,
> + priv->can_tx_hndl.
> + u32globalstatus);
> + } else {
> + stats->tx_packets++;
> + /* stats->tx_bytes += dlc; */
> + /*can_get_echo_skb(ndev, 0);*/
> + }
> + }
> + }
> + if (netif_queue_stopped(ndev))
you can call netif_wake_queue(ndev) multiple times, so there is no need
for netif_queue_stopped()
> + netif_wake_queue(ndev);
> +
> + can_get_echo_skb(ndev, 0);
> + pru_can_tx_mode_set(priv->dev, true, ecanreceive);
> + return IRQ_HANDLED;
> +}
> +
> +static int omapl_pru_can_open(struct net_device *ndev)
> +{
> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
> + int err;
> +
> + /* register interrupt handler */
> + err = request_irq(priv->trx_irq, &omapl_rx_can_intr, IRQF_SHARED,
> + "pru_can_irq", ndev);
you're doing a lot of work _in_ the irq handler. Maybe threaded irq?
> +static int omapl_pru_can_close(struct net_device *ndev)
> +{
> + struct omapl_pru_can_priv *priv = netdev_priv(ndev);
> +
> + if (!netif_queue_stopped(ndev))
check is not needed.
> + netif_stop_queue(ndev);
> +
> + close_candev(ndev);
> +
> + free_irq(priv->trx_irq, ndev);
> + return 0;
> +}
> +
Regards,
Kurt
next prev parent reply other threads:[~2011-02-11 15:20 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-11 14:51 [PATCH v2 00/13] pruss mfd drivers Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 01/13] mfd: pruss mfd driver Subhasish Ghosh
2011-02-21 16:30 ` Samuel Ortiz
2011-02-22 5:43 ` Subhasish Ghosh
2011-02-22 10:31 ` Samuel Ortiz
2011-02-22 10:48 ` Wolfgang Grandegger
2011-02-22 11:33 ` Samuel Ortiz
2011-02-22 12:49 ` Subhasish Ghosh
2011-02-22 16:27 ` Wolfgang Grandegger
2011-02-23 12:25 ` Subhasish Ghosh
2011-02-23 13:09 ` Russell King - ARM Linux
2011-02-11 14:51 ` [PATCH v2 02/13] da850: pruss platform specific additions Subhasish Ghosh
2011-02-11 18:41 ` Sergei Shtylyov
2011-02-18 7:18 ` Subhasish Ghosh
2011-02-28 13:04 ` TK, Pratheesh Gangadhar
2011-03-01 6:59 ` Subhasish Ghosh
2011-03-03 11:12 ` TK, Pratheesh Gangadhar
2011-02-11 14:51 ` [PATCH v2 03/13] da850: pruss board " Subhasish Ghosh
2011-02-11 18:43 ` Sergei Shtylyov
2011-02-18 7:18 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 04/13] mfd: pruss CAN private data Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 05/13] da850: pruss CAN platform specific additions Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 06/13] da850: pruss CAN board " Subhasish Ghosh
2011-02-11 18:45 ` Sergei Shtylyov
2011-02-18 7:19 ` Subhasish Ghosh
2011-02-18 7:19 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 07/13] da850: pruss CAN platform specific changes for gpios Subhasish Ghosh
2011-02-11 18:47 ` Sergei Shtylyov
2011-02-18 7:20 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 08/13] da850: pruss CAN board " Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 09/13] can: pruss CAN driver Subhasish Ghosh
2011-02-11 15:06 ` Kurt Van Dijck
2011-02-14 4:54 ` Subhasish Ghosh
[not found] ` <4D58D854.5090503@grandegger.com>
2011-02-14 7:42 ` Kurt Van Dijck
2011-02-14 8:45 ` Subhasish Ghosh
[not found] ` <4D58F77B.9080005@pengutronix.de>
2011-02-14 13:15 ` Subhasish Ghosh
2011-02-11 15:20 ` Kurt Van Dijck [this message]
2011-02-18 7:07 ` Subhasish Ghosh
[not found] ` <4D5E2570.10108@grandegger.com>
2011-02-18 8:15 ` Subhasish Ghosh
2011-02-18 8:36 ` Marc Kleine-Budde
2011-02-18 9:09 ` Subhasish Ghosh
2011-02-18 15:07 ` Arnd Bergmann
2011-03-22 7:30 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 10/13] mfd: pruss SUART private data Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 11/13] da850: pruss SUART board specific additions Subhasish Ghosh
2011-02-11 15:26 ` Michael Williamson
2011-02-18 7:13 ` Subhasish Ghosh
2011-02-11 18:50 ` Sergei Shtylyov
2011-02-22 6:22 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 12/13] da850: pruss SUART platform " Subhasish Ghosh
2011-02-11 18:55 ` Sergei Shtylyov
2011-02-22 9:18 ` Subhasish Ghosh
2011-02-22 11:20 ` Sergei Shtylyov
2011-02-22 13:24 ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 13/13] tty: pruss SUART driver Subhasish Ghosh
2011-02-11 16:28 ` Alan Cox
2011-02-18 13:47 ` Subhasish Ghosh
2011-02-18 14:35 ` Alan Cox
2011-02-18 18:23 ` Thomas Gleixner
2011-02-18 18:51 ` Arnd Bergmann
2011-02-22 8:42 ` Subhasish Ghosh
2011-02-22 14:37 ` Greg KH
2011-02-23 5:30 ` Subhasish Ghosh
2011-02-23 18:20 ` Greg KH
2011-02-22 8:43 ` Subhasish Ghosh
2011-02-22 16:34 ` Arnd Bergmann
2011-02-24 10:31 ` Subhasish Ghosh
2011-02-22 10:26 ` Subhasish
2011-02-22 11:11 ` Alan Cox
2011-03-01 13:37 ` Subhasish Ghosh
2011-03-01 14:07 ` Alan Cox
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=20110211152026.GC373@e-circ.dyndns.org \
--to=kurt.van.dijck@eia.be \
--cc=linux-arm-kernel@lists.infradead.org \
/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).