Comment 69 for bug 411294

Revision history for this message
In , Jérôme (jrme-redhat-bugs) wrote :

Here are my observation before i forget about them :

Register dump i asked are all register the vbetool post ever read or write on
this specific hw. Thus if there is any difference in the way vbetool or KMS restore the card it should reflect in various dumps. It's not the case. The dumps
show that with KMS VGA is disable, PLL are different too (because video mode
setup by KMS and vbetool are different), of course video mode related register
are different.

Interesting things that diff btw dump shows, is that MC is idle on KMS and the
3D pipe configuration isn't restored. MC being idle could be either the source
of the bug or just reflect the fact that VRAM is not working. If MC is not
properly restored or in bogus state it could report IDLE because it doesn't
answer to any memory request from the GPU. Or if VRAM is not properly restored
MC can simply fail at executing request from the GPU and thus report IDLE.

Otherwise all others register have similar values.

My first attempt to fix the issue tried to reset the MC at resume, i found a bug
in my patch i am working on new one which will do the following (order matter) :
-stop MC at suspend
-reset MC at resume
-restore MC
-ASIC_Init

I am relooking at Atombios dump as i was looking at the wrong disasm of the atom bios tools, to check if vbetool post takes a different path than ASIC_Init.