linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Stefan Eichenberger <eichest@gmail.com>
Cc: kernel@pengutronix.de, andi.shyti@kernel.org,
	shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com,
	Frank.Li@nxp.com, francesco.dolcini@toradex.com,
	linux-i2c@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Stefan Eichenberger <stefan.eichenberger@toradex.com>
Subject: Re: [PATCH v2 4/4] i2c: imx: prevent rescheduling in non dma mode
Date: Fri, 30 Aug 2024 10:13:56 +0200	[thread overview]
Message-ID: <ZtF_RJaG9lj_Mvtb@pengutronix.de> (raw)
In-Reply-To: <20240819072052.8722-5-eichest@gmail.com>

On Mon, Aug 19, 2024 at 09:19:10AM +0200, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> 
> We are experiencing a problem with the i.MX I2C controller when
> communicating with SMBus devices. We are seeing devices time-out because
> the time between sending/receiving two bytes is too long, and the SMBus
> device returns to the idle state. This happens because the i.MX I2C
> controller sends and receives byte by byte. When a byte is sent or
> received, we get an interrupt and can send or receive the next byte.
> 
> The current implementation sends a byte and then waits for an event
> generated by the interrupt subroutine. After the event is received, the
> next byte is sent and we wait again. This waiting allows the scheduler
> to reschedule other tasks, with the disadvantage that we may not send
> the next byte for a long time because the send task is not immediately
> scheduled. For example, if the rescheduling takes more than 25ms, this
> can cause SMBus devices to timeout and communication to fail.
> 
> This patch changes the behavior so that we do not reschedule the
> send/receive task, but instead send or receive the next byte in the
> interrupt subroutine. This prevents rescheduling and drastically reduces
> the time between sending/receiving bytes. The cost in the interrupt
> subroutine is relatively small, we check what state we are in and then
> send/receive the next byte. Before we had to call wake_up, which is even
> less expensive. However, we also had to do some scheduling, which
> increased the overall cost compared to the new solution. The wake_up
> function to wake up the send/receive task is now only called when an
> error occurs or when the transfer is complete.
> 
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>

Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


      reply	other threads:[~2024-08-30  8:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19  7:19 [PATCH v2 0/4] i2c: imx: prevent rescheduling in non-dma mode Stefan Eichenberger
2024-08-19  7:19 ` [PATCH v2 1/4] i2c: imx: only poll for bus busy in multi master mode Stefan Eichenberger
2024-08-21 11:01   ` Fabio Estevam
2024-08-21 14:39     ` Oleksij Rempel
2024-08-21 15:23       ` Stefan Eichenberger
2024-08-21 16:43         ` Fabio Estevam
2024-08-21 22:31         ` Andi Shyti
2024-08-22  6:51     ` Oleksij Rempel
2024-08-22 11:07     ` Fabio Estevam
2024-08-22 11:50       ` Stefan Eichenberger
2024-08-22 12:59         ` Fabio Estevam
2024-08-23 13:43       ` Stefan Eichenberger
2024-08-21 22:21   ` Andi Shyti
2024-08-22  7:03     ` Stefan Eichenberger
2024-08-22 10:04       ` Oleksij Rempel
2024-08-22 12:03         ` Stefan Eichenberger
2024-08-23  0:35         ` Andi Shyti
2024-08-23 13:48           ` Stefan Eichenberger
2024-08-23 14:04             ` Oleksij Rempel
2024-08-23 14:42               ` Stefan Eichenberger
2024-08-19  7:19 ` [PATCH v2 2/4] i2c: imx: separate atomic, dma and non-dma use case Stefan Eichenberger
2024-08-30  7:31   ` Oleksij Rempel
2024-08-19  7:19 ` [PATCH v2 3/4] i2c: imx: use readb_relaxed and writeb_relaxed Stefan Eichenberger
2024-08-30  7:37   ` Oleksij Rempel
2024-08-19  7:19 ` [PATCH v2 4/4] i2c: imx: prevent rescheduling in non dma mode Stefan Eichenberger
2024-08-30  8:13   ` Oleksij Rempel [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=ZtF_RJaG9lj_Mvtb@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=Frank.Li@nxp.com \
    --cc=andi.shyti@kernel.org \
    --cc=eichest@gmail.com \
    --cc=festevam@gmail.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=stefan.eichenberger@toradex.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).