linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Torin Cooper-Bennun <torin@maxiluxsystems.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Subject: Re: Improving TX for m_can peripherals
Date: Wed, 5 May 2021 13:21:32 +0100	[thread overview]
Message-ID: <20210505122132.sbutrydmu5qvggke@bigthink> (raw)
In-Reply-To: <20210505115624.7qhbit4olyvpfkf4@pengutronix.de>

On Wed, May 05, 2021 at 01:56:24PM +0200, Marc Kleine-Budde wrote:
> For easier queuing, get rid of the worker. Directly send the can_frame
> from the xmit handler. The problem is, you cannot sleep inside it. This
> means, you cannot use regmap(), the only thing that works is
> spi_async(). And as it's async, you can only write data via SPI, reading
> doesn't make sense.

Yeah, this makes things pretty tough, given that we currently have to
read the next available TX buffer index before doing the writes!

> Have a look at the mcp251xfd_start_xmit() function. All data structures
> for the SPI messages are prepared in beforehand in
> mcp251xfd_tx_ring_init_tx_obj(). The xmit function looks up the correct
> data structure, converts the skb to the chip's format
> mcp251xfd_tx_obj_from_skb() and then sends the data over spi. Special
> care is taken of the handling of the head and tail pointers and the
> stopping of the queue to avoid race conditions - see
> mcp251xfd_get_tx_free(), mcp251xfd_tx_busy(), netif_stop_queue(),
> netif_wake_queue().
> 
> Hope that helps,
> Marc

I'll be sure to look into it in more detail, thanks. In the meantime,
your patch is working very well to mostly solve this issue :)

--
Regards,

Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com


      reply	other threads:[~2021-05-05 12:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 10:30 Improving TX for m_can peripherals Torin Cooper-Bennun
2021-05-05 11:56 ` Marc Kleine-Budde
2021-05-05 12:21   ` Torin Cooper-Bennun [this message]

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=20210505122132.sbutrydmu5qvggke@bigthink \
    --to=torin@maxiluxsystems.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    /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).