devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Andreas Larsson <andreas@gaisler.com>
Cc: linux-can@vger.kernel.org, software@gaisler.com,
	Wolfgang Grandegger <wg@grandegger.com>,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v8] can: grcan: Add device driver for GRCAN and GRHCAN cores
Date: Wed, 14 Nov 2012 09:43:13 +0100	[thread overview]
Message-ID: <50A359A1.30700@pengutronix.de> (raw)
In-Reply-To: <50A34D49.2070908@gaisler.com>

[-- Attachment #1: Type: text/plain, Size: 5547 bytes --]

On 11/14/2012 08:50 AM, Andreas Larsson wrote:
> On 11/13/2012 10:15 PM, Marc Kleine-Budde wrote:
> 
> [...]
> 
>> On 11/12/2012 03:57 PM, Andreas Larsson wrote:
>>> >+    bpr = 0; /* Note bpr and brp are different concepts */
>>> >+    rsj = bt->sjw;
>>> >+    ps1 = (bt->prop_seg + bt->phase_seg1) - 1; /* tseg1 - 1 */
>>> >+    ps2 = bt->phase_seg2;
>>> >+    scaler = (bt->brp - 1);
>>> >+    timing |= (bpr << GRCAN_CONF_BPR_BIT) & GRCAN_CONF_BPR;
>>> >+    timing |= (rsj << GRCAN_CONF_RSJ_BIT) & GRCAN_CONF_RSJ;
>>> >+    timing |= (ps1 << GRCAN_CONF_PS1_BIT) & GRCAN_CONF_PS1;
>>> >+    timing |= (ps2 << GRCAN_CONF_PS2_BIT) & GRCAN_CONF_PS2;
>>> >+    timing |= (scaler << GRCAN_CONF_SCALER_BIT) & GRCAN_CONF_SCALER;
>>> >+
>>> >+    netdev_info(dev, "setting timing=0x%x\n", timing);
>> what about moving the sanity check before putting together the "timing"
>> variable and doing the netdev_info()?
> 
> The idea was for the user to have the full context of the problem when
> getting the error (e.g., when using the bitrate method to set the timing
> parameters, the calculated parameters are not otherwise known to the
> user). But I can do that with a separate netdev_dbg and move the sanity
> check as suggested.

I'm worried about the first stating "setting timing", but then not
writing it to the register.

> 
>>> >+    if (!(ps1 > ps2)) {
>>> >+        netdev_err(dev, "PS1 > PS2 must hold: PS1=%d, PS2=%d\n",
>>> >+               ps1, ps2);
>>> >+        return -EINVAL;
>>> >+    }
>>> >+    if (!(ps2 >= rsj)) {
>>> >+        netdev_err(dev, "PS2 >= RSJ must hold: PS2=%d, RSJ=%d\n",
>>> >+               ps2, rsj);
>>> >+        return -EINVAL;
>>> >+    }
>>> >+
>>> >+    grcan_write_bits(&regs->conf, timing, GRCAN_CONF_TIMING);
>>> >+    return 0;
>>> >+}
> 
> [...]
> 
>>> >+static int grcan_poll(struct napi_struct *napi, int rx_budget)
>>> >+{
>>> >+    struct grcan_priv *priv = container_of(napi, struct grcan_priv,
>>> napi);
>>> >+    struct net_device *dev = priv->dev;
>>> >+    struct grcan_registers __iomem *regs = priv->regs;
>>> >+    int rx_work_done;
>>> >+    unsigned long flags;
>>> >+
>>> >+    /* Receive according to given budget */
>>> >+    rx_work_done = grcan_receive(dev, rx_budget);
>>> >+
>>> >+    /* Catch up echo skb according to separate budget to get the
>>> benefits of
>>> >+     * napi for tx as well. The given rx_budget might not be
>>> appropriate for
>>> >+     * the tx side.
>>> >+     */
>>> >+    grcan_transmit_catch_up(dev, GRCAN_TX_BUDGET);
>>> >+
>>> >+    spin_lock_irqsave(&priv->lock, flags);
>>> >+
>>> >+    if (grcan_poll_all_done(dev)) {
>> Just make it:
>>     if (work_done < budget) {
>>         napi_complete();
>>         enable_interrupts();
>>     }
>>
>> If there are CAN frames pending, an interrupt will kick in and
>> reschedule the NAPI.
> 
> Sure, I can do that for the first check (and add back checking
> tx_work_done as well). That misses to call napi_complete and start

Hmmm...Either move tx-complete handling to the interrupt handler, or
just use a budget big enough for rx and tx-complete.

> interrupts in the case in which handling of frames are complete
> work_done == budget though. But on the other hand, then grcan_poll will
> be triggered once again and then detect that nothing is to be done if
> that is still the case.
> 
> However, the problem with skipping the check after turning on interrupts
> is that more frames can have arrived and/or have been sent after
> calculating work_done and before turning on interrupts. For those
> frames, unless I have misunderstood something, interrupts will not be
> raised and they can get stuck until (if ever) later frames once again
> trigger rescheduling of napi.

No, if correctly used, NAPI is race free and no events will be lost:

Handle incoming events (rx or tx-complete) until:
a) number of handled events == budget
or
b) no more events pending.

	while (work_done < budget && interrupts_pending()) {
		work_done += handle_rx(budget - work_done);
		work_done += handle_tx(budget - work_done);
	}

Then, if you have handled less events then budget:
1) call napi_complete()
then
2) enable interrupts.

	if (work_done < budget) {
		napi_complete();
		enable_interrupts();
	}

Then, return number of handled events:

	return work_done;

> 
>>> >+        bool complete = true;
>>> >+
>>> >+        if (!priv->closing) {
>>> >+            /* Enable tx and rx interrupts again */
>>> >+            grcan_set_bits(&regs->imr, GRCAN_IRQ_TX | GRCAN_IRQ_RX);
>>> >+
>>> >+            /* If more work arrived between detecting completion and
>>> >+             * turning on interrupts, we need to keep napi running
>>> >+             */
>>> >+            if (!grcan_poll_all_done(dev)) {
>>> >+                complete = false;
>>> >+                grcan_clear_bits(&regs->imr,
>>> >+                         GRCAN_IRQ_TX | GRCAN_IRQ_RX);
>>> >+            }
>>> >+        }
>>> >+        if (complete)
>>> >+            napi_complete(napi);
>>> >+    }
>>> >+
>>> >+    spin_unlock_irqrestore(&priv->lock, flags);
>>> >+
>>> >+    return rx_work_done;
>>> >+}

Marc

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2012-11-14  8:43 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5076999F.6070302@pengutronix.de>
2012-10-23  9:57 ` [PATCH v2] can: grcan: Add device driver for GRCAN and GRHCAN cores Andreas Larsson
2012-10-23 16:26   ` Wolfgang Grandegger
2012-10-24 13:31     ` Andreas Larsson
2012-10-30  9:06       ` [PATCH v3] " Andreas Larsson
2012-10-30 10:07         ` Wolfgang Grandegger
2012-10-30 16:24           ` Andreas Larsson
2012-10-31 12:51             ` Wolfgang Grandegger
2012-10-31 16:33               ` Andreas Larsson
2012-10-31 16:39                 ` [PATCH v4] " Andreas Larsson
2012-10-31 20:21                 ` [PATCH v3] " Wolfgang Grandegger
2012-11-01 16:08                   ` Andreas Larsson
2012-11-02 14:23                     ` [PATCH v5] " Andreas Larsson
2012-11-05  9:28                     ` [PATCH v3] " Wolfgang Grandegger
2012-11-07  7:32                       ` Andreas Larsson
2012-11-07 11:15                         ` Wolfgang Grandegger
2012-11-07 12:55                           ` Andreas Larsson
2012-11-07 15:20                             ` [PATCH v6] " Andreas Larsson
2012-11-08  8:29                               ` Wolfgang Grandegger
2012-11-08  9:27                                 ` Marc Kleine-Budde
2012-11-08 10:37                                   ` Andreas Larsson
     [not found]                                   ` <509B7B1E.5040509-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-11-08 13:10                                     ` [PATCH v7] " Andreas Larsson
2012-11-09  0:01                                       ` Marc Kleine-Budde
2012-11-12 14:57                                         ` [PATCH v8] " Andreas Larsson
2012-11-13 21:15                                           ` Marc Kleine-Budde
2012-11-14  7:50                                             ` Andreas Larsson
2012-11-14  8:43                                               ` Marc Kleine-Budde [this message]
2012-11-14 11:02                                                 ` Andreas Larsson
2012-11-14 11:22                                                   ` Marc Kleine-Budde
2012-11-14 15:07                                                     ` Andreas Larsson
2012-11-14 15:12                                                       ` Marc Kleine-Budde
2012-11-15  7:47                                                         ` [PATCH v9] " Andreas Larsson
2012-11-15 20:32                                                           ` Marc Kleine-Budde
2012-11-16  6:17                                                             ` Andreas Larsson
2012-11-08 10:33                                 ` [PATCH v6] " Andreas Larsson
2012-10-30  9:29       ` [PATCH v2] " Wolfgang Grandegger

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=50A359A1.30700@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=andreas@gaisler.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linux-can@vger.kernel.org \
    --cc=software@gaisler.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).