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.

Authentication when input source changes and wait time for KSV RDY bit

Hello,

I added some comments to the questions so that I would be more understandable for you.  Would you please reply yo me ASAP since my customer has been waiting for a long time?

My customer uses UH927 and UH928 and has 2 issues right now and I have a couple of questions which are related to the tickets from our disty FAE.

http://e2e.ti.com/support/interface/high_speed_interface/f/138/t/375714.aspx

http://e2e.ti.com/support/interface/high_speed_interface/f/138/t/375719.aspx

 

The first issue is that my customer sees blue screen when the input source changes from HDCP digital to no HDCP analog.  Their current system is that starting without HDCP(when it isn't a HDCP content), authenticating when HCDP content is connected and keeping protecting contents if the input source changes to analog.  However if the source changes to analog like AUX input, they see IS_AUTH_FAIL=1 with blue screen.

Boot
-> No HDCP authentication (unless HDCP is required)
-> HDCP authentication when the source changes to HDCP
-> Continues protecting source if it is analog like AUX input
-> IS_AUTH_FAIL=1with blue screen

The other issue is KSV RDY bit in HDCP_STS register.  They need to wait for around 5ms or so to get the correct KSV RDY bit when the interrupt is asserted.  They don't need wait time for the other interrupt status bit.

Questions

=========

1. Does my customer need to perform authentication again if the input source changes even if it is analog?  Would you please tell me the correct procedure for HDCP?  I mean in which case, the authetication has to be performed and doesn't have to be done?
2. Is KSV RDY bit required a wait time unlike the other bits?  If so, how long will it be?  Do you see any issues on checking the interrupt status?


 

  • Kawasaki-san,

    I apologize for the delay. 

    For the first question - in theory the authentication would stay active when the source changes to non-protected content. What may be happening, however, is that during the transition the 928 loses lock (due to the change in PCLK). That would cause the 927 to lose authentication. The 927 would try to complete authentication again, but may be getting stuck at the KSV_RDY state waiting for the source to validate the keys and finish authentication. This would cause the blue screen to continue being output from the 928.

    When switching sources, a good practice would be to enable AV_MUTE on the 927 (0xC2[0]) to hide any glitches caused by the transition. They could also disable authentication if it is no longer required. Then after the transition, they could disable AV_MUTE. 

    For the second question - what interrupts are they configured to trigger on? Register 0xC6 configures which conditions will trigger interrupts. They may be seeing an interrupt from something else other than KSV_RDY, such as receiver detect. 

    Thanks,
    Jason

  • Hello Jason,

    Thank you very much for your comments.

    Please check if my understandings are correct for AV_MUTE.  The datasheet says AV_MUYE is only set if the HDCP_EESS bit is also set, so you're proposing those bits are set before changing the input source, right? 

    Boot

    -> No HDCP authentication (unless HDCP is required)

    -> HDCP authentication when the source changes to HDCP

    -> 0xC2 register set(HDCP EESS=HDCP AV MUTE=1)

    -> Continues protecting source if it is analog like AUX input

    -> Check if IS_AUTH_FAIL=1 with blue screen

    For the interrupt registers, they set these, so all the interrupts should be enabled.  Have you heard a wait time required for KSV RDY?  My customer says that is the only status bit requiring wait time.  They can read the others without wait time.

    Register        Data

    0x01            0x02

    0x03            0xDA

    0x04            0x80

    0x05            0x00

    0x07            0x88

    0x08            0x88

    0x70            0xCE

    0x77            0xCE

    0x71            0xD2

    0x78            0xD2

    0x0D            0x25

    0x0E            0x05

    0x0F            0x07

    0x13            0x10

    0xC0            0x05

    0xC2            0xC0

    0xC3            0x02

    0xC6            0xFF

    Best regards,

     Yoshikazu Kawasaki

  • Hello Yoshikazu,

    Your understanding of AV_MUTE is correct. I still think that switching sources would cause authentication to fail (due to losing lock), so at the same time as enabling AV_MUTE they should disable authentication. Otherwise when AV_MUTE is disabled, the blue screen would be displayed.

    That being said, I'm not sure I fully understand what the system configuration is - I'm assuming the 'analog AUX' input is a completely different clock source from the protected content.

    When the interrupt happens, is this the order of what is happening?

    - INTB pin goes low

    - Read the 0xC7 status register, KSV_RDY is the ONLY interrupt that is set

    - Check KSV_RDY bit of HDCP Status register, it is 0 until 5ms after the interrupt, then goes to 1

    That is not what I would expect, so I want to make sure that they are interpreting the interrupt correctly.

    Thanks,
    Jason

  • Hello Jason,

    Thank you very much for your comments.

    The procedure my customer did for HDCP including interrupt handling is attached.  Please let me know if you see anything wrong.

    Best regards,

     Yoshikazu Kawasaki

    HDCP_Authentication_Flow.pptx
  • Hello Yoshikazu,

    The procedure looks okay - is this just for the authentication when the protected content needs to be sent? I wasn't clear when the source is changing to AUX content, or when the interrupt is happening. There is some Japanese text, I'm not sure if that makes it more clear.

    Thanks,
    Jason

  • Hello Jason,

    Thank you very much for checking the procedure.  Yes, the procedure is their authentication flow.  I attached their procedure in English for your reference.

    Would you please tell me these?

    1. Do you see any issues on their procedure for HDCP authentication?  What would my customer need to do when the input source changes from HDCP to analog which doesn't need HDCP?  Would you please tell me the correct procedure?

    2. Would you please tell me why you would think KSV_RDY is the only status bit my customer needs some wait time?

    Best regards,

     Yoshikazu Kawasaki

    HDCP_Authentication_Flow_Englist.pptx
  • Hello Jason,

    Thanks to your advice for AV_MUTE, my customer didn't get authentication fail if they did as you suggested.  So, the root cause of the blue screen should be PCLK change as you suspected.  They also found that the SoC clock stops for a while when the input source changes, but it didn't stop if authentication is disabled.  They've been investigating how to continues the SoC clock, but it seems to be quite difficult.  They'd like to fix this issue as easy as possible.  They're wondering what they should do for that.  Would you please give me your comments about these as well?

    1. The HDCP authentication can't be remained when the PCLK changes?

    2. Would you please tell me the correct procedure when PCLK changes/stops for a moment?  Is it required to disable authentication?

    3. Is it possible to avoid the unlock(or HDCP authentication fail) issue by changing/stopping the PCLK?

    4. Is it required to do authentication again after getting HDCP contents from non HDCP?

       HDCP -> authentication -> non HDCP -> HDCP -> needs authentication again?

    Best regards,

     Yoshikazu Kawasaki

  • Hello Yoshikazu,

    1. If lock is lost, then HDCP authentication will fail and need to be re-completed. If the new content is not HDCP protected, then it makes sense to disable HDCP before changing PCLK. 

    2. If the old and new content are both HDCP protected, then they should enable AV_MUTE (to prevent any glitches on the screen), disable authentication, change PCLK, and enable authentication. This could be done without disabling authentication, but that would result in a failure which they would have to ignore.

    3. No.

    4. If lock is maintained throughout that whole cycle, then authentication can remain valid and wouldn't need to be redone. If lock is lost, then authentication would need to happen when the content switches to HDCP.

    Thanks,
    Jason

  • Hello Jason,

    Thank you very much for your comments.  Please let me confirm two things about KSV_RDY bit and your comments for #2.

    1. Does KSV_RDY bit need a wait time to check the correct status?

    2. You mentioned about the flow for changing the input source from HDCP to another HDCP.  If I understand correctly, it is :

    AV_MUTE->disable authentication->change PCLK->enable authentication

    You also mentioned that this could be done without disabling authentication.  However your suggestion is disabling the authentication after AV_MUTE.  Which one is correct?

    Best regards,

     Yoshikazu Kawasaki