Firstly there is no obligation to make V4L2_CID_HBLANK writeable - you could just compute the right HBLANK value for each mode, and use VBLANK (which is generally far simpler as it's always in lines) for frame rate control. VBLANK is used in preference to HBLANK to extend the frame time as it minimises the temporal delay between lines on rolling shutter cameras, so HBLANK only comes into play on really long exposures.
Making HBLANK R/W is effectively the icing on the cake, and allowing absolutely all the features of the sensor to be exposed.
Do be very careful over PIXEL_RATE and LINK_FREQUENCY - they may be directly linked, but there is no guarantee. Many sensors have a FIFO between the pixel array and MIPI blocks. PIXEL_RATE is used in the pixel array calculations, and link frequency is for the MIPI side. eg for IMX477, PIXEL_RATE is 840MPix/s which should do 4k60, but with a link frequency of 450MHz or 900Mbit/s per lane, 2 lanes only gives 1800Mbit/s, or 150MPix/s at 12bpp. You'll note that the minimum line length is 0x5dc0 or 24000 pixels in 4056x3040 mode, so the FIFO has a chance to empty for each line.
will127534's approach for configuring HBLANK looks reasonable. It does mean that the value set may be slightly different from that requested, but it should be a minimal offset. Within the V4L2 spec, the control handler is allowed to amend the requested value (https://www.kernel.org/doc/html/latest/ ... -ctrl.html
and https://www.kernel.org/doc/html/latest/ ... ctrls.html
When the value is out of bounds drivers can choose to take the closest valid value or return an ERANGE error code, whatever seems more appropriate. In the first case the new value is set in struct v4l2_ext_control. If the new control value is inappropriate (e.g. the given menu index is not supported by the menu control), then this will also result in an EINVAL error code error.
So you could take the requested value, convert it to HMAX, and then convert that back to ensure that userspace is told the actual value set.
If you want a definitive answer, then you need to post the query (or driver) on the linux-media mailing list. http://vger.kernel.org/vger-lists.html#linux-media
For IMX283 I note that Arducam do make a board with it on - https://www.arducam.com/product/arducam ... r-depthai/
. Whilst designed for DepthAI OAK, it's using the normal Pi 22pin FFC connector. Do be a little careful as you may need an opposite sides FFC cable when all Raspberry Pi use cases use same sides 22pin cables.
I've just been looking at their AR0234 DepthAI OAK board as it gets rid of the Pivariety rubbish and gives you just the plain sensor. Unfortunately for that one it looks like they're using a clock signal from the DepthAI board, rather than having an oscillator on the camera board. The pictures of the IMX283 would appear to have an oscillator on them.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.