Hi Caspar, Pratap, all, I have the same laptop (GZ302EA) and have been working on the rear camera as well. Some results that may help this thread:
The rear camera streams on my machine (NV12 1920x1080, about 30 fps) with an out-of-tree setup. As Pratap explained, the stock linux-firmware image does not start this sensor; on my machine the camera runs with ISP firmware and sensor setup data from my own Windows driver installation, read from the Windows partition of that machine. I do not redistribute any of it. The firmware alone was not enough: getting a picture also took the board configuration and GPIO wiring below, changes in the isp4 capture driver and in the sensor setup, and the two fixes I sent to linux-media (link below). Board details as seen from Linux on the GZ302: - The sensor is \_SB.CAMB (_HID "OMNI13B1") in an SSDT, without _CRS, so ACPI describes no GPIO, clock or regulator for it. - I2C on the ISP's bus: the sensor answers at 0x10 once it is powered and clocked; the focus motor is at 0x0c and the module EEPROM at 0x50, matching Caspar's scan. My guess is that with the stock firmware the sensor never gets powered, because SET_STREAM_CONFIG fails before that, which would explain why 0x10 did not ACK. - Sensor reset: amdisp-pinctrl GPIO 0, active low (the "reset" GPIO of the ov13b10 driver), the same ISP GPIO as the OV05C10 enable line. - enable_isp (AMDI0030:00 pin 85, as for OMNI5C10): not confirmed on this board. No ACPI device claims the pin, and the ISP also boots with it left undriven. - Sensor clock: 24 MHz, as declared for the OV05C10 platform on the same ISP; four CSI-2 lanes. On the hang Caspar saw when stopping the stream, possibly related: when a stream is running across s2idle (start a stream, then "rtcwake -m mem -s 20"), no further frame arrives after resume, and stopping the stream logs "fail to disable stream" and "fail to stop stream" because the commands time out. On my machine the timeouts return and the device can be closed; the driver has no system-sleep callbacks. Caspar, did your hang happen after a suspend, or also without one, and did you see those two messages? I sent two small isp4 fixes found on this machine to linux-media: https://lore.kernel.org/all/[email protected]/ After the merge window I plan to post the board data above as an RFC (amdgpu OMNI13B1 entry and GPIO lookups, amd_isp4 board configuration), explicitly not for merging until the firmware supports the sensor. Pratap, you mentioned contacting testers once there is OV13B10 firmware or a sensor-agnostic draft: I would be glad to test both on the GZ302 and can share logs, ACPI tables and v4l2-compliance output. My out-of-tree code (capture-driver changes, the board configuration and the test scripts) is in a repository I can share on request. One question for the sensor-agnostic driver: will a board like this one describe its sensor through amdgpu and amd_isp4 tables as today, or will the firmware take the sensor setup from another source? Thanks, Seifelden
