IMX708 ccs and link frequency changes - #7605
Conversation
When the PLL is configured in DUAL_MODE (separate VT and OP trees) and the sensor's FIFOs allow derating and/or overrating, the VT pixel rate might be higher or lower than OP pixel rate. Support such usecases by allowing an optional input for the target VT pixel rate. Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
Replace the PLL dividers and multipliers hard coded into the mode and link frequency register lists with a call to the CCS PLL calculator. The pre-PLL dividers match values those currently in use, and the CCS PLL calculator generates the same register values as what's in the current mode list. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Give each mode an array of timings rather than one fixed set, so that a mode can run faster when the link has the bandwidth for it. The entry a mode lists first is its default, used for any link frequency it has no timing for, which leaves every existing mode behaving as before. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Add timings for a 960MHz link frequency, which gives the full resolution mode enough bandwidth to reach 30fps in 2-lane mode, and roughly doubles the rate of the binned modes. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
| #define IMX708_REG_IOP_PREPLLCK_DIV 0x030d | ||
| #define IMX708_REG_IOP_PLL_MPY 0x030e | ||
| #define IMX708_REG_PLL_MULT_DRIV 0x0310 | ||
| #define IMX708_PLL_MULT_DRIV_DUAL 1 |
There was a problem hiding this comment.
These are all duplicates of the CCS registers
https://elixir.bootlin.com/linux/v7.2.2/source/drivers/media/i2c/ccs/ccs-regs.h#L202-L214
Hmm, I thought I'd done the conversion to use CCS_REGxx macros, but it seems not to have been merged. Drat, it was part of #7057 which got stalled.
If the first patch from there still cherry-picks cleanly, then can we do that one first?
There was a problem hiding this comment.
In case that one doesn't apply cleanly, I've done the same in my branch relatively early in the git log, so maybe that would apply cleanly.
See f1a4b608ea in rpi/imx708
| ret = imx708_write_reg(imx708, IMX708_REG_PLL_MULT_DRIV, | ||
| IMX708_REG_VALUE_08BIT, | ||
| IMX708_PLL_MULT_DRIV_DUAL); | ||
| if (!ret) |
There was a problem hiding this comment.
Using ccs_reg gets rid of this pattern as you pass in a pointer to ret, and it aborts if it is set.
| unsigned int i; | ||
|
|
||
| for (i = 1; i < ARRAY_SIZE(mode->timings); i++) { | ||
| if (mode->timings[i].link_frequency == link_freq) |
There was a problem hiding this comment.
mode->timings[i].link_frequency <= link_freq?
No reason why selecting a link frequency of 963MHz should preclude selecting your faster rate.
(Ideally we'd work out the threshold point for switching to the more ambitious timing, and ditch the specific link frequencies and allow any achievable values).
3 participants
No description provided.