Re: [PATCH v2] media: i2c: imx471: Fix pixel rate and line length
From: Christian Murphy
Date: Sat Sep 05 2026 - 13:13:48 EST
Hi Kate,
Thanks for the series.
On Fri, Sep 4, 2026 at 04:59:58PM +0800, Kate Hsuan wrote:
> According to the datasheet, since this sensor runs in PLL dual mode so
> the PLL configurations in the op domain are used to calculate the data
> rate and pixel rate.
The OP PLL clocks the CSI-2 output. PIXEL_RATE is the pixel array rate
(ext-ctrls-image-process.rst), set by the VT PLL. Your 159.36 MHz is
close to the output-derived 160 MHz the driver has.
LINE_LENGTH_PCK reads back 5120 and a frame at FLL 1308 takes
17.296 ms, so 387.2 MHz. At 159.36 MHz it would take 42 ms.
I tried writing 2560 while streaming: at FLL 1308, 6.61 us lines,
115.6 fps, frames intact, no drops or ISYS errors during the test.
With .llp still 2328 and your pixel rate, libcamera would calculate
14.6 us lines and 52 fps. The measured stream carries 2.4 Gbps of
RAW10, above the 1.6 Gbps a 200 MHz link carries on four lanes, so the
200 MHz in the driver and ipu-bridge is understated, a separate fix.
Writing 2328 gives 6.01 us lines, but the IPU gets 474 rows of
black and flags every frame BAD_FRAME_DIM. Stepping down from 2560,
2544 still gives an image, 2536 down does not, and 2416 down arrives
truncated, so 2560 sits just above the working limit here. The
12.05 us bound I gave Sakari was wrong, but 2328 does not work either.
Using 2560 to raise the frame rate makes sense. With your planned
HBLANK write, .llp needs to be 2560 too, with PIXEL_RATE at 387.2 MHz.
My patch uses 5120 because that is what the sensor currently runs at.
Could we combine the pixel-rate correction with your HBLANK change
and use .llp = 2560 consistently? Happy to test.
Kind regards,
Christian