Please attach your dmesg output.  Was it the firmware updates the caused the regression or an Ubunutu update?  If it's an Ubuntu update, can you narrow down what update caused the regression?  If it's a firmware update, you'll probably have to take that up with Apple.

Created attachment 127003 [details]
dmesg output on 16.04

Created attachment 130894 [details]
dmesg of first failed commit

Same with another iMac11,1, but no firmware update.  Kernels before 3.14 are fine.  Kernels from 3.14 show blank display or sometimes flickering horizontal lines.

I've done a git bisect and first failing commit is 32167016076f714f0e35e287fbead7de0f1fb179 "drm/radeon: rework finding display PLL numbers v2" by Christian König.

Happy to test kernels or enable debugging, let me know.

Tested 4.11.0-rc7 as-is, and drm.debug=0xe, display was flickering horizontal lines, and got PLL setup of;

[drm:radeon_compute_pll_avivo [radeon]] 360000 - 366660, pll dividers - fb: 22.0 ref: 2, post 3

Tested 4.11.0-rc7 by reverting all the PLL changes (overkill);

72edd83cc9e58 ("drm/radeon: fix PLLs on RS880 and older v2")
4b21ce1b4b5d2 ("drm/radeon: lower the ref * post PLL maximum once more")
3b333c55485f ("drm/radeon: avoid high jitter with small frac divs")
c2fb3094669a ("drm/radeon: improve PLL limit handling in post div calculation")
24315814239a ("drm/radeon: use fixed PPL ref divider if needed")
f8a2645ecede ("drm/radeon: improve PLL params if we don't match exactly v2")
32167016076f ("drm/radeon: rework finding display PLL numbers v2")

display was good, and got PLL setup of;

[drm:radeon_compute_pll_avivo [radeon]] 36000, pll dividers - fb: 54.0 ref: 5, post 3

Created attachment 130899 [details] [review]
possible fix

Does this patch help?

Created attachment 130900 [details] [review]
possible fix

Narrow the focus to just rv770.

Created attachment 130908 [details]
dmesg with "drm/radeon: adjust pll flags for RV770"

Thanks, but no, not fixed by 3cc2ebbca98 "drm/radeon: adjust pll flags for RV770".  Result was blank display.  Captured dmesg by ssh, attached.

Hi,

I'm still seeing this issue with an iMac11,1 with the identical graphics (RV770/M98L [Mobility Radeon HD 4850])

This is with kubuntu 17.04:

kernel: 4.10.0-32-generic

radeon driver info:
--------------------
libdrm-radeon1:amd64                   2.4.76-1
xserver-xorg-video-radeon              1:7.9.0-0ubuntu1

I only get a working main display using 'nomodeset', which of course is disabling the radeon driver.

Any suggested patches or things to try?

Thanks,

Justin Thiessen

Other than reverting the series in comment 4, I've no solution.  Once I had that workaround, I was mostly happy.  I wanted to find the underlying problem and upstream it, but ran out of time.

At one stage I was using "avivotool regs pll1" to confirm the PLL registers, comparing between last working kernel version, latest kernel, and my kernel with the series reverted.

My notes have outstanding questions that I didn't get to resolve; 

1. how to achieve a dot clock of 360000 instead of 366660, given that 360000 works for me?

2. why is RADEON_PLL_PREFER_LOW_REF_DIV set given that the bit is only used when RADEON_PLL_LEGACY is set?

3. why set RADEON_PLL_PREFER_MINM_OVER_MAXP given that it limits the ref_div to 7 yet the system has already chosen 2 instead of 5.

Hope that helps.

Thanks James - I'll give this a shot

so with the reversions from comment 4 (some conflict resolution by hand necessary, but seemed straightforward), the radeon driver loads and the primary display gets initialized and seems to work.

seems like either:
* the screen dimming is broken resulting in a dark primary screen when that kicks in

or 

* after suspend the secondary display becomes primary and the internal screen is dark.

haven't yet dug into this.

looks like i'm seeing occasional artifacts as well.

This is with kubuntu 17.04, kernel:

4.10.0-32-generic #36-Ubuntu SMP

Definitely progress, considering

Great.  Sounds like what I observed.  I seem to recall there were two sysfs entries for brightness, and both were effective.  I don't have automatic dimming enabled, so didn't notice a problem.  I don't suspend at all, because it has never worked after resume.  I'd forgotten to check.

Did you have any luck with this?

I have a late 2009 imac and on installing kubuntu 18.04 the radeon driver fails with a dark screen or defaults to vesa complaining  - modprobe: ERROR: could not insert 'radeon': Invalid argument   if I use the nomodeset option from boot (via refind).
I've reported this in bug 107324.

I've attached a separate screen via the displayport, and the radeon driver loads and I get the second monitor as a secondary screen, from which I can access kscreen through the settings dialog and then set as the primary.
Throughout this time, the secondary display is working but is dark in comparison to what I would expect, but the primary screen, the imac, is a black screen except for tear type artefacts like barely visible equidistant lines floating upwards.
I would guess that the edid is reported incorrectly, as the imac screen is reported in the settings dialog as 'laptop'.
I'm going to try obtaining and setting an edid etc now.

Created attachment 140762 [details]
xorg.0.log

this is with the external screen attached.  I've attached another file of xorg.0.log.old with no screen attached and a failed boot.

Created attachment 140763 [details]
xorg.0.log.old

failed boot log

*** Bug 107324 has been marked as a duplicate of this bug. ***

I am currently running a rt compiled kernel for audio use at the latest patch level, so 4.9.98, but I get the same problem on the generic installed kernel that is 4.17 I think.  I'll check now.

the generic is 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

looks like the edid is fried.

his is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Only trying 6 as per your request.
256-byte EDID successfully retrieved from i2c bus 6
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
        Identifier "Color LCD"
        ModelName "Color LCD"
        VendorName "APP"
        # Monitor Manufactured week 28 of 2009
        # EDID version 1.4
        # Digital Display
        DisplaySize 600 340
        Gamma 2.20
        Option "DPMS" "true"

        #Extension block found. Parsing...
extb[4]: 0x23 (0x20)
Hmm, you have data blocks, but not video ones... weird
Something strange happened. Please contact the author,

I'll try updating the apple firmware to see if that might help.

Created attachment 140768 [details]
results.log from the ubuntu firmware checking tool

from https://wiki.ubuntu.com/FirmwareTestSuite/

(In reply to jamesstewartmiller from comment #14)
> I would guess that the edid is reported incorrectly, as the imac screen is
> reported in the settings dialog as 'laptop'.

FWIW, sounds rather like the settings app just incorrectly assumes that only laptops have eDP outputs.

Thanks, I thought that the display size was incorrect, but I have since seen how the size is calculated.

Thanks for asking, James.  No, I've no progress to report since my previous comments here.  I'm still using a local kernel on the affected machine, and haven't had time to resolve the outstanding questions I listed.  Let me know if you need any information.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/164.