Imx708 link frequency of 960MHz. - #7599
Conversation
Move the line length, pixel rate and default vblank of each mode into a list of timings, one per link frequency that the mode has a timing for, and program the line length and pixel rate registers from the matching entry at stream on. Only one timing is defined per mode here, so there is no change in existing behaviour. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Add timings for a 960MHz link frequency, which gives the full resolution mode the abliity to run at 30fps in a 2-lane configuration. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
|
@jailuthra and @6by9 FYI. |
| * and a mode can stream once but then fail to start again. Each timing below | ||
| * keeps at least 4% in hand, that is | ||
| * | ||
| * line_length_pix / pixel_rate > 1.04 * width * bpp / link bandwidth |
There was a problem hiding this comment.
Ah I was working on something similar for the upstream version where we would want to support any arbitrary crop/binning configuration.
The FIFO between VT and OP is undocumented as far as I understand, I'll try to use this formula and let you know if that breaks something.
There was a problem hiding this comment.
Ah I was working on something similar for the upstream version where we would want to support any arbitrary crop/binning configuration.
Watch out as line_length_pck is very constrained on imx708. Arbitrary cropping on this particular sensor has limited gain.
The FIFO between VT and OP is undocumented as far as I understand, I'll try to use this formula and let you know if that breaks something.
Agreed they never document it for depth or trigger point, but I've never had it go wrong.
As I commented on the imx908 review, the MIPI link requires some time per line for:
- transition to/from LP on the data lanes (and clock lane?)
- for line start and end short packets
- for packet headers
hence you don't have the full bandwidth available for image data transfer. That's why Naush has allowed a 4% margin.
It could be calculated, but generally it's not worth the effort.
6by9
left a comment
6by9
left a comment
There was a problem hiding this comment.
I'm not a fan, but I wonder if you're better off using the CCS PLL helpers to compute these rather than hard coding.
Jai has done most of the work for us in https://lore.kernel.org/linux-media/20260807-imx708-v2-3-7d3d7b57779d@ideasonboard.com/
Constrain the predividers to those we currently use and you'll avoid the potential for regressions there.
| * and a mode can stream once but then fail to start again. Each timing below | ||
| * keeps at least 4% in hand, that is | ||
| * | ||
| * line_length_pix / pixel_rate > 1.04 * width * bpp / link bandwidth |
There was a problem hiding this comment.
Ah I was working on something similar for the upstream version where we would want to support any arbitrary crop/binning configuration.
Watch out as line_length_pck is very constrained on imx708. Arbitrary cropping on this particular sensor has limited gain.
The FIFO between VT and OP is undocumented as far as I understand, I'll try to use this formula and let you know if that breaks something.
Agreed they never document it for depth or trigger point, but I've never had it go wrong.
As I commented on the imx908 review, the MIPI link requires some time per line for:
- transition to/from LP on the data lanes (and clock lane?)
- for line start and end short packets
- for packet headers
hence you don't have the full bandwidth available for image data transfer. That's why Naush has allowed a 4% margin.
It could be calculated, but generally it's not worth the effort.
I'm not convinced that we can do this and keep the exact same default PLL configuration in the default case, but I'll check in more detail. ccs-pll assumes |
@naushir I had updated the CCS PLL helper to allow that: I've used that in my WIP branch (on top of raw sensor model, implementing arbitrary crop and binning too) https://github.com/jailuthra/linux/commits/rpi/imx708/ With that change I can now pass a target pixel_rate_pixel_array while populating the struct, and the PLL configuration came out to be effectively the same as what was hardcoded before. The simple change I made has one shortcoming though: it fails if the target rate isn't possible rather than giving a close one. I didn't want to mess with the PLL calculation logic too much (just yet) But I think I could try implementing something similar to what you've done here, calculating the "best" possible pixel rate and LLP value with 4.8Mhz step size for the pixel rate and 5216/2608 step size for LLP for any given crop + binning config. With the 4% margin ofc.
@6by9 I agree it's a bit cumbersome. I am trying arbitrary cropping, even if LLP is constrained, as cutting the FLL size can increase the FPS considerably, which is more important than FOV for some applications. I will try for the rest of today to get something working, else I'll fallback to the 3 modes that were used before. It's tricky because some registers (0x34xx and 0x3cxx) are undocumented but I suspect they change depending upon the windowing. |
I'll update this PR (or maybe open a new one...) with the CCS rework including your patch to see what it looks like. |
|
#7605 adds the CCS helper usage. |
3 participants
No description provided.