From: David Jander <david@protonic.nl>
To: Alexander Stein <alexander.stein@systec-electronic.com>
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, 1 Oct 2014 11:07:41 +0200 [thread overview]
Message-ID: <20141001110741.0e8e5ffb@archvile> (raw)
In-Reply-To: <4712537.n1vM034J9B@ws-stein>
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.
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...
Best regards,
--
David Jander
Protonic Holland.
next prev parent reply other threads:[~2014-10-01 9:07 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 [this message]
2014-10-01 9:19 ` Alexander Stein
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=20141001110741.0e8e5ffb@archvile \
--to=david@protonic.nl \
--cc=alexander.stein@systec-electronic.com \
--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.