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(®s->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(®s->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(®s->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 --]
next prev parent 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).