4lane support for IMX708 #7057
Draft
4lane support for IMX708 #7057
+558
−658
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6by9
force-pushed
the
rpi-6.12.y-imx708-4lane
branch
2 times, most recently
from
3263f1b to
b79f8de
Compare
|
Bah, I hate the handling of 64bit division on 32bit kernels. Hopefully resolved now. |
6by9
force-pushed
the
rpi-6.12.y-imx708-4lane
branch
from
b79f8de to
6388ea2
Compare
naushir
approved these changes
Sep 22, 2025
V4L2_CCI removes the duplication of handling sensor registers that represent 8, 16, 24, 32, or 64 bit values, and is preferred over sensor drivers hard coding register widths. Switch imx708 to use this way of addressing registers. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Exposure, analogue gain, and digital gain are all being set from the tables of registers as well as via the control handler. The value in the tables is therefore redundant, so remove them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Rather than the 3 hard coded PLL settings for 447, 450, and 453MHz, compute the PLL settings based on device tree. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The line_length_pix value was duplicated between the register tables and the mode descriptor, so remove from the tables and set it programmatically. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Currently this is still at the same pixel rates and hence frame rates as over 2 lanes. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Removing more duplication between register tables and mode descriptors, compute the pixel rate registers rather than hard coding the PLL multipliers in the register tables. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As the driver now supports 4 data lane readout, and it as an option to the overlay Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
6by9
force-pushed
the
rpi-6.12.y-imx708-4lane
branch
from
6388ea2 to
fac260a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This gets IMX708 working in 4 lane mode.
It hasn't yet changed the frame rates achievable, but has made it easier in computing the PLL register settings based on the configured values.
Whilst we could try to do something clever in automatically computing values, I'd probably lean towards having an array for
line_length_pixandpixel_ratefor each mode, with one set of values for 2 lanes and another for 4 lanes. At least that way we can guarantee that the value combinations work, but does limit some of the gain in increasing the link frequency.I haven't added any validation on the link frequency actually making a usable system. Adding a check later that the line time of the pixel array is greater than that of the MIPI link would probably be beneficial.