From: Marc Kleine-Budde <mkl@pengutronix.de>
To: "Stéphane Grosjean" <s.grosjean@peak-system.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
linux-can Mailing List <linux-can@vger.kernel.org>
Subject: Re: [PATCH 3/3] can/peak_usb: add support of ONE_SHOT mode
Date: Wed, 10 Mar 2021 12:53:05 +0100 [thread overview]
Message-ID: <20210310115305.firsk4zgacjwgiys@pengutronix.de> (raw)
In-Reply-To: <PA4PR03MB6797F23B2236519A345A8C3DD6919@PA4PR03MB6797.eurprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
On 10.03.2021 11:18:15, Stéphane Grosjean wrote:
> To complete the open reflection on this subject: to be perfect, the
> echo skb should in fact not be released by the USB write completion
> routine but, like the PCI/PCIe version, on reception in the Rx queue
> of an echo frame to the one written...
If you don't have a TX complete notification, this would be a workaround
to let the TX echo better reflect what's going on on the bus.
> This means :
> 1 - the core of the peak_usb driver has to be deeply modified
> 2 - the rx path of the USB interface will be much more loaded,
> resulting in a higher CPU load
> 2 - in the case of a one-shot frame, how to manage the fact that this
> echo frame is never received because the one-shot frame could not
> be written on the bus? Does this need a garbage collector on the
> echo skbs?
Yes, you have to free the echo skb in case of a no-send due to one-shot
mode.
Does the HW offer a TX aborted notification?
> Is it worth it?
If you don't have TX complete or TX abort notifications, then it's not
worth it. Better spend time implementing these notifications on the
controller side :)
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-03-10 11:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 11:18 [PATCH 3/3] can/peak_usb: add support of ONE_SHOT mode Stéphane Grosjean
2021-03-10 11:53 ` Marc Kleine-Budde [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-03-09 14:53 Stéphane Grosjean
2021-03-09 14:58 ` Marc Kleine-Budde
2021-03-09 8:21 [PATCH 0/3] can/peak_usb: Added improvement to the peak_usb driver Stephane Grosjean
2021-03-09 8:21 ` [PATCH 3/3] can/peak_usb: add support of ONE_SHOT mode Stephane Grosjean
2021-03-09 10:36 ` Marc Kleine-Budde
2021-03-09 10:53 ` Oliver Hartkopp
2021-03-09 10:58 ` Marc Kleine-Budde
2021-03-19 10:01 ` Marc Kleine-Budde
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=20210310115305.firsk4zgacjwgiys@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=s.grosjean@peak-system.com \
--cc=socketcan@hartkopp.net \
/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.