https://bugs.freedesktop.org/show_bug.cgi?id=87682
--- Comment #9 from Thom madeforspam@telfort.nl --- (In reply to Chris Bainbridge from comment #8)
This is not correct. The 77/69 does not imply a linear ordering because of forks: Trust git ;-)
Thanks for the update, that explains everything. I hardly know git, and before yesterday I didn't even know what git or what bisecting was...it's a bit overwhelming.
c2fb3094669a3205f16a32f4119d0afe40b1a1fd is the first bad commit
Not familiar with this code, but from the patch the PLL values are printed out:
DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post%d\n", freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p, ref_div, post_div);
That is like magic :-) How did you get git to give you the source of that patch so quickly ? (I googled for hours on this stuff without success)
So suggest enabling debug log and compare those two lines from a working and non-working kernel.
I assume that I have to enable debug log via a bootoption because I couldn't find anything in menuconfig that wasn't already marked for inclusion. What bootoption do I have to use to enable the right (and right amount of) debug logging ? (and after that, where do I find the log output?)
It should also be trivial to checkout a recent tag and revert the bad commit
I don't even know yet what that is or how to do that, even after reading the man pages about checkout, tag, revert and commit; but I'm convinced I'll get there in the end ;-)