Repository navigation
sensors: probing a streaming SP2305 no longer turns its picture white - #238
Merged
Merged
Conversation
On HiSilicon the GalaxyCore probe runs at 0x78, which is the same 7-bit address as the SuperPix probe's 0x79 -- an SP2305 / OV2735. Its first read was a two-byte address, 0x3f0. That sensor has one-byte addresses, so it took the read as a write: 0xf0, then 0xf1, into register 0x03, the high byte of its exposure. On a camera that was streaming, the picture went white and stayed white -- the sensor's driver rewrites the exposure only when it changes, and in a bright scene it does not -- until the streamer restarted. `ipctool -s` and `ipcinfo --short-sensor` both did it, every time. - SuperPix is probed before GalaxyCore. It only ever reads and writes a byte-address at a time, so a SuperPix-register-family part is named before any two-byte address reaches it. - GalaxyCore reads its byte-address ID first and tries the two-byte one only for what that does not name. The GC1004 that 0x78 was added for has one-byte addresses and its exposure at 0x03 too. - The SuperPix probe selects page 0 with one data byte, not two (the second went on into 0xFE), and puts back the page it found. A streamer writes the exposure to page 1 without selecting it every time. The fingerprint is unchanged: every ID names the same part as before. sensors_test gains a scripted SP2305 on page 1 at an address shared with a GalaxyCore probe; against the old code it sees two two-byte reads, a two-byte page write and page 0 left selected. Measured on hi3516ev300 + SP2305/OV2735 while streaming under an LED floodlight: `ipctool -s`, `ipcinfo --short-sensor` and a full report name the sensor OV2735, and the exposure register and the picture are unchanged. Before, each of the first two left it white.
PR Summary by QodoPrevent sensor probing from whitening a streaming SP2305
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all |
This file contains hidden or 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
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.
What happened
On HiSilicon the GalaxyCore probe runs at
0x78, the same 7-bit address as the SuperPix probe's0x79, which is an SP2305 / OV2735. The GalaxyCore probe's first read used a two-byte register address,0x3f0.The SP2305 has one-byte addresses, so it took that read as a write:
0xf0, then0xf1, into register0x03. That is the high byte of its exposure.On a camera that was streaming, the picture went white and stayed white until the streamer restarted. The sensor driver rewrites the exposure only when it changes, and in a bright scene it doesn't (OpenIPC/openhisilicon#255 fixes that side).
ipctool -sandipcinfo --short-sensorboth did it, every time. This is very likely the random white-out in OpenIPC/majestic#295.Changes
0xf0/0xf1) and only falls back to the two-byte one for an ID that doesn't name a part. The GC1004 that0x78was added for has one-byte addresses, and its exposure is at0x03too.0xFE), and puts back the page it found. A streamer writes the exposure to page 1 without reselecting the page every time.Tests
src/sensors_golden.txtis unchanged; every ID names the same part as before.sensors_test: a scripted SP2305 on page 1, at an address shared with a GalaxyCore probe.pr-build-check.ymlpass.On hardware
hi3516ev300 + SP2305/OV2735, streaming under an LED floodlight, auto-exposure at ~130 lines:
ipctool -s0x03 = 0xf1ov2735_i2c, register and picture unchangedipcinfo --short-sensorov2735, unchangedipctoolreport0x79, unchanged