From: Kurt Van Dijck <kurt.van.dijck@eia.be>
To: Jan Altenberg <jan@linutronix.de>
Cc: bhupesh.sharma@st.com, wg@grandegger.com,
b.spranger@linutronix.de, netdev@vger.kernel.org
Subject: Re: can: c_can: TX delivery
Date: Wed, 23 Mar 2011 09:53:40 +0100 [thread overview]
Message-ID: <20110323085340.GC346@e-circ.dyndns.org> (raw)
In-Reply-To: <16a340801622a96218c76dbbabc7a23f.squirrel@www.linutronix.de>
Jan,
I split your 2 questions in 2 replies.
On Tue, Mar 22, 2011 at 04:59:23PM +0100, Jan Altenberg wrote:
> Hi all,
>
> The second problem is related to tx_next, which should hold the number of
> the oldest CAN frame, which was not on the line:
>
> for (/* nix */; (priv->tx_next - priv->tx_echo) > 0; priv->tx_echo++) {
> msg_obj_no = get_tx_echo_msg_obj(priv);
> c_can_inval_msg_object(dev, 0, msg_obj_no);
> val = c_can_read_reg32(priv, &priv->regs->txrqst1);
> if (!(val & (1 << msg_obj_no))) {
> can_get_echo_skb(dev,
> msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
> stats->tx_bytes += priv->read_reg(priv,
> &priv->regs->ifregs[0].msg_cntrl)
> & IF_MCONT_DLC_MASK;
> stats->tx_packets++;
> }
> }
>
> But tx_echo is incremented unconditionally and we don't actually track the
> number of the oldest unsent frame.
> Let's assume the following scenario: We bring up can0 and send 3
> frames: TX object: 0, 1, 2; 1 and 2 make it on the line, but 0 is
> still pending. If we go through the above loop in that situation, we will
> skip message object 0, because the txrqst bit is still set. We will
> account message object 1 and 2. That's correct, but afterwards tx_echo is
> set to 2, BUT the oldest message which is pending is 0. Am I right or did
> I get something wrong?
> The operation of c_can_do_tx() is described as follows: "We iterate from
> priv->tx_echo to priv->tx_next and check if the packet has been
> transmitted, echo it back to the CAN framework. If we discover a not yet
> transmitted package, stop looking for more." The actual
> implementation doesn't seem to stop if we discover a not yet
> transmitted package. But I'm not sure if just stopping might be a
> good idea, because in that case, the echo skb for already transmitted
> messages might be delayed by not yet transmitted messages.
It is better to deliver the echo's in the order they were delivered
on CAN.
For that, we can replace the tx_next/tx_echo pair with a single tx_bitmask.
In the tx_bitmask, we could set a bit when the TX is queued, and test for
those bits in the tx interrupt.
When tx is done, clear the bit in tx_bitmask & stuff.
16 tx objects fit inside a single int.
c_can_start_xmit would look a bit different. I think of something like this:
/* find free object */
for (j = 0; j < TX_MAX; ++j) {
if (!(priv->tx_bitmask & (1 << j)))
break;
}
if (j >= TX_MAX)
/* no free objects */
return NETDEV_TX_BUSY;
c_can_write_...(j, ...)
can_put_echo_skb(, j, ...)
priv->tx_bitmask |= (1 << j);
return NETDEV_TX_OK;
not sure if I made my point.
Note that this will eliminate the need for explicit wrap-around. It's
done implicitely.
>
> Cheers,
> Jan
>
Regards,
Kurt
next prev parent reply other threads:[~2011-03-23 8:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-22 15:59 can: c_can: TX handling Jan Altenberg
2011-03-23 8:51 ` can: c_can: TX echo Kurt Van Dijck
2011-03-23 13:54 ` Jan Altenberg
2011-03-23 14:25 ` Wolfgang Grandegger
2011-03-23 14:52 ` Jan Altenberg
2011-03-23 8:53 ` Kurt Van Dijck [this message]
2011-03-23 15:32 ` can: c_can: TX delivery Jan Altenberg
2011-03-23 15:49 ` Kurt Van Dijck
2011-03-24 10:02 ` Marc Kleine-Budde
2011-03-24 4:18 ` c_can: TX handling Bhupesh SHARMA
2011-03-24 10:56 ` Jan Altenberg
2011-03-24 5:43 ` Bhupesh SHARMA
2011-03-24 10:38 ` [PATCH] can: c_can: Fix tx_bytes accounting Jan Altenberg
2011-03-24 10:00 ` Wolfgang Grandegger
2011-03-24 11:26 ` [PATCH resend] " Jan Altenberg
2011-03-24 10:49 ` Kurt Van Dijck
[not found] ` <20110324104925.GB339-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
2011-03-24 11:49 ` Wolfgang Grandegger
[not found] ` <4D8B2FAF.5040000-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-03-28 1:24 ` David Miller
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=20110323085340.GC346@e-circ.dyndns.org \
--to=kurt.van.dijck@eia.be \
--cc=b.spranger@linutronix.de \
--cc=bhupesh.sharma@st.com \
--cc=jan@linutronix.de \
--cc=netdev@vger.kernel.org \
--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).