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
No description provided.