atombios_crtc.c - make error messages distinguishable "unable to allocate a PPLL\n"

[Deucher, Alexander]

> -----Original Message-----
> From: James Feeney [mailto:james at nurealm.net]
> Sent: Monday, June 08, 2015 3:43 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: atombios_crtc.c - make error messages distinguishable "unable
> to allocate a PPLL\n"
> 
> > DCE4 parts (like the 5570) only have an external clock if the OEM supplied
> > it, hence not all boards have it.  Also, the external clock source can only
> > be used to drive native DP (DisplayPort), not non-DP outputs like DVI or
> HDMI
> > or VGA or a passive DP to DVI/HDMI convertor.  If you are using 3 non-DP
> > displays, that will only work if at least two of the displays have the exact
> > same clock and hence can share a PLL.  If you want to use a the external
> > clock, the board has to have it, and if it does, it can only be used for DP.
> > There are lots of other complex cases and limitations as well depending on
> > the asic.
> 
> Thanks Alex.  Yes, I know.  The DisplayPort actually goes through an Accell
> "UltraAV DisplayPort 1.2 to HDMI 1.4 active adapter".  But I do not know if
> the
> board actually has the external clock source installed.  Is this external clock
> probed by the driver?  Is there a log message about the existence or
> nonexistence of the "external clock"?

Yes, the driver checks to see if it is available.  If it is available, rdev->clock.dp_extclk will be non-zero.

The basic logic works like this for your board.  The DCE5 and DCE6 cases are not relevant for DCE4.

if the display is DP {
    if there is an ext clock {
        Use the ext clock;
    }  else {
        Use one of the two display PLLs if one is available or sharable;
    }
} else {
    Use of one of the two display PLLs if one is available or sharable;
}

> 
> The radeon driver does not seem to report any detail about what it has
> found in
> the hardware, and so, it is very difficult to infer what "should" or "should
> not" be possible with the display configurations.
> 

The driver prints out basic display topology information in the system log (connectors, encoders, hotplug and ddc info).  Beyond that there is tons of other stuff that might be relevant depending on the scenario.  The whole thing is so complex, it's really hard to clearly articulate all the possible scenarios.

> Actually, with Xorg and Weston, it seems I have to force _all_three_
> interfaces
> to the same clock, even though, presumably, there are at least two separate
> PLLs.  Can the DisplayPort _not_ use the - possibly "random" - clock from the
> other display interfaces?  Does the DisplayPort have to have an
> _independent_
> clock source?

Yes, DP needs its own clock source.  However, you only need one clock source for all DP ports so you can drive multiple DP displays from a single clock source.  The clock source used for DP cannot be shared with non-DP displays.  Non-DP displays need a dedicated clock source per mode clock.  E.g., you can share a clock source across multiple non-DP displays if they have the same clock value.  There are additional caveats however.  For example, you can't share a clock source between two displays with different hdmi audio settings even if the mode clocks are the same (e.g., DVI without audio and HDMI with audio using the same mode clock).  Also make sure the actual mode clocks are identical.  I.e., you can have two monitors that support 1920x1200, but each has slightly different timing so the clocks don't match.

Alex

> 
> Subsequently, using xrandr, I can try to force, for instance, DVI-0 to a
> different clock, but it does nothing.  "xrandr --verbose" will report the new
> mode, but the log shows an error,
> 
>  kernel: [drm:atombios_crtc_mode_fixup [radeon]] *ERROR* unable to
> allocate a
> PPLL FIVE
>  kernel: [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR*
> failed to set
> mode on [CRTC:32]
> 
> and the display menu reports that the display is still running in the old mode.
>  That is a mess with xrandr, since what it is reporting is then wrong.
> 
> Also, running three displays on a Virtual Terminal is a mess, with one display
> showing the Virtual Terminal in a "least common denominator" mode for all
> three
> displays, and with the other two displays still showing the previous Xorg
> display.
> 
> For the moment, it would be most useful if the radeon driver would disclose
> the
> specific hardware configuration it was "seeing", for instance, the exact
> number
> of "working" clock sources, and the exact number of crtc's, and to also
> disclose
> how the clock sources were being deployed, for instance, specifically, which
> clock sources were being shared, and which were being made "exclusive".
> 
> 
> James