Repository navigation
anyka: name every generation's part, report media memory, detect the sensor - #273
Merged
Merged
Conversation
Two families the Anyka EV200/EV300 SDKs drive that no probe knew: - PrimeSensor PS5250/5260/5268/5270/5280: ID at byte registers 0x00/0x01 of bank 0, which 0xef selects. The bank is put back as it was found, as the SuperPix probe does with its page. - BYD BF3703: ID 0x3703 at byte registers 0xfc/0xfd. They are probed last, and only at addresses a HAL lists for them.
…sensor
Model. A device tree's root compatible names the part outright
("anyka,ak3918ev200", "anyka,ak3919ev330") and now wins; OpenIPC's
kernels and the EV330 vendor ones have one. Otherwise the board string
does, but it often names only the package: "AK3918E80PIN" is an EV200 on
OpenIPC's board and an EV300 on another camera, "AK3918E" a V380E2's
EV200. The chip ID's generation now completes it, so these report
AK3918EV200 / AK3918EV300 rather than the package. 0x20120100 is both
the Aimer39 AK3918's and some EV200s': the board string or device tree
puts it in a generation of its own (family ak3918). The AK3918AV130
keeps its ID at SYSCTRL + 0x3fc (0x565735xx, revisions A and B) and is
now read there.
Memory. OpenIPC's kernels take mem= alone and give the ISP the rest of
the memory the device tree declares, so with no memsize= the total is
the device tree's /memory and media what the kernel did not get.
Sensor. Anyka sensors answer I2C only while the camera driver has them
clocked and out of reset, and the drivers power them down after their
own probe, so ipctool found none. On EV200/EV300 the HAL now starts the
CIS clock as the drivers do (SYSCTRL 0x18 from the peripheral PLL,
24 MHz) and pulses the reset/power-down GPIOs the device tree names for
the camera, then puts back exactly what it changed. When the clock is
already running a pipeline is, and nothing is touched. The address
table gains the OV9712's 0x60, the GC1024's 0x78, the EV330 GC4653's
0x52, SmartSens' 0x64, ImageDesign, PrimeSensor and BYD.
On an AK3918EV200 (OpenIPC, SC1345): model AK3918EV200 (was
AK3918E80PIN), ram total 64M / media 24M, sensor SmartSens SC1345 at
0x60 (was none), ipcinfo -s sc1345; the clock and GPIO registers read
the same before and after. With a capture running it reads the sensor
without touching the clock and the stream keeps 15 fps. The naming was
checked against the boot logs of gwell and V380E2 EV200, an AK3916EV301
and EV330 vendor firmware under qemu-hisilicon; anyka_test covers it.
The _A/_B suffix came from 0x3020, which tells two silicon revisions of the part apart -- the Anyka driver for this ID picks its init variant by it -- rather than two parts. A name that changes with the revision makes a poor key for anything looked up by sensor name, such as a tuning file.
EV330 board strings say "AK39EV330", which no part is called. Where the device tree does not name the part either, report the generation the way the vendor kernel's CPU banner does, "AK39XXEV330", rather than the board's short form.
PR Summary by QodoIdentify Anyka parts, report media memory, and probe powered sensors
AI Description
Diagram
High-Level Assessment
Files changed (9)
|
Code Review by Qodo
1.
|
universal_i2c_write_register() ignored `data` and wrote `data_width` bytes of the register address, so a write through the generic HAL stored nothing: `ipctool i2cset` did nothing on those SoCs, the SuperPix probe's page select and restore never reached the sensor, and with two-byte addresses not even the whole address went out. Send the address and then the value, most significant byte first, as one write.
- The probe calls hal_cleanup() only after it has opened the bus, so a power-up for an adapter that does not open was never undone. Arm only when the adapter opens. - Take the reset/power-down GPIOs from the camera node under the adapter being probed (/sys/bus/i2c/devices/i2c-N/of_node), not from the first camera node anywhere. Without that link, use the device tree's camera only when there is exactly one, and touch no pin otherwise. - PrimeSensor: give up when the bank cannot be selected rather than read the ID from the wrong bank, and retry the restore once. Raised by the Qodo review of #273. Re-run on the AK3918EV200: the adapter resolves to i2c0@20150000 and its camera@37, SC1345 is found, and the clock and GPIO registers read the same before and after.
Collaborator
Author
|
On the Qodo review, all four fixed:
Re-run on the AK3918EV200: the adapter resolves to |
dimerr
marked this pull request as draft
November 8, 2026 12:23
dimerr
marked this pull request as ready for review
November 8, 2026 12:23
ipcinfo grew 4985 bytes, over the size check's 1024, for a family few cameras use. It now grows 968 with every vendor built in and 5 with none. The sensor power-up and the PrimeSensor and BYD detectors move behind !STANDALONE_LIBRARY: ipctool keeps them, ipcinfo does not, so ipcinfo -s names an Anyka sensor only while something already clocks it. Neither sensor has a tuning in the firmware package. The part naming stays in ipcinfo, since ipcinfo -c has to be right, but takes the device tree's first compatible through line_from_file(), and the suffix from the generation constant instead of a table of strings. An Aimer39 is now told by the bare part its board or device tree names.
ipcinfo is how OpenIPC finds the sensor, so it cannot leave the power-up to ipctool. It now starts the CIS clock itself and grows 728 bytes with every vendor built in, 5 with none. The sensor drivers' power-off leaves reset an input, so on a board with no pwdn-gpio the sensor answers once clocked. ipctool also pulses the camera GPIOs. Every write goes through one helper that remembers the register's old value, and cleanup writes those back. ipcinfo takes the part from the device tree and otherwise the board string as before; working a part number out of a vendor board string, and the AV130 and Aimer39 generations, stay in ipctool.
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.
Anyka: name every generation's part, report media memory, and detect the sensor. Plus two new sensor families and SC2145H without a revision suffix.
Chip
anyka,ak3918ev200,anyka,ak3919ev330) wins. OpenIPC's kernels and the EV330 vendor kernels have one.AK3918E80PINis an EV200 on one board (Cloud39EV2_…) and an EV300 on another (Cloud39EV3_…), and a V380E2 saysCloud39E_AK3918E+H42. The chip ID's generation completes the name.0x20120100is both the Aimer39 AK3918's and some EV200s'. A board string or device tree saying Aimer39 puts it in its own family,ak3918.0x080003fc(0x565735xx).AK39XXEV330, as the vendor CPU banner does. The board string'sAK39EV330is not a part.Memory
OpenIPC's kernels take
mem=alone, so withoutmemsize=the total is the device tree's/memoryand media is what the kernel did not get.Sensor
Anyka sensors answer I2C only while the camera driver has them clocked and out of reset, and the drivers power them down after their own probe. On EV200/EV300,
hal_enable_sensor_clocknow does what the drivers do:0x18from the peripheral PLL, 24 MHz);hal_cleanupthen puts back exactly what it changed. When the clock is already running a pipeline is, and nothing is touched.The address table gains OV9712 at 0x60, GC1024 at 0x78, the EV330 GC4653 at 0x52, SmartSens at 0x64, ImageDesign, PrimeSensor and BYD.
Sensors
SC2145H. The_A/_Bsuffix came from 0x3020, a silicon revision the Anyka driver uses to pick its init variant, not a different part.sensors_golden.txtis updated.Tested
On an AK3918EV200 (OpenIPC firmware, SC1345):
The CIS clock and GPIO registers read the same before and after a probe (
0x08000018=0x00106231, GPIO dir0x010000C0, out0x00000001). With a capture streaming, the clock is running, ipctool reads the sensor without touching anything, and the stream keeps 15 fps.The naming for the other generations is covered by
anyka_test, with inputs from real boot logs: gwell and V380E2 EV200, an AK3916EV301, and EV330 vendor firmware, booted under qemu-hisilicon. Those generations were not run on hardware.sensors_testpasses.Size
ipcinfogrows 728 bytes withIPCHW_VENDORS=alland 5 withnone, measured the way the size check does. It powers the sensor up by starting the CIS clock, and takes the part from the device tree.ipctooladditionally pulses the camera GPIOs, works a part number out of a vendor kernel's board string, and knows PrimeSensor and BYD.The sensor drivers' power-off leaves reset an input, so the clock is enough on the board tested, whose device tree declares no
pwdn-gpio. On a board that has that pin the drivers assert it, and there onlyipctoolwould find the sensor.Known limit: an AK3916EV301 whose vendor kernel calls itself
AK3918EV300reports as AK3918EV300. Nothing readable in software tells the two apart.Formatting was done by hand (no clang-format on the build host). The arm32 build is clean; mips32 and arm64 are left to CI.