HPD timers, displayport interrupts, and DCE details

[sylware]

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).

[agd5f]

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.

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.

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.

* 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.

[sylware]

hpd sensing right after initing

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?)

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.

[agd5f]

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.

I read your patch. It seems we still miss DFP6 in radeon_atombios_encoder_dpms_scratch_regs.

I'll check that out next week.