Re: [PATCH v2] media: i2c: imx471: Fix pixel rate and line length

[Kate Hsuan]

Hi Christian,

Thank you for your patches.

On Sun, Sep 6, 2026 at 1:12 AM Christian Murphy <christian@xxxxxxxxxxxxx> wrote:
>
> 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 went to the VT domain at the beginning, but after reading the
datasheet, it mentioned, "IOPSYCK determines the pixel rate". I
switched to the OP domain. Perhpas, the datasheet and MIPI datasheet
confused me.

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

That is why I try to set it to the original value 2560 for line length PCK.
Idealy, the sensor supports 2328x1304 @150fps (binning mode)
based on the new value 0x0a00 (2560) (ipu6-drivers), libcamera reports
115.63 fps on my X9-15.

> 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.
It's ok. sure

for the line length PCK part, I try to propose a variable setting like
what mt9m114 did.
Line length PCK can be changed along with HBLANK control. This may
allow hblank to be configured and fps to be changed.

Compare to your pixel rate equation with the equation mentioned in the
MIPI datasheet + PLL tree in the imx471 datasheet.

imx471 signal processing rate is determined by ext freq,
VT_PREPLLCK_DIV, VT_PLL_MPY, and VT_SYCK_DIV * VT_PXCK_DIV.
so it may look like
signal processing rate = (ext freq * VT_PLL_MPY) / (VT_PREPLLCK_DIV *
VT_SYCK_DIV * VT_PXCK_DIV).
(I think this is per lane)

and
MIPI spec mentions the pixel speed is:
ext_vt_pixel_clk_freq_MHz = (ext_clk_freq_MHz * vt_pll_multiplier *
num_of_vt_lanes) / (vt_pre_pll_clk_div * vt_sys_clk_div *
vt_pixel_clk_div)
(19200000 * 121 * 4) / (2 * 2 * 6) = 387200000

The result is the same as your pixel rate 387.2Mhz. Could you consider
this approach?

>
> Kind regards,
>
> Christian
>


--
BR,
Kate