Repository navigation
Conversation
4f58560 to
e8f0ba8
Compare
|
@6by9 and @jailuthra are you both ok for me to merge this change? |
6by9
left a comment
6by9
left a comment
There was a problem hiding this comment.
Sorry, thought I'd submitted this review.
The last two patches feel awkward as it is still defining fixed link frequencies.
Can we do similar to imx355 where as long as the link frequency is valid, we adopt it? In this case it will need to have a list of min link_frequency for each step of line_length_pck because imx708 wants discrete values. Perhaps we do that as a refinement if it doesn't fall out easily.
|
I've just noticed that 4dba86f in my 4 lane support patch set does change it to validate the DT link frequency, and then advertise that value. My validation is via computation rather than ccs_pll though. |
|
All fixed. @jailuthra I've updated your patches a bit and added my SoB tag to them. I'll work on the more flexible link-frequency updates on top of this. |
e8f0ba8 to
8a2118d
Compare
|
@6by9 ready for you to have another check. |
6by9
left a comment
6by9
left a comment
There was a problem hiding this comment.
Very minor nit picks. It'll do as is, but there are some cleanups possible.
| { CCI_REG8(0x3cbd), 0x3c }, | ||
| { CCI_REG8(0x3cbe), 0x00 }, | ||
| { CCI_REG8(0x3cbf), 0x00 }, | ||
| { CCI_REG8(0x0202), 0x0a }, |
There was a problem hiding this comment.
Additional clean up not required for this patchset:
- merge the relevant registers into CCI_REG16.
- 0x0202/3 is actually coarse integration time, defined as IMX708_REG_EXPOSURE and set by V4L2_CID_EXPOSURE, so these values have no business being in the modes table.
There was a problem hiding this comment.
Remove the exposure regs, but I'll leave out the folding into CCI_REG16() as that will severely trample Jai's patch.
| .pixel_rate = 595200000, | ||
| .timings = { | ||
| { | ||
| .line_length_pix = 0x3d20, |
There was a problem hiding this comment.
Is there a reason for the line length to be in hex?
There was a problem hiding this comment.
No specific reason, just following similar convention of reg values as hex.
…ites Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
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> Signed-off-by: Naushir Patuck <naush@raspberrypi.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, describing the sensor clock tree limits from its manual. The pre-PLL dividers are pinned to the values those register lists used, so the tree the calculator arrives at is the one the driver has always programmed, which was confirmed against every mode at every link frequency. 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. A mode uses the higest link frequency timings specified. 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 and roughly doubles the rate of the binned modes. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
8a2118d to
9c32129
Compare
Replace the DKMS imx708 driver's fixed 2-lane timings with a table of timings per link frequency, with separate timings for two and four data lanes, after Raspberry Pi's imx708 link frequency PR (raspberrypi/linux#7605). 4608x2592 now runs at up to 60 fps on four lanes. - Two or four data lanes, read from the device tree. - Each mode has a fallback timing (the Pi's) plus a row per link frequency: 447, 549, 750, 960 and 1002 MHz. A row holds a timing for two lanes and one for four, at the same pixel rate with half the line length on four lanes. - The PLL registers are static values per timing and per link frequency (no CCS PLL calculator). LINE_LENGTH_PCK is written from the timing. - Each row keeps about 0.5 us of idle link time per line: a 2304x1296 line that left 0.34 us idle made the next stream get no frames until a reboot. - 4608x2592: 30 fps at 549 MHz, 45 at 750 MHz and 60 at 1002 MHz on four lanes. 2304x1296 reaches 172 fps at 750 MHz and 220 at 1002 MHz. - A failed line length write is reported as one, not as a PLL failure. Tested with raw captures on an Orange Pi 5B (CAM1, CAM2) and a ROCK 5B+ (CAM0): four lanes at 750, 960 and 1002 MHz, and the 450 MHz two-lane default, match the table. Not run on hardware: the other two-lane rows, four lanes at 447 and 549 MHz, and HDR. Processed streams above about 115 fps still stall in the rkisp2 interrupt path; this is not changed here. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
No description provided.