Hi Maxime, On 28/06/2024 10:50, Maxime Ripard wrote: > 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. You forgot to attach the logs :-) I don't off-hand see a race condition. But there is an important thing to remember: the HPD is only pulled high if the 5V line from the source is also high. I.e., if no source is detected, then the HPD remains low. I don't think you state what the source device is, but make sure it has 5V high. If it is low, or it toggles the 5V for some reason, then that might be related to the problem. But without logs it is hard to tell. Regards, Hans > > 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
