We have experienced HDCP failures on the ADV7626 RX side with directly cabled devices. I opened a thread 6 months ago here: ADV7626 enters an RX HDCP error loop (Ri == 0) after hot-plug with various sources.
And we thought the issue was fixed, but it has come up again with the same 780C and other commercial source devices. Some seem to fail on every hot-plug, others seem to fail every so many hotplugs; I have a feeling it is a timing issue potentially. In our system we use the ADV7626 on both receiver type devices and a transmitter type devices. Where we have multiple ADV7626-based devices daisychained, we have found that we must delay the turning on of HDCP to downstream devices, presumably, to allow them to lock the video good first, then process the HDCP, or we run into HDCP failures where the downstream ADV7626 will return Ri values of 0x00 all the time.
e.g. Device #1 must wait to enable HDCP to device #2 for 3-6 seconds after a valid video format change in order for device #2 to perform HDCP on its RX side correctly, otherwise device #2 returns Ri values of 0x00.
TMDS Stream -> ADV7626 device #1 -> ADV7626 device #2
With our receivers, if we sniff the DDC lines we also see them returning Ri values of 0x00 to the BluRay or other source equipment when the failure is occurring. I am assuming that the source device 'may' be attempting to do HDCP before we have fully locked the video potentially? I saw another thread in this forum for a different ADI part in which it was mentioned that VLOCK being fully stable is required for the part to do HDCP on the RX side correctly.
e.g. Device #1 returns Ri values of 0x00 when failing. Sometimes I will get constant AKSV update interrupts from the ADV7626 when this failure occurs, but this is not a given, and I am not sure why it occurs sometimes and not others. Sniffing the DDC lines shows the start of the HDCP negotiation goes correctly, but then the ADV7626 just returns Ri of 0x00 for the initial value, and thereafter (the values never changes).
BlueRay (or other source) -> Device #1 ADV7626
I found that someone had a similar issue here:
And a binary image was potentially sent to the end user with a fix?
We are hoping to get any potential SDK updates to RX HDCP behavior that may be available, as we re-use a very large portion of the HAL and RX/TX libs as-is. We do not use the ADV7626 as an HDCP repeater in any of our applications (i.e. we don't pass KSVs from the downstream sink back up to the RX - HDCP is managed on a system level with regards as to which encrypted streams can be shown on which attached sinks per the HDCP standard).
Searching Ri values of 0x00 in the forum in the past few months has resulted in a few hits. It seems like a 'thing' or error state in which the RX side of the transceiver can get stuck in. I know there are some undocumented 'resets' of certain sub-systems which do not appear in the HW manual or the SW register manual's but are present in the SDK. I am wondering if one exists to reset the RX HDCP engine. I know some parts implement this and others do not - sometimes its a shared EDID/HDCP reset. It seems to be 'unavailable' according to the SDK for the 7626, but maybe there is some other method? It would be a hammer approach to do this on every hot-plug, but if it fixes the issue it might be worth it.
I would think that the RX always returning 0x00 for the Ri value may be the clue as to what's going on - I would not think that this could occur for too many reasons. The DDC lines show the initial key exchange works, reading of BCAPS and BSTATUS look OK on the bus, but the first Ri returned by the ADV7626 is zero when the failure occurs.