Announcement

Collapse
No announcement yet.

HPD timers, displayport interrupts, and DCE details

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • HPD timers, displayport interrupts, and DCE details

    Based on evergreen chips and in the case of a displayport connector, we have in hpd_init (evergreen.c) 2 timers:
    DC_HPDx_CONNECTION_TIMER(0x9c4) (units?)
    DC_HPDx_RX_INT_TIMER(0xfa) (units?)

    How the HPD logic can detect interrupt from the sink instead of a cable disconnexion? According to the displayport standard, we would need to generate an HPD interrupt but not assert the cable disconnexion (2ms threshold + debouncing safety I presume).

    questions:
    * Routes from digital encoders to uniphy links are really hardcoded on the die, or we do not use their routing capabilities?
    * Are the atombios states (dpms/connected connector/etc...) in scratch registers still relevant from dce4 since we basically manually program those states from the driver? (BTW, we miss some DFP6 and more DFPx for some states in atombios driver code).

  • #2
    Originally posted by sylware View Post
    Based on evergreen chips and in the case of a displayport connector, we have in hpd_init (evergreen.c) 2 timers:
    DC_HPDx_CONNECTION_TIMER(0x9c4) (units?)
    DC_HPDx_RX_INT_TIMER(0xfa) (units?)
    The units are microseconds.

    Originally posted by sylware View Post
    How the HPD logic can detect interrupt from the sink instead of a cable disconnexion? According to the displayport standard, we would need to generate an HPD interrupt but not assert the cable disconnexion (2ms threshold + debouncing safety I presume).
    That is correct. One is for hpd connect/disconnect, the other is for hpd from the sink.

    Originally posted by sylware View Post
    questions:
    * Routes from digital encoders to uniphy links are really hardcoded on the die, or we do not use their routing capabilities?
    They are hardcoded for evergreen. The only exception is SUMO/SUMO2 which is routeable.

    Originally posted by sylware View Post
    * Are the atombios states (dpms/connected connector/etc...) in scratch registers still relevant from dce4 since we basically manually program those states from the driver? (BTW, we miss some DFP6 and more DFPx for some states in atombios driver code).
    The connected ones are, but the crtc ones are not. I just sent a patch to dri-devel to fix this.

    Comment


    • #3
      hpd sensing right after initing

      Originally posted by agd5f View Post
      That is correct. One is for hpd connect/disconnect, the other is for hpd from the sink.
      Ok.
      I noticed that evergreen_hpd_init uses the evergreen_hpd_sense through evergreen_hpd_set_polarity. Is it ok to use the hpd sense logic right after initing the timers? (coldplug logic?)

      Originally posted by agd5f View Post
      The connected ones are, but the crtc ones are not. I just sent a patch to dri-devel to fix this.
      I read your patch. It seems we still miss DFP6 in radeon_atombios_encoder_dpms_scratch_regs.

      Comment


      • #4
        Originally posted by sylware View Post
        Ok.
        I noticed that evergreen_hpd_init uses the evergreen_hpd_sense through evergreen_hpd_set_polarity. Is it ok to use the hpd sense logic right after initing the timers? (coldplug logic?)
        Yes.

        Originally posted by sylware View Post
        I read your patch. It seems we still miss DFP6 in radeon_atombios_encoder_dpms_scratch_regs.
        I'll check that out next week.

        Comment

        Working...
        X