media: i2c: imx219: Scale the pixel rate for analog binning

[naushir]

When the analog binning mode is used for high framerate operation, the pixel rate is effectively doubled. Account for this when setting up the pixel clock rate, and applying the vblank and exposure controls.

The previous logic only used analog binning for RAW8, but normal binning limits the framerate on RAW10 480p 1. So with this patch we switch to using special binning (with 2x pixel rate) wherever possible.

Co-developed-by: Naushir Patuck naush@raspberrypi.com

Co-developed-by: Vinay Varma varmavinaym@gmail.com

[naushir]

@6by9 @pelwell

Any objections to merging this?

[pelwell]

I didn't understand the benefit of adding the binning_mode enumeration, but no objections.

[naushir]

I didn't understand the benefit of adding the binning_mode enumeration, but no objections.

Neither do I TBH - it was an upstream thing 😃

[6by9]

Adding "Commit f513997 upstream" would help Dom for rebasing onto 6.15 and above.
But I have no issues with backporting this commit.

[naushir]

Adding "Commit f513997 upstream" would help Dom for rebasing onto 6.15 and above.

Done!

[Alexei-Kornienko]

@naushir Hello. I've tried reading camera with kernel version of 6.12.48. And it seems that this fix causes another issue. FPS seems to be fixed however I get my images with horizontal stipes of 64 pixels high that are misaligned. (attached example image)

When I revert to a stable kernel this issue is not present.

[naushir]

What command line are you using for the above capture?

[Alexei-Kornienko]

I don't use a command line directly. I read frames using libcamera bindings to Rust... but basically here is my settings that I get from the sensor:

StreamConfigurationRef {
            pixel_format: SBGGR16,
            size: Size {
                width: 1640,
                height: 1232,
            },
            stride: 3328,
            frame_size: 4100096,
            buffer_count: 6,
        },

And I read a Plane from a FrameBuffer.

I've tried running exactly the same code on different kernel versions and on a Linux rpi 6.12.34+rpt-rpi-2712 everything is fine.

[naushir]

Thanks - confirmed that this breaks the 1640x1232 mode. Annoyingly I did not test this one as 640x480 is the only mode that is applicable for the rate change.

Sign, this is again upstream trying to achieve modeless settings that now break some modes :(

[pelwell]

upstream trying to achieve modeless settings that now break some modes :(

Fewer modes = more modeless.

[Alexei-Kornienko]

640x480 is the only mode that is applicable for the rate change.

1640x1232 with this patch also changes to 83.7 fps (which is what I'm trying to use)

[naushir]

1640x1232 with this patch also changes to 83.7 fps (which is what I'm trying to use)

That may not be a functional mode/framerate on this sensor.

[Alexei-Kornienko]

I've mentioned it in raspberrypi/libcamera#308
I used 8 bit mode in an old kernel version and it seems to work fine.
'SRGGB8' : 1640x1232 [83.70 fps - (0, 0)/3280x2464 crop]

At that time I used just a python picamera2 module (which internally uses libcamera) and was able to read 80 fps without any issues.
So for an old kernel I got:

rpicam-hello --list-cameras
Available cameras
-----------------
0 : imx219 [3280x2464 10-bit RGGB] (/base/axi/pcie@120000/rp1/i2c@88000/imx219@10)
    Modes: 'SRGGB10_CSI2P' : 640x480 [206.65 fps - (1000, 752)/1280x960 crop]
                             1640x1232 [41.85 fps - (0, 0)/3280x2464 crop]
                             1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
                             3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]
           'SRGGB8' : 640x480 [206.65 fps - (1000, 752)/1280x960 crop]
                      1640x1232 [83.70 fps - (0, 0)/3280x2464 crop]
                      1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
                      3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]

and for a new:
uname -a
Linux rpi 6.12.48-v8-16k+ #1905 SMP PREEMPT Mon Sep 22 13:35:50 BST 2025 aarch64 GNU/Linux

rpicam-hello --list-cameras
Available cameras
-----------------
0 : imx219 [3280x2464 10-bit RGGB] (/base/axi/pcie@1000120000/rp1/i2c@88000/imx219@10)
    Modes: 'SRGGB10_CSI2P' : 640x480 [206.65 fps - (1000, 752)/1280x960 crop]
                             1640x1232 [83.70 fps - (0, 0)/3280x2464 crop]
                             1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
                             3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]
           'SRGGB8' : 640x480 [206.65 fps - (1000, 752)/1280x960 crop]
                      1640x1232 [83.70 fps - (0, 0)/3280x2464 crop]
                      1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
                      3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]

So newer version makes SRGGB10_CSI2P mode to work on 83 fps.

[6by9]

So newer version makes SRGGB10_CSI2P mode to work on 83 fps.

The new version lists that it works at 83fps. That doesn't necessarily mean it actually works.
The fix is going to be revert the 10bit 1640x1232 mode to supporting up to 41.85 fps.

[Alexei-Kornienko]

I understand that. However I would like to use at least 8 bit SRGGB8 in 80fps mode. And on latest stable kernel it only exposes 40 fps. And this seems like a regression to me

[naushir]

#7063 updates another downstream patch from 6.6 to fix the mode specific binning factors.