From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Stefan Lengfeld <contact@stefanchrist.eu>
Cc: linux-media <linux-media@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Oleksij Rempel <linux@rempel-privat.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
linux-i2c@vger.kernel.org
Subject: Re: Sony IMX290/462 image sensors I2C xfer peculiarity
Date: Wed, 11 Oct 2023 13:25:55 +0200 [thread overview]
Message-ID: <m3fs2htn7g.fsf@t19.piap.pl> (raw)
In-Reply-To: <20231011101553.we3r73xejvqdql5j@porty> (Stefan Lengfeld's message of "Wed, 11 Oct 2023 12:15:53 +0200")
Stefan,
> I cannot answer whether the delay is needed for atomic transfer or not.
> But I can give a bit of context for I2C atomic transfers in general.
>
> These where only introduced for a very narrow and special uses shutting
> down the device/power with external PMICs in the kernel's shutdown
> handlers.
Well, I guess I'm abusing this code a bit.
The problem is I use Sony IMX290 and IMX462 image sensors, and they have
an apparently hard-coded timeout of about 2^18 their master clock cycles
(= ca. 7 ms with my setup). After the timeout they simply disconnect
from the I2C bus. Of course, this isn't mentioned in the docs.
Unfortunately, "normal" I2C accesses take frequently more than those
7 ms (mostly due to scheduling when all CPU cores are in use). So I
hacked the IMX I2C driver a bit and now all accesses to the sensor use
the atomic paths and local_irq_save() (inside the driver only).
> My understand is that an ordinary I2C device would just use normal (and
> sleepable) I2C transfers while the device is in use.
You are spot-on here :-) Now I use IMX 290 and 462.
OTOH I wonder if such issues are limited to those sensors only.
Thanks for your immediate response,
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
next prev parent reply other threads:[~2023-10-11 11:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 10:53 Sony IMX290/462 image sensors I2C xfer peculiarity Krzysztof Hałasa
2023-09-29 13:33 ` Dave Stevenson
2023-10-03 12:59 ` Krzysztof Hałasa
2023-10-10 9:46 ` Krzysztof Hałasa
2023-10-11 9:10 ` Krzysztof Hałasa
2023-10-11 9:50 ` Krzysztof Hałasa
2023-10-11 10:15 ` Stefan Lengfeld
2023-10-11 11:25 ` Krzysztof Hałasa [this message]
2023-10-11 11:59 ` Alexander Stein
2023-10-11 12:18 ` Krzysztof Hałasa
2023-10-12 22:01 ` Stefan Lengfeld
2023-10-13 7:17 ` Wolfram Sang
2023-10-13 10:39 ` Krzysztof Hałasa
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=m3fs2htn7g.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=contact@stefanchrist.eu \
--cc=dave.stevenson@raspberrypi.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/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.