linux-kernel - Re: Sony IMX290/462 image sensors I2C xfer peculiarity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPY8ntASwh3AcRqE+2zF4Df=u+=wJ5K9icAeOrXTMJGDd1+caw@mail.gmail.com>
Date:   Fri, 29 Sep 2023 14:33:42 +0100
From:   Dave Stevenson <dave.stevenson@...pberrypi.com>
To:     Krzysztof Hałasa <khalasa@...p.pl>
Cc:     linux-media <linux-media@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Sony IMX290/462 image sensors I2C xfer peculiarity

Hi Krzysztof

On Fri, 29 Sept 2023 at 11:53, Krzysztof Hałasa <khalasa@...p.pl> wrote:
>
> Hi,
>
> I am debugging certain IMX290 and IMX462 I2C failures on an NXP
> i.MX6MP based board and there seem to be interesting "feature" here:
> Sony IMX290 and IMX462 image sensors apparently terminate I2C transfers
> after 2^18 of their master clock cycles. For example, with a typical
> 37.125 MHz clock oscillator, this means about 7 ms. In practice, I'm
> barely able to read a block of 128 registers (at I2C 400 kHz clock
> rate).
>
> I think the sensors simply disconnect from the bus after 2^18 clock
> cycles (starting from the first START condition, the repeated STARTs
> don't reset the timeout). This means, in case of a READ operation, the
> data read by the CPU after the timeout contains all bits set to 1.
> i.MX8MP detects arbitration losses, so if the SDA change to 1 happens on
> high clock value (but not on ACK bit), the whole transfer is aborted.
> Otherwise, the ending bytes are simply set to FF (and the last non-FF
> may be corrupted partially).
>
> The problem is 7 ms is a short time and on a non-real time system even
> a simple non-DMA I2C register writes can take as much time. This causes
> driver failures.

What's your requirement to be able to read back so many registers at once?

Whilst potentially useful during development, most sensor drivers
write specific registers but never read anything other than
potentially a model ID register during probe.
Large block writes are generally not possible as at least the IMX290
datasheet does state "Do not perform communication to addresses not
listed in the Register Map", and there are numerous reserved blocks
throughout the map.
As far as I know there's no OTP on these sensors which would be about
the only reason I can think of for needing to read large blocks.

I currently can't see a reason for a sensor driver to be needing to do
these big reads, so how can it cause a driver failure?

Scanning the IMX290 datasheet further, there is a slightly worrying
paragraph in "Register Communication Timing (I2C)":
"In I2C communication system, communication can be performed excluding
during the period when communication is prohibited from the falling
edge of XVS to 6H after (1H period)."
and the diagram shows a 1 line period 6 lines after XVS which is
marked "communication prohibited period". Ouch!
I've never experienced issues with I2C comms to these modules, but is
it possible that you're hitting this period with your longer I2C
transactions? A logic analyser looking at XVS, XHS, and the I2C might
give you some clues. Or are you not streaming when you're doing these
transactions?
IMX462 appears to list a similar restriction.

  Dave

> Needless to say, the datasheets know nothing about the feature.
>
> Any thoughts?
> --
> Krzysztof "Chris" Hałasa
>
> Sieć Badawcza Łukasiewicz
> Przemysłowy Instytut Automatyki i Pomiarów PIAP
> Al. Jerozolimskie 202, 02-486 Warszawa