From: Wolfgang Grandegger <wg@grandegger•com>
To: Jan Altenberg <jan@linutronix•de>
Cc: Kurt Van Dijck <kurt.van.dijck@eia•be>,
bhupesh.sharma@st•com, b.spranger@linutronix•de,
netdev@vger•kernel.org
Subject: Re: can: c_can: TX echo
Date: Wed, 23 Mar 2011 15:25:59 +0100 [thread overview]
Message-ID: <4D8A02F7.7050607@grandegger.com> (raw)
In-Reply-To: <b7a5102e35a2afd04327d7b42da4e988.squirrel@www2.linutronix.de>
Hi Jan,
On 03/23/2011 02:54 PM, Jan Altenberg wrote:
> Hi,
>
>>> So, we first invalidate the message object and afterwards we read
>>> the DLC value from the msg_cntrl (which is 0 after invalidating the
>>> message object) to account the TX bytes. So tx_bytes will always be
>>> 0. The fix should be easy, I think, we can just move
>>> c_can_inval_msg_object to the end of that loop.
This means that "ifconfig" will report *0* TX Bytes!?
>> IMO, it looks necessary to call c_can_inval_msg_object inside the if
>> (), after it has been transmitted. Otherwise, if for some other (TX)
>> reason you get in this loop, you may clear a pending transmission?
>> Again, I haven't read this one's datasheet. I was familiar with its
>> predecessor.
>
> I tried to check, but the datasheet is a bit unclear regarding that
> point ;-) My interpretation is, that c_can_inval_msg_object()
> shouldn't affect the txrqst bit, but nevertheless calling it inside
> the if() statement would make the code more readable.
>
> I can prepare a patch, but I'd like to wait for Wolfgang's / Bupesh's
> feedback.
I'm following the discussion and as I'm not familiar with that chip, I'm
waiting for Bupesh's answer as well... before I start digging. You can
also have a look to the pch_can driver, which is C_CAN based as well.
Wolfgang.
next prev parent reply other threads:[~2011-03-23 14:23 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 [this message]
2011-03-23 14:52 ` Jan Altenberg
2011-03-23 8:53 ` can: c_can: TX delivery Kurt Van Dijck
2011-03-23 15:32 ` 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=4D8A02F7.7050607@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=b.spranger@linutronix$(echo .)de \
--cc=bhupesh.sharma@st$(echo .)com \
--cc=jan@linutronix$(echo .)de \
--cc=kurt.van.dijck@eia$(echo .)be \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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