IMX415 support - rpi-6.6.y #6582
Conversation
Commit b814b5b upstream. Complete the list from "INCK Setting" section in IMX415-AAQR-C (Rev. E19504, 2019/05/21). For consistency suffix all lane rate values by UL, which is needed for 2376000000 anyway. Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
This also requires that the ranges for the exposure control are updated. Signed-off-by: Dave Stevenson <[email protected]>
The control of HMAX documented in the datasheet is consistent with being in terms of a scaled INCK, being always 72MHz or 74.25MHz. It is NOT link frequency dependent, but the minimum value for HMAX is dictated by the link frequency. If PIXEL_RATE is defined as being 12 times the 72 or 74.25MHz, and all values are scaled down again when writing HMAX, then the numbers all work out regardless of INCK or link frequency. Retain an hmax_min (set to the same value as the previous fixed hmax register value) to set as the default value to avoid changing the behaviour for existing users. Signed-off-by: Dave Stevenson <[email protected]>
The link frequencies are equally valid in 2 or 4 lane modes, but they change the hmax_min value for the mode as the MIPI block has to have sufficient time to send the pixel data for each line. Remove the association with number of lanes, and add hmax_min configuration for both lane options. Signed-off-by: Dave Stevenson <[email protected]>
|
"Don't worry about forward porting to 6.12 / 6.13" translates to "Do worry about preventing the semi-automatic forward porting to 6.12". The sooner we can merge this, the more likely I am to remember... |
This PR title updated to denote 6.6, and #6583 created with the 6.12 patches. Hopefully those steps will help with the memory. d5df1c7 in 6.10 and above will cause oodles of conflicts with this series, so that would also likely jog the memory if you tried forward-porting. I'm happy with the series, it's just if NP or DAP have any views or notice issues that would hold things up. |
|
Can't see anything obviously wrong with the drive code changes! |
Thanks. I'll throw them upstream in the next couple of days. |
See: raspberrypi/linux#6579 kernel: BCM2711, BCM2712 and RP1 UARTs are r1p5 See: raspberrypi/linux#6587 kernel: IMX415 support - rpi-6.6.y See: raspberrypi/linux#6582 kernel: PCI: brcmstb: don't use ASPM state defines for register bits See: raspberrypi/linux#6588 kernel: allo-piano-dac-plus: Trial patches for the second part of issue 6527 See: raspberrypi/linux#6590 kernel: configs: add CONFIG_CRYPTO_NHPOLY1305_NEON=m See: raspberrypi/linux#6594
See: raspberrypi/linux#6579 kernel: BCM2711, BCM2712 and RP1 UARTs are r1p5 See: raspberrypi/linux#6587 kernel: IMX415 support - rpi-6.6.y See: raspberrypi/linux#6582 kernel: PCI: brcmstb: don't use ASPM state defines for register bits See: raspberrypi/linux#6588 kernel: allo-piano-dac-plus: Trial patches for the second part of issue 6527 See: raspberrypi/linux#6590 kernel: configs: add CONFIG_CRYPTO_NHPOLY1305_NEON=m See: raspberrypi/linux#6594
Minor tweaks to the mainline imx415 driver to make it work with the Pi and libcamera. I will send them upstream in due course.
Tested with a https://www.waveshare.com/imx415-98-ir-cut-camera.htm module. @davidplowman now has one to do the tuning.
Don't worry about forward porting to 6.12 / 6.13 - I have a 6.12 branch with the required changes there, but was trying to resolve the general CFE issues there first.