From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Jan Altenberg <jan@linutronix.de>
Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>,
bhupesh.sharma@st.com, wg@grandegger.com,
b.spranger@linutronix.de, netdev@vger.kernel.org
Subject: Re: can: c_can: TX delivery
Date: Thu, 24 Mar 2011 11:02:03 +0100 [thread overview]
Message-ID: <4D8B169B.60401@pengutronix.de> (raw)
In-Reply-To: <ff5ade24e148af2e46832e5a64444d05.squirrel@www2.linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]
On 03/23/2011 04:32 PM, Jan Altenberg wrote:
> Hi,
>
>> I split your 2 questions in 2 replies.
>
> Thanks :)
>
>> not sure if I made my point. Note that this will eliminate the need
>> for explicit wrap-around. It's done implicitely.
>
> Hmmm, I double-checked the datasheet, which gives the following statement:
> "The receive/transmit priority for the Message Objects is attached to
> the message number. Message Object 1 has the highest priority, while
> Message Object 32 has the lowest priority. If more than one
> transmission request is pending, they are serviced due to the priority
> of the corresponding Message Object."
>
> So, we shouldn't run into the scenario I described in my previous mail
ACK - the tx implementation is borrowed from the at91 driver. There we
have a prio field per mailbox (which is _not_ the CAN id), and the
mailbox number itself. If two mailboxes have the same prio the mailbox
with the lower number is send first. So we start with the highest prio
in mailbox 0, until the last mb, then decrease the prio and start with
mb 0. Special care is taken in prio wrap around and all mailboxes full.
Please recheck if this is implemented on the c_can driver correctly.
> and the existing implementation should be OK, right?! I'm quite sure
> I've seen a situation where msg_obj 17 "seemed" to be pending, while
> msg_obj 18 and 19 already have been transmitted. But in that case, I
> enabled ONESHOT for the can interface, which enables the DA mode
> (automatic
> retransmission is disabled). The errata sheet for c_can covers that
Oh...Oneshot means if TX fails (due to higher prio frame on the bus) it
won't be tx'ed again. IIRC in the at91 there's a bit signalling that TX
has been aborted due to oneshot. Maybe an interrupt can be enabled, too.
Hmm....the driver advertised it supports oneshot mode. Has this been
tested? If oneshot isn't working we should disable it in the driver
until it has been fixed.
> mode. There's a problem with "Concurrent transmission requests" and I'm
> quite sure my test-case hit that problem.
>
> I'm quite new to Bosch's c_can, so maybe Bhupesh can give some feedback
> (or beat me for causing some confusion ;-)).
cheers, 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: 262 bytes --]
next prev parent reply other threads:[~2011-03-24 10:02 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 ` 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 [this message]
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=4D8B169B.60401@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=b.spranger@linutronix.de \
--cc=bhupesh.sharma@st.com \
--cc=jan@linutronix.de \
--cc=kurt.van.dijck@eia.be \
--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).