DCON doesn't assert correct status during resume

[pgf]

while the system is running, freezing/unfreezing the dcon works fine.

when the system is resuming, the dcon doesn't assert the correct status (0x01) on its two status lines at the time of the first scanline interrupt after the DCON unload happens. a workaround has been installed in the driver to treat this case specially, otherwise we will wait and timeout after a second, looking for the "right" interrupt. the missing status signal is troubling, however.

(missing status assertion (of DCONSTAT0) verified using o'scope.)

[Quozl]

triage. moved to hardware milestone. changed to latest released hardware version.

[pgf]

it turns out that the reason we don't see a proper 01 status acknowledging our "dcon unload" operation is that the "dcon unload" operation (i.e, our write of DCONLOAD to '1') is redundant.

we set DCONLOAD to 0 before we suspend. when we return from suspend, it is _already_ set to 1. (these before/after values confirmed by debugging.) for whatever reason, i think this means the DCON has already entered pass-thru mode. need to wire up a board to verify.

[pgf]

as close as i can tell with the scope, DCONLOAD is being asserted at the moment that we resume.

[pgf]

see also #9869, which is related, but concentrates on behavior while the system is awake.

[wad]

Are you sure about your terminology ? I've attached a diagram which shows the proper operation as specified in the documentation. The difference is that the 01 status comes from scanline interrupts which occur while the DCON is still frozen. Once it is unfrozen, the scanline interrupt is identified by 00.

I would change the driver timeout to something more reasonable, like 100 mS.

Despite the fact that this bug is due to a flaw in either the VX855 silicon or documentation (failure to maintain the state of a GPIO across suspend/resume, despite claiming to do so in the data sheet) it may still be possible to work around it.

The DCON will not unfreeze until the trailing edge of the first VSYNC pulse that it sees from the host. As long as the VX855 display controller hasn't been restarted, you should still be able to use the scanline interrupt and get 01 as the status.

And if we enable the VX855 display controller in a manner synchronous to VSYNC generated from the DCON (see ticket #9869), there shouldn't be a glitch upon resume.

[wad]

Macro timing diagram of the DCON freeze and unfreeze process

[pgf]

Replying to wad:

The DCON will not unfreeze until the trailing edge of the first VSYNC pulse that it sees from the host.

i think i was mis-reading the spec on this point. i thought it would do that if you set everything else up "just right", as in "As long as ... is sufficiently close... Dcon will switch following the trailing edge of the input Vsync". i'll think about it more with your (correct) interpretation.

[pgf]

Replying to wad:

I would change the driver timeout to something more reasonable, like 100 mS.

are you referring to this: "otherwise we will wait and timeout after a second, looking for the "right" interrupt"? the driver workaround avoids that wait, so we don't hit the timeout.

[Quozl]

We now suspect that this symptom is caused by OpenFirmware touching DCONLOAD during the resume path. See #9350.

[dsd]

The firmware got fixed and that seemed to solve the original problem. Can this bug be closed or is there still a suspected issue with VX855 GPIO lines?

[pgf]

i believe we think everything's okay, and the comments re: vx855 gpio lines were errnoeous. closing.