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

[James Feeney]

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

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.

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?

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