Hi On Tue, 2 Jul 2024 at 15:23, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > Hi, > > On Mon, Jul 01, 2024 at 10:29:55AM GMT, Hans Verkuil wrote: > > 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 :-) > > Of course I did :) > > It should be attached this time > > > I don't off-hand see a race condition. > > Yeah, me neither. The code looked sane to me, hence that mail. > > > 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. > > It's a RaspberryPi. I was looking at the register and it doesn't detect > HPD being high, but I'll try to see if I can find a testpoint to read > the level. FWIW The Pi has the HDMI 5V connected to the main 5V rail via an RT9742SNGV [1] or AP2331W [2] for over-current protection. It should never get dropped under normal conditions. If you're using an Auvidea B10x board for the TC358743, then the recent revisions have "cable detect" available on the 8pin header pin 3 [3]. I'm not aware of a point where you can probe the HPD output easily. Dave [1] https://www.richtek.com/assets/product_file/RT9742/DS9742-10.pdf [2] https://www.diodes.com/assets/Datasheets/AP2331.pdf [3] https://auvidea.eu/download/manual/B10x_technical_reference_1.4.pdf > Maxime
