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

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

[James Feeney]

atombios_crtc.c

In multi-display configurations, especially with three or more displays,
PLL/clock source allocations can fail when there are more crtc's than PLLs.
When attempting to debug these PLL allocation failures in the source code, the
error message displayed in the log, DRM_ERROR("unable to allocate a PPLL\n");,
is not useful because the exact same error message is used for _five_ different
error states/code paths.

These different error states/paths should be distinguished, simply by including
some kind of distinguishing mark with each error message.  For instance:

                        DRM_ERROR("unable to allocate a PPLL ONE\n");
                        DRM_ERROR("unable to allocate a PPLL TWO\n");
                DRM_ERROR("unable to allocate a PPLL THREE\n");
                DRM_ERROR("unable to allocate a PPLL FOUR\n");
                DRM_ERROR("unable to allocate a PPLL FIVE\n");

Whether the reported error is truly valid because of an actual hardware
limitation, or invalid because of faulty heuristics in the software, is a
separate topic.

Thanks
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Christian König]

On 08.06.2015 18:26, James Feeney wrote:
> atombios_crtc.c
>
> In multi-display configurations, especially with three or more displays,
> PLL/clock source allocations can fail when there are more crtc's than PLLs.
> When attempting to debug these PLL allocation failures in the source code, the
> error message displayed in the log, DRM_ERROR("unable to allocate a PPLL\n");,
> is not useful because the exact same error message is used for _five_ different
> error states/code paths.
>
> These different error states/paths should be distinguished, simply by including
> some kind of distinguishing mark with each error message.  For instance:
>
>                          DRM_ERROR("unable to allocate a PPLL ONE\n");
>                          DRM_ERROR("unable to allocate a PPLL TWO\n");
>                  DRM_ERROR("unable to allocate a PPLL THREE\n");
>                  DRM_ERROR("unable to allocate a PPLL FOUR\n");
>                  DRM_ERROR("unable to allocate a PPLL FIVE\n");

Actually it's always the same error. The message just appears in that 
file multiple times for different hardware generations.

Regards,
Christian.

>
> Whether the reported error is truly valid because of an actual hardware
> limitation, or invalid because of faulty heuristics in the software, is a
> separate topic.
>
> Thanks

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[James Feeney]

> Actually it's always the same error. The message just appears in that file
> multiple times for different hardware generations.

Which is fine, presupposing that the user already knows what hardware generation
they are using _and_ how the video card manufacturer actually implemented the
display interfaces, as, for instance, whether or not the "external PLL" really
exists, or was left off.  That is "presuming the conclusion", though.  The user
does _not_ know.

The problem is that the error message is not informative for the person who is
actually encountering the problem.  At that point, the user already knows that
their display is not working, and they do not need an error message that says,
effectively, "Your display is not working."  That is insulting.  They need
information about how to respond, how to "fix" the problem.  The idea is to be
able to look at the source code.

For instance, I have an HD 5570 card, including a DisplayPort interface, for
which we can read "The 5000-series designs host two internal clocks and one
external clock."  With exactly three clocks and three displays, there should
_never_ be an allocation error.  Instead, there are constant "unable to allocate
a PPLL" errors, generated in the fifth "/* all other cases */" code path.  Why?

I had to modify and recompile the source just to find where the error was being
generated.  Please make life a little easier.

James
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Deucher, Alexander]

> -----Original Message-----
> From: James Feeney [mailto:james@nurealm.net]
> Sent: Monday, June 08, 2015 1:10 PM
> To: Koenig, Christian; Deucher, Alexander
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: atombios_crtc.c - make error messages distinguishable "unable
> to allocate a PPLL\n"
> 
> > Actually it's always the same error. The message just appears in that file
> > multiple times for different hardware generations.
> 
> Which is fine, presupposing that the user already knows what hardware
> generation
> they are using _and_ how the video card manufacturer actually implemented
> the
> display interfaces, as, for instance, whether or not the "external PLL" really
> exists, or was left off.  That is "presuming the conclusion", though.  The user
> does _not_ know.
> 
> The problem is that the error message is not informative for the person who
> is
> actually encountering the problem.  At that point, the user already knows
> that
> their display is not working, and they do not need an error message that
> says,
> effectively, "Your display is not working."  That is insulting.  They need
> information about how to respond, how to "fix" the problem.  The idea is to
> be
> able to look at the source code.
> 
> For instance, I have an HD 5570 card, including a DisplayPort interface, for
> which we can read "The 5000-series designs host two internal clocks and one
> external clock."  With exactly three clocks and three displays, there should
> _never_ be an allocation error.  Instead, there are constant "unable to
> allocate
> a PPLL" errors, generated in the fifth "/* all other cases */" code path.  Why?

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.

Alex

> 
> I had to modify and recompile the source just to find where the error was
> being
> generated.  Please make life a little easier.
> 
> James
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Deucher, Alexander]

> -----Original Message-----
> From: James Feeney [mailto:james@nurealm.net]
> Sent: Monday, June 08, 2015 3:43 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: dri-devel@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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[James Feeney]

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

Again, thanks for that.  That's quite helpful.  In extensive reading, trying to
understand what would be required to run three displays, I saw no mention of
those two points.

If the radeon driver could report a) what architecture it sees/code path it is
following, b) the total number of clock sources found, and c) which clock
sources are assigned to which outputs, then it would be much easier to discover
the current display configuration and to anticipate what display configurations
would be "workable".

The radeon driver can be quite "obstinate" when trying to set a specific
configuration for three displays, where the result will depend upon the
configuration history, or perhaps is strongly dependent upon the relative
position of the displays.

For instance, with my HD 5570, and supposing that the external clock is not
installed, and that there are still two independent internal clock sources
available, it should be possible to assign one clock source to the DisplayPort
output, and one clock source shared to the DVI and HDMI outputs.  If I change
the output modes from a working configuration to, say, a test configuration, and
then try to change back again, some repeated "trial and error" attempts with
xrandr are required, before the original configuration will "take".  Often, the
first reconfiguration or two results in some black screens, and then "something"
in some subsequent xrandr reconfiguration will trigger a screen update where the
displays are first "scrambled" and then are redrawn correctly.

This suggests to me some kind of "hidden state" in the radeon driver, which is
being updated by some indirect mechanism when I change output modes.  Sorry, I'm
not being precise.  Does anyone have any thoughts about how to better understand
this reconfiguration sequence, and how to make the process more "robust" and
predictable?

James
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Christian König]

On 11.06.2015 00:12, James Feeney wrote:
>> 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.
>> ...
>> 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
> Again, thanks for that.  That's quite helpful.  In extensive reading, trying to
> understand what would be required to run three displays, I saw no mention of
> those two points.
>
> If the radeon driver could report a) what architecture it sees/code path it is
> following, b) the total number of clock sources found, and c) which clock
> sources are assigned to which outputs, then it would be much easier to discover
> the current display configuration and to anticipate what display configurations
> would be "workable".

Yeah, that's indeed true. We already dump the connector configuration on 
bootup, but not the config of the PLLs driving them.

Feel free to submit a patch for this, it clearly sounds like a good idea.

>
> The radeon driver can be quite "obstinate" when trying to set a specific
> configuration for three displays, where the result will depend upon the
> configuration history, or perhaps is strongly dependent upon the relative
> position of the displays.
>
> For instance, with my HD 5570, and supposing that the external clock is not
> installed, and that there are still two independent internal clock sources
> available, it should be possible to assign one clock source to the DisplayPort
> output, and one clock source shared to the DVI and HDMI outputs.  If I change
> the output modes from a working configuration to, say, a test configuration, and
> then try to change back again, some repeated "trial and error" attempts with
> xrandr are required, before the original configuration will "take".  Often, the
> first reconfiguration or two results in some black screens, and then "something"
> in some subsequent xrandr reconfiguration will trigger a screen update where the
> displays are first "scrambled" and then are redrawn correctly.
>
> This suggests to me some kind of "hidden state" in the radeon driver, which is
> being updated by some indirect mechanism when I change output modes.  Sorry, I'm
> not being precise.  Does anyone have any thoughts about how to better understand
> this reconfiguration sequence, and how to make the process more "robust" and
> predictable?

Well, the basic problem is the hardware. And the "hidden state" you are 
talking about is just the hardware state.

Especially on older generations you have all kind of funny dependencies 
in the PLLs that you need to take care of in the software.

Some have special routing requirements, e.g. can drive only certain 
outputs, some can only generate a certain range of frequencies 
(resolutions), some have undocumented power management dependencies 
(e.g. you turn PLL1 off and PLL2 suddenly becomes unstable).

The last time I tried to fix some corner cases I've broken a lot of 
other users with my patches. So a very typical scripting comment applies 
here as well: "It works don't touch it"! We could try patches, but the 
chance of fixing it for one person and breaking it for somebody else is 
just very high.

The best advice I can give you if you want to use more than two displays 
at the same time make sure to have DP displays, and that's a good idea 
no matter what hardware you have.

Regards,
Christian.

>
> James

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Alex Deucher]

On Wed, Jun 10, 2015 at 6:12 PM, James Feeney <james@nurealm.net> wrote:
>> 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.
>> ...
>> 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
>
> Again, thanks for that.  That's quite helpful.  In extensive reading, trying to
> understand what would be required to run three displays, I saw no mention of
> those two points.
>
> If the radeon driver could report a) what architecture it sees/code path it is
> following, b) the total number of clock sources found, and c) which clock
> sources are assigned to which outputs, then it would be much easier to discover
> the current display configuration and to anticipate what display configurations
> would be "workable".

It's still a challenge even if you printed information about the clock
sources.  As Christian noted, there are a lot of corner cases and
limitations of various clock sources depending on the chips.  E.g.,
just printing out that you have 3 clocks sources does not imply that
you can run 3 monitors.  E.g., ext pll can only drive native DP or
active DP to DVI converters.  Regular plls can only be shared if the
clocks match, etc.  I'm not sure if it would help or just cause more
confusion.


>
> The radeon driver can be quite "obstinate" when trying to set a specific
> configuration for three displays, where the result will depend upon the
> configuration history, or perhaps is strongly dependent upon the relative
> position of the displays.
>
> For instance, with my HD 5570, and supposing that the external clock is not
> installed, and that there are still two independent internal clock sources
> available, it should be possible to assign one clock source to the DisplayPort
> output, and one clock source shared to the DVI and HDMI outputs.  If I change
> the output modes from a working configuration to, say, a test configuration, and
> then try to change back again, some repeated "trial and error" attempts with
> xrandr are required, before the original configuration will "take".  Often, the
> first reconfiguration or two results in some black screens, and then "something"
> in some subsequent xrandr reconfiguration will trigger a screen update where the
> displays are first "scrambled" and then are redrawn correctly.
>
> This suggests to me some kind of "hidden state" in the radeon driver, which is
> being updated by some indirect mechanism when I change output modes.  Sorry, I'm
> not being precise.  Does anyone have any thoughts about how to better understand
> this reconfiguration sequence, and how to make the process more "robust" and
> predictable?

Part of the problem is the current KMS modesetting API.  It sets modes
per display rather than globally setting up the entire display
configuration.  For example some DIG PHYs (encoders for digital
displays like DP or HDMI or DVI) can only be driven by certain PLLs.
If the PLL is already in use by another display, the driver cannot
support the requested configuration without reconfiguring the the
other already configured displays so the ordering may make a
difference.  The new atomic modesetting API that is currently in
progress aims to rectify this by setting up the complete display state
at one time so the driver can make optimal decisions about how to use
the relevant display resources.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel