https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #62 from Mathias Tillman <master.homer@xxxxxxxxx> --- Sorry for bringing up an old bug, but I'm still having this problem in 3.18, so I decided to do some further tests which made me discover some new things that may or may not be related. I started off by adding a new sysfs entry for calling a pplib command (I noticed that one such call failed when I unplugged and replugged one of my monitors). What I discovered was that ALL pplib commands failed (returned 0x00) when it got stuck in the higher power level, and it started working again once I unplugged my second monitor. What's interesting here is that the commands were also fine when I was running them using a single monitor that was also running on the highest power level (though it was not stuck). So it seems that they fail only when the power level is stuck. I'm not sure if this is related or not, but it certainly seems that way to me. To check if it was actually related to the mclk value as my previous tests had shown that they were I added another sysfs entry for changing the mclk value on the fly (using radeon_set_memory_clock). I guess the code for disabling the mclk switching on multiple monitors is necessary as the screen would become garbled and eventually the computer would lock up when running it multiple times. In any case, it works if I only call it a few times, so I was able to test my theory. Unfortunately it showed the same symptoms no matter what I lowered the mclk to (pplib commands failing, unable to force the power level, etc). So it doesn't seem to be directly related to what the mclk value is, but more that it at one point has been running at a particular value and that triggers a part of the code that disables pplib commands and power scaling? I'm really not sure why this is happening. I hope this information will be useful to someone, I will probably keep trying to solve this, but I am starting to run out of ideas (and I'm far from familiar with how the radeon code actually works). -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
