[TESTING] kbingham/rpi 6.16.y/imx283 fixes

[kbingham]

Some redesign of the imx283 mode configuration that allows us to add modes and configurations more easily. Ultimately - I hope to progress this sometime to support free arbitrary cropping on the sensor side with the driver handling all the alignment and restrictions correctly - but that will take some more time still yet.

Crucially in this series is some changes to the handling of the user clamp area which contains the VOB but isn't actually part of the sensor vertical position coordinates. Previously - this means that a 16 line offset has been occuring in the output image.

Another artifact is that the sensor introduces an extra line at the top of the image which we believe is to support or prevent bayer reordering on vflip. But the additional line produces an undesirable artifact in the output. This series uses the ability to adjust the clamp area/VOB to extend over the additional line (and one more to maintain bayer order) to remove the artifact. To prevent this causing the image to be offset - an extra two lines are requested on top of the mode first.

Finally - three clear new modes are added

• native array - outputs the full 5592x3710 pixel count - which is interesting as you see the bayer reorder occur - and the various HOB/VOB areas.
• a 'full active' pixels mode produces all output from the sensor /excluding/ the HOB/VOB - but this includes the additional line artifact.
• The 'effective array' is the datasheet pixel area that includes a 12 pixel margin on all sides to allow for color processing to occur in the ISP scalers without issues at the edges.

I'd still like to get the binning and timing values out of the crop mode structure - but that will take some more work - and we don't yet have an api to control binning / skipping which makes it difficult to convey in the scanout mode structures.

[kbingham]

I haven't posted these upstream yet - sharing here to get them tested by known IMX283 users on RPi ... but no specific desire to merge this into the RPi tree until reviewed upstream. But they could be if testers find the series beneficial.

[will127534]

SRGGB12_CSI2P,5592x3710 mode doesn't seems right, but all other modes are working fine: 5592x3710:

5496x3672:

[will127534]

Ah it looks like SRGGB10_CSI2P,5472x3648/0 this mode isn't working also, there is no error message but the frame is empty.

[will127534]

Here are the jpeg images for all the modes =========12-bit Mode ============ 5592x3710_12: 5496x3694_12: 5496x3672_12: 5472x3648_12: 2736x1824_12: 1824x1216_12:

=========10-bit Mode ============ 5472x3648_10:

[kbingham]

Thank you - I hadn't noticed 10 bit was broken - but thanks to your test I can see the bug. I'll fix that.

[kbingham]

5592x3710_12:

I think this is almost expected behaviour - I was expecting 'pink' because the bayer order ends up being mis-interpreted/mis-aligned - though I don't know why it goes quite so psychedelic through the ISP ... But it's also a bit too specialised a mode to actually advertise anyway I think - so I'll just drop this one.

[pelwell]

What's the state of this PR? rpi-6.16.y is EOL, and rpi-6.17.y can't be far behind. rpi-6.18.y must still be quite close to upstream, and we'd want this on rpi-6.18.y before we'd consider merging, so perhaps it's time to rebase your branch.

[kbingham]

absolutely - no desire for this to be merged for RPI it's testing only - I've only pushed this so that I could get some RPI testers the most recent updates on a working Pi kernel, where they reported some issues.

I'll be posting these upstream to mainline, and where appropriate I'll share backports - but I wanted to be sure everything's working, and work through some issues that were reported in the community.