Hi Hans,
I've been playing with the unicam driver and the TC358743 HDMI -> CSI
bridge recently.
The program I was testing it with had a (arguably suboptimal) pattern
where it would (in a non-blocking way):
In a loop:
- set EDID
- In a loop:
- call query_dv_timings
- if we have a timing matching the mode we expect:
- break the loop
- Call s_dv_timings
- Call s_fmt
- Call reqbufs
- Query and Queue all requested buffers
- Call streamon
- In a loop:
- Dequeue the events
- If there's a resolution change:
- Call streamoff
- Call reqbufs with 0 buffers to clear all buffers
- Restart the entire sequence
- Dequeue a buffer
- Queue it again
This works mostly fine, but when trying to capture the boot of a device
connected on the other end, I'm always getting at some point an
resolution change event in the very first iteration.
The event itself looks fine: there's no remaining events at any point,
the sequence is correct, etc. However, this puts the s_edid call super
close to streamoff and the next s_edid call.
And it looks like the tc358743 driver doesn't like that very much and
the HPD pin ends up in the wrong state on the next iteration: both the
driver itself and the device at the other reports the hotplug pin as
being low, and thus, not connected.
I'm not entirely sure what is the reason, but I suspect a race in:
https://elixir.bootlin.com/linux/v6.9.3/source/drivers/media/i2c/tc358743.c#L403
Possibly due to the 100ms delay?
I've attached a kernel log with debug logs from both v4l2 and the driver
enabled.
The occurence I'm talking about starts at 149.457319, and you can see
that it looks like there's less than 100ms between the s_edid call
(149.488760) and the streamoff call (149.553513)
Thanks!
Maxime
Attachment:
signature.asc
Description: PGP signature
