Hi Team,
SN65DSI86 IRQ supports HPD events but does it also support cable removal events? We saw IRQ being asserted (turned high) when plugging in cable but it did not go back to low when we removed cable.
Thanks.
Roy
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Team,
SN65DSI86 IRQ supports HPD events but does it also support cable removal events? We saw IRQ being asserted (turned high) when plugging in cable but it did not go back to low when we removed cable.
Thanks.
Roy
Hi Team,
We found that the reason why IRQ kept asserting high might be due to register 0xF5. Since IRQ asserts when any of the bit field changes to high, upon cable insertion, it will always be high no matter the cable is removed or re-plugged. However, this stops IRQ from being transparent on reflecting the actual cable status. Is there a way to fix this?
Thanks!
Roy
Hi Team,
We found that the reason why IRQ kept asserting high might be due to register 0xF5. Since IRQ asserts when any of the bit field changes to high, upon cable insertion, it will always be high no matter the cable is removed or re-plugged. However, this stops IRQ from being transparent on reflecting the actual cable status. Is there a way to fix this?
Thanks!
Roy
Roy
Please refer to section 8.4.5.1 HPD (Hot Plug/Unplug Detection).
Address 0xF5 only reports status of HPD when HPD input is enabled (register 0x5C bit 0 (HPD_DISABLE) is cleared).
When cable is removed, are you seeing HPD_REMOVAL (bit 2 of Register 0xF5) being set?
Are you also enable the HPD_REMOVAL _EN (bit 2 of Register 0xE6)?
Thanks
David
Hi David,
We have already been able to see IRQ work. It's just that the IRQ state doesn't change after it was first asserted.
Like I said, IRQ changed to high when we inserted the cable; but it didn't return to low when we removed the cable.
Is this an expected behavior? Could you please verify this with an EVM?
Thanks!
Roy
Roy
Did they clear the register 0xF5 by writing to 0xFF to it?
Thanks
David
Hi David,
I didn't know that 0xFF is what we need to clear 0xF5. I'll give it a try then let you know.
Thanks.
Roy