Kernel 6.12 Compatibility

[schoolpost]

Certainly jumping the gun on this one, I'm attempting to get rpicam-apps/libcamera working with the IMX294 on kernel 6.12

I've had to make some minor adjustments to the driver to account for some v4l2 api changes, specifically:
v4l2_subdev_get_try_crop -> v4l2_subdev_state_get_crop
v4l2_subdev_get_try_format -> v4l2_subdev_state_get_format

and:
#include <asm/unaligned.h> -> #include <linux/unaligned.h>

With that I can get the driver to successfully compile. However there are new issues to contend with. I have image artifacts for nearly all the sensor modes.

    SRGGB10_CSI2P,1896x1404/190.223 - Score: 14202.4
    SRGGB12_CSI2P,1392x248/461.681 - Score: 0
    SRGGB12_CSI2P,1392x736/351.494 - Score: 11286.8
    SRGGB12_CSI2P,3872x2180/61.4288 - Score: 12613.3
    SRGGB12_CSI2P,4144x2184/57.7601 - Score: 12318.4
    SRGGB12_CSI2P,4176x2184/54.3685 - Score: 12282.4
    SRGGB12_CSI2P,3792x2840/41.8305 - Score: 14081.1
    SRGGB14_CSI2P,3792x2840/28.8218 - Score: 15081.1

I say nearly because there are 2 odd sensor modes that seem to not be affected...for whatever reason.

12-bit 1392x248:

14-bit 3792x2840: ( this one is using the software 14-bit unpacking patch, which does work. )

All the other modes exhibit some kind of garbled image output:

12-bit 1392x736

12-bit 4144x2184

Certainly something not right...but I'm not sure where specifically that is ( PiSP, CFE, Libcamera, elsewhere? )

[naushir]

Is the corruption present in the RAW/Bayer data for the 12-bit case? If so I would suggest looking at the sensor driver register set as a start.

[schoolpost]

Is the corruption present in the RAW/Bayer data for the 12-bit case? If so I would suggest looking at the sensor driver register set as a start.

Yes, the RAW is affected. I'm very confused why there are 2 modes that work without issue, and more so confused that the driver is otherwise artifact free and functional in kernel 6.6

Is there anywhere specific I should look first within the driver?

[naushir]

One obvious thing to check is the CSI-2 link frequency is calculated correctly. The code for that can be found here:
https://github.com/raspberrypi/linux/blob/5985ce32e511f4e8279a841a1b06a8c7d972b386/drivers/media/platform/raspberrypi/rp1_cfe/cfe.c#L1088, and wants the sensor driver to correctly advertise V4L2_CID_LINK_FREQ for the mode in use.

There is a handy log message that displays the calculated link frequency in the above function.

[6by9]

The 12-bit 1392x736 corruption looks like some FIFO overflows, or the sensor stops early and you're getting uninitialised memory.

Link frequency is the most likely candidate. What does v4l2-ctl --list-ctrls-menu -d /dev/v4l-subdev2 list as the controls? (correct the subdev if necessary)

[schoolpost]

This appears to be in an issue of RP1 clock speed. To achieve 4K60 capability we have to run a mild overclock of RP1 ( bump it to
300Mhz for ~580Mpx/s and modifying: .minPixelProcessingTime = 1.0us / 580, )

Doesn't look like 6.12 is willing to accept the higher assigned clock, is there new procedure for achieving this?

6.6 actually takes it even further and seems to round up to a higher clock than we assign:

[    0.528434] rp1 0001:01:00.0: bar0 len 0x4000, start 0x1f00410000, end 0x1f00413fff, flags, 0x40200
[    0.528436] rp1 0001:01:00.0: bar1 len 0x400000, start 0x1f00000000, end 0x1f003fffff, flags, 0x40200
[    0.528443] rp1 0001:01:00.0: enabling device (0000 -> 0002)
[    0.528980] rp1 0001:01:00.0: chip_id 0x20001927
[    0.533025] clk: couldn't set clk_sys clk rate to 300000000 (-22), current rate: 333333333

[naushir]

It's been a while since I looked at overclocking RP1. What runes are you using to set the clock speed to 300MHz?

[schoolpost]

Found here: https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm64/boot/dts/broadcom/rp1.dtsi

Changing both <200000000>, // RP1_PLL_SYS & <200000000>, // RP1_CLK_SYS

So this method still works in 6.6 but as I noted, seems to auto adjust itself to 333333333

The same method in 6.12 does not take hold, and stays fixed at 200000000

[naushir]

Do you have a log from the clock driver when setting up clk_sys for the 6.12 tree by any chance?

[schoolpost]

I don't currently, but as I recall scanning through dmesg earlier, I didn't see any explicit logging related to clock driver unlike what I saw in 6.6 : [ 0.530488] clk: couldn't set clk_sys clk rate to 300000000 (-22), current rate: 333333333 <--- from 6.6

[naushir]

I'll take a look and see what I can find. Unfortunately I'm a bit swamped with other things, so it may a while before I get to this.

[schoolpost]

I've jumped back to 6.6 in the mean time, but I'd love to get onto 6.12 as soon as I can.

[fiepfiep]

for me 6.12 works just fine..