Hi Seifelden, On Tue, 27 Oct 2026, Seifelden Abdelmonem wrote: > Caspar, did your hang happen after a suspend, or also without one, and > did you see those two messages?
Without a suspend. I checked the journal of that boot: there was no suspend between boot and the hang. I did see both messages, several times, for the earlier attempts whose stop completed. The hang itself turned out to be a different bug from yours. The hung-task report said: task .v4l2-ctl-wrapp:38440 is blocked on a mutex likely owned by task .v4l2-ctl-wrapp:38440 isp4sd_stop_stream+0x43 isp4sd_enable_streams.cold+0x8b isp4vid_qops_start_streaming isp4sd_start_stream() holds ops_mutex and its error path calls isp4sd_stop_stream(), which takes ops_mutex again. It is the same pattern Yifei Gao fixed in isp4sd_pwron_and_init(), and it is still present in mainline. It does not need the GZ302 to reproduce: start and stop a stream, then start it again without S_FMT. The stop clears the subdev pad format, so setup_output fails with "fail to get out prop" and the task deadlocks. Your setup gets past setup_output, which would explain why you don't hit it. I sent a fix to linux-media: https://lore.kernel.org/all/[email protected]/ I tested it on v7.3 on the GZ302 with a local OMNI13B1 enablement and the stock firmware: the second start now fails with EINVAL, the process exits, and the next start and stop work again. Thanks for posting the board details and the two fixes, that was useful. Same here: once AMD has OV13B10 firmware or a draft of the new driver, I'm happy to test it on my GZ302 as well. Cheers, Caspar On Tuesday, October 27th, 2026 at 10:32, Seifelden Abdelmonem <[email protected]> wrote: > 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 >
