Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
From:   =?utf-8?Q?Krzysztof_Ha=C5=82asa?= <khalasa@piap.pl>
To:     Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc:     linux-media <linux-media@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: Sony IMX290/462 image sensors I2C xfer peculiarity
References: <m3y1gpw8ri.fsf@t19.piap.pl>
        <CAPY8ntASwh3AcRqE+2zF4Df=u+=wJ5K9icAeOrXTMJGDd1+caw@mail.gmail.com>
Date:   Tue, 03 Oct 2023 14:59:16 +0200
In-Reply-To: <CAPY8ntASwh3AcRqE+2zF4Df=u+=wJ5K9icAeOrXTMJGDd1+caw@mail.gmail.com>
        (Dave Stevenson's message of "Fri, 29 Sep 2023 14:33:42 +0100")
Message-ID: <m3o7hfx3ob.fsf@t19.piap.pl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S1pVdUVwS3pXWHk2eE9Yak1zVEphWlVnVm1zUVZ4NXppc0FPdHFOblVFeHQv?=
 =?utf-8?B?VkRMa1lORnhEaEthY1l6OWNMSmVYZXRZaW5xekpsT0Y4QmgzbERzcHRNWCt1?=
 =?utf-8?B?akhGTjlKMHdFNDE4UzZrTnphQXk1MmtUMUtBb0YvajVTNXNjUTQ3NStDQVBj?=
 =?utf-8?B?UkhvOGhRWXdBcUtGWUM2aHNLMXJZbWxPc2FtTmFLOHVLRjczdDgzcVhTWENk?=
 =?utf-8?B?L3VsSVNFeHRBTVhrVTRQNUR4NS8xQ2htY1R5aXZZamhKYnZpdFhhenFGMCtt?=
 =?utf-8?B?dW5Kc0xuY3V6aTg1T2VydUxQOXN0ZEU4bnNaQ2dVQjlSczhJc3hSVnZJQlV3?=
 =?utf-8?B?enFNbmtEVVJCa0UvVTlRaldYREN6NlFRQW56cjNsQzFhYTRvUmtHRElRMHlN?=
 =?utf-8?B?UkwwUVgyb09LWTQ5bkFPRDZUSkVpUEVYUXlzbWt2dDczWmliOW1XZlc4WHds?=
 =?utf-8?B?WTNJMXh5cFo3RzI5bVVZbUNvS3l0cUc3WElZRngxblkvN2V4M1JnVDZJYWJ5?=
 =?utf-8?B?bEhqbWJGcXhScUpJRWZFQXdyYUhNU3NRMFMxcVpMUXlVY0RnbUdxaFZUQWU5?=
 =?utf-8?B?aDVUL3hwQklSZXpqd21yYkd3S1hucEFkTE0rT1FuT05wbUttSFNpQWFBdmZS?=
 =?utf-8?B?K3psN29TeXlmbGFISlpxTFc5OUVRSmZlYm9VdVpSRmlrTStPRkhQa2htVmJn?=
 =?utf-8?B?M0NOK3VVbEQ1TVloaHhCUjdGTXE3MWFvbXQxdXNKSlFXY2s3TGhtUHc0OVQ1?=
 =?utf-8?B?aE11SnpzMU9MYUdGQktqa0RYeDdvUHhVSmdLRzhUeDFhNGpzczFkTHRPQ2Uy?=
 =?utf-8?B?aGlTYjh3QVR2UzRZNWJRK0Z1Y2FZSnY0d3pMQk55WWhuK0J5aVdJRUZBbE4x?=
 =?utf-8?B?NkdETGh1MnlYbnBEOW1sZzVsU01HNEVuMDkxcTRqZldFMzZqQnpsOTR2UlB3?=
 =?utf-8?B?UWJuQ2NmY25neGxYU3BKcjhrc2tMMzJ5Mkd5aWpiZTJBVUllTzNOcWRkZXdp?=
 =?utf-8?B?LzR6V1R1UkpDMEpHUk5yc0pOeHV1amI4TEI4bmJNS256ZElDMUp5dzhaRDRn?=
 =?utf-8?B?K0RIVm1hTGpBVklUQy9WemlPeEluMDlndVR1MVFGRmRxcUI5eExJVTh1OVQ1?=
 =?utf-8?B?NGdjTzkvR3Z0OXNldmxCNXlyVlZ4YS9vbFRJb2E0R1JkUHFhQ0tWdGZsQ3NB?=
 =?utf-8?B?N1F5Qzhxd3p5THRUWjdnWGM5QWVKQ1hBMUlwb1dxOVU3YzlzV0pqMVBZdVRB?=
 =?utf-8?B?VGtUUi9kdkRlbDhML2FnTzMzbFp4dFROOEthdzRzRGE5YW0rT3Y4OFQ5OFlk?=
 =?utf-8?B?SHdraEV3aW5UdHZmNVBneVEwWVZNU1ppa2hHanV5aG9XSFJXMVMzYk5jN2RK?=
 =?utf-8?B?WUhQMWoySlFrbmtTOGxCc1BDbTFmcnNLZ3k1V2RzdEhBc1Bad2xxdTdDRmtL?=
 =?utf-8?B?ckxHWUdBVmlyNGNWbkROMFdyTlZEbVFmZ3hHU0lLTENHL1Nmc2wzejh6ZUp3?=
 =?utf-8?B?RmNjOHZ0UUNUVkQ2dlc5bW0wa2ZyUEJ3enZSVEF0clVQdWVKbHE1SC9HTHV5?=
 =?utf-8?B?SVBPUE9PYUQ2d05RTm9kZzFRWUU3S3RFVGl6a1cxRUZEd0ZKVDlFY0JSK0xK?=
 =?utf-8?B?dFFCclRZVHFDbGdDRWd4UkR4eWJQWGFGYmI5Mk1oL0Y0K0VTTE5nMTdWMEdp?=
 =?utf-8?B?TEdCMjZkOFBsQkxQcSttdTFPS0FQZmhkZHlzV0VUU1NoYVVNbllmTnBiTEc1?=
 =?utf-8?B?VGlzSTJhSlIwQk1hSEgwblNvZCtRTjdiL3JLV2ordVFycXAwTnc4V3J3NTZy?=
 =?utf-8?B?RHJsMTluN0hqV1cvOU9Wb3BXcHJ6Q2tJaWJvT2NPMmdwb1lKQ3hNcU9zOUZY?=
 =?utf-8?B?REd4TGZBUXIrcnFpZnAwUlJ2UW01YTNVK0h0TDhTNU84RFFJK296QUVxSWF1?=
 =?utf-8?B?SWlLdktsSTNHM2lDSVpxL3dCUE5uUWViWWVjUlkydWhlTUJHdEt3dVBGdDhG?=
 =?utf-8?B?RFFUNmVnODZMNTlSNE8zb0F4NktkREtvVEhCUXdOLzJZVTJOb2Z6emNNVDcy?=
 =?utf-8?B?Zmk5MTBva09XQW8vb1VZTmdrY3UxdkIxK3g3dVFkTVlIcHFxaUtGVFhDN0hB?=
 =?utf-8?B?eEEvSmd0akdUWHpIWG40NVA3VkJVSGxCR1c3K2NSVUN5V3EvY1d5V1lLMzk1?=
 =?utf-8?Q?/14VQfcgLBVVC1o9vM26UK3T0QPFTmCl/ywvbdKdx67Y?=
X-OriginatorOrg: piap.pl
X-MS-Exchange-CrossTenant-Network-Message-Id: b0e3a7fd-34c2-46ba-5f9b-08dbc4108e01
X-MS-Exchange-CrossTenant-AuthSource: DB8P193MB0680.EURP193.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2023 12:59:18.5972
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3e05b101-c6fe-47e5-82e1-c6a410bb95c0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bWUX1dal/PjFaVlNoZTxsXtEDBi8ZGQdVrDCRodbB2IYKcJJojiXFobMDq4zZDRYTFcShUQQQ/tAD6DbiKOlgWUBvPXHRWRtXgf7gHhBdbXOpIla0Gep4It/vZtj7R6pu7S1luXzgwwUPtl8v6NLng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P193MB1064
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_BLOCKED,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 03 Oct 2023 05:59:29 -0700 (PDT)

Hi Dave,

thanks for your mail:

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

Ah, I'm debugging I/O errors while trying to use the sensors, it was
only an example how to reliably trigger the problem.

> 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?

I2C doesn't specify a time limit for requests. Even doing basic things -
like enabling streaming - I sometimes get I/O errors ("arbitration
lost"). This is i.MX6MP platform using PIO-style hardware master I2C.
While the CPU has some DMA capability for I2C, it's apparently not used
in this case - maybe because the transfers are shorter than the
threshold.

BTW the "arbitration lost" means here a STOP was detected by the CPU.
This happens when the sensor stops pulling down SDA on timeout, in case
SCL was high at the time (SDA 0->1 with SCL high is technically STOP,
but there is only one master here - CPU - and only one I2C device - the
sensor, so it isn't a real STOP, it's just a sensor disconnection from
the I2C bus).

With 37.125 MHz master clock the time limit is ca. 7 ms - it's easy for
a short transfer to take more time, even on an otherwise idle system and
even with 400 kHz I2C clock.

It happens in init, while enabling streaming, while setting parameters
while streaming. Everytime a transfer crosses the magic ca. 7.06xx ms
time. No transfer can take more time than this value, I always get
a (false) STOP or the data being read becomes all ones.

> 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!

Right, I noticed this, but I don't think it's related. The issue can be
seen in idle as well.

> 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?

I'm just hitting a seemingly hard limit with long transfers (albeit it
may be quite short in terms of bytes - times between bytes are just long
due to scheduling and PIO-style byte-sized CPU access).

> A logic analyser looking at XVS, XHS, and the I2C might
> give you some clues.

TBH I didn't try to connect to XVS and XHS. My IMX290 modules don't even
have these signals (apparently -  there are "unused" connections).
I just observed that the timeout is 2^18 master cycles from the first
START. There it very little jitter here (on an oscilloscope - a fraction
of a microsecond). I haven't counted the exact master clock cycles #,
should I?

> Or are you not streaming when you're doing these
> transactions?

That's the case, too.

> IMX462 appears to list a similar restriction.
--=20
Krzysztof "Chris" Ha=C5=82asa

Sie=C4=87 Badawcza =C5=81ukasiewicz
Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP
Al. Jerozolimskie 202, 02-486 Warszawa