From: Alexander Stein <alexander.stein@systec-electronic.com>
To: David Jander <david@protonic.nl>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
Wolfgang Grandegger <wg@grandegger.com>,
linux-can@vger.kernel.org
Subject: Re: [PATCH v5] can: flexcan: Re-write receive path to use MB queue instead of FIFO
Date: Wed, 01 Oct 2014 11:19:54 +0200 [thread overview]
Message-ID: <5856354.jaFqUxgnZF@ws-stein> (raw)
In-Reply-To: <20141001110741.0e8e5ffb@archvile>
Hello David,
On Wednesday 01 October 2014 11:07:41, David Jander wrote:
> On Wed, 01 Oct 2014 10:29:41 +0200
> Alexander Stein <alexander.stein@systec-electronic.com> wrote:
>
> > On Wednesday 01 October 2014 09:15:46, Marc Kleine-Budde wrote:
> > > On 10/01/2014 09:11 AM, Alexander Stein wrote:
> > > > BTW: You posted a patch for at91_can in June (Din't get opportunity
> > > > to try it yet), where you use a kfifo to accomplish the same, why not
> > > > here?
> > >
> > > The cyclic buffer approach is okay, from my point of view.
> >
> > I'M just wondering why 2 different approaches have been chosen.
>
> Good question.... I did the at91_can modification a long time ago, and the
> initial approach was more or less guided by the current architecture of the
> at91_can driver. I also probably got better ideas when doing something very
> similar for the second time (flexcan).
> Also, I can imagine that there are more CAN drivers that have similar
> problems, and maybe we should think about a solution in the SocketCAN
> framework itself instead.
Sounds reasonable too. If someone ever wants to support flexcan on coldfire (m68k) there is only a single message box (+ a shift register), there you will need this feature for sure :)
But I'm still curious which approach is better: Implement an own cyclic buffer or use kfifo (which might be a cyclic buffer itself, dunno)?
> Talking about at91_can... I have posted that patch twice already and had
> no reaction so far. Unfortunately now I don't have the hardware anymore, so I
> doubt I can pick this up again, let alone re-write that patch, unless someone
> is willing to help with testing...
It is on my TODO, but did not get chance to test it yet. There is the statement that a proprietary driver here is better that it doesn't drop any frames under heavy load while socketcan one does. So it might actually improve the situation.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
next prev parent reply other threads:[~2014-10-01 9:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 12:52 [PATCH v5] can: flexcan: Re-write receive path to use MB queue instead of FIFO David Jander
2014-09-29 13:29 ` Alexander Stein
2014-09-29 14:39 ` David Jander
2014-09-29 15:02 ` Alexander Stein
2014-09-30 7:13 ` David Jander
2014-09-30 7:43 ` Alexander Stein
2014-10-01 6:29 ` David Jander
2014-10-01 7:11 ` Alexander Stein
2014-10-01 7:15 ` Marc Kleine-Budde
2014-10-01 8:29 ` Alexander Stein
2014-10-01 9:07 ` David Jander
2014-10-01 9:19 ` Alexander Stein [this message]
2014-10-01 9:34 ` David Jander
2014-10-01 9:58 ` Marc Kleine-Budde
2014-10-06 7:28 ` David Jander
2014-10-06 10:00 ` Marc Kleine-Budde
2014-10-06 11:17 ` David Jander
2014-10-07 9:30 ` [RFC PATCH 1/2] can: rx-fifo: Increase MB size limit from 32 to 64 David Jander
2014-10-07 9:30 ` [RFC PATCH 2/2] can: rx-fifo: Add support for IRQ readout and NAPI poll David Jander
2014-10-07 13:17 ` [RFC PATCH 1/2] can: rx-fifo: Increase MB size limit from 32 to 64 Marc Kleine-Budde
2014-10-07 13:27 ` David Jander
2014-10-07 14:18 ` Marc Kleine-Budde
2014-10-08 9:08 ` [PATCH v5] can: flexcan: Re-write receive path to use MB queue instead of FIFO David Jander
2014-10-08 9:56 ` Marc Kleine-Budde
2014-10-08 10:36 ` Alexander Stein
2014-10-08 10:43 ` Marc Kleine-Budde
2014-10-08 14:01 ` David Jander
2014-10-09 10:37 ` David Jander
2014-10-01 9:19 ` David Jander
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=5856354.jaFqUxgnZF@ws-stein \
--to=alexander.stein@systec-electronic.com \
--cc=david@protonic.nl \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.