OV5647 link frequency control #6423
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To make comparisons of the mode registers easier, put the registers for the binned and VGA modes in the same order as the others. Signed-off-by: Dave Stevenson <[email protected]>
There are many registers in common between all the modes. Pull those out into one common table. Signed-off-by: Dave Stevenson <[email protected]>
…ed modes In order to simplify the driver slightly, use the same PLL configuration, and hence pixel rate and link frequency (to be added) for the full, 1080p, and binned modes. Signed-off-by: Dave Stevenson <[email protected]>
The link frequency can vary between modes, so add it as a control. Signed-off-by: Dave Stevenson <[email protected]>
naushir
reviewed
Oct 17, 2024
|
why are link frequencyes not added also to the device tree? |
The driver doesn't check the link frequencies defined in devicetree, so there was little point in updating DT at this stage. The 297MHz value currently in there is totally wrong for this sensor. As I've said, there will be a follow up patch that will read the link frequencies and configure the clock setup accordingly. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Oct 18, 2024
See: raspberrypi/linux#6421 kernel: Fixes for video-mux with Pi5 See: raspberrypi/linux#6410 kernel: OV5647 link frequency control See: raspberrypi/linux#6423 kernel: CQE incremental fixes part 2 See: raspberrypi/linux#6419
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
Oct 18, 2024
See: raspberrypi/linux#6421 kernel: Fixes for video-mux with Pi5 See: raspberrypi/linux#6410 kernel: OV5647 link frequency control See: raspberrypi/linux#6423 kernel: CQE incremental fixes part 2 See: raspberrypi/linux#6419
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I found I had the OV spreadsheet for PLL config, so could determine the link frequency.
I don't know why we had a different clock setup for 1080p cropped and binned modes vs the full res. Increasing it that fraction gives a slightly higher max frame rate in those modes (32.81 fps at 1080p and 46.34fps at 1296x972), and removes one extra link frequency.
There will hopefully be a follow-up to these which will add selection of the slower rate for 6sec exposures.
Simplest approach is to set {0x3037, 0x06} to halve all the clocks (default is 0x03). Arranging it will be the awkward one - selection via link frequency in DT is the cleanest approach, but the current overlays actually have a single incorrect value defined, so we'll need a fallback.
(I will find a few minutes to send these patches upstream in due course).