Opened 5 years ago

Closed 4 years ago

#9631 closed defect (fixed)

DCON doesn't assert correct status during resume

Reported by: pgf Owned by: wad
Priority: normal Milestone: 1.5-hardware-C
Component: hardware Version: 1.5-C2
Keywords: Cc: pgf, rsmith, dsd
Blocked By: Blocking:
Deployments affected: Action Needed: diagnose
Verified: no

Description

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.)

Attachments (1)

DCONMacroTiming.pdf (18.7 KB) - added by wad 5 years ago.
Macro timing diagram of the DCON freeze and unfreeze process

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by Quozl

  • Action Needed changed from never set to diagnose
  • Milestone changed from 1.5-F11 to 1.5-CTest
  • Version changed from not specified to 1.5-B2

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

comment:2 Changed 5 years ago by pgf

  • Cc pgf rsmith added
  • Version changed from 1.5-B2 to 1.5-C2

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.

comment:3 Changed 5 years ago by pgf

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

comment:4 Changed 5 years ago by pgf

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

comment:5 follow-ups: Changed 5 years ago by 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.

Changed 5 years ago by wad

Macro timing diagram of the DCON freeze and unfreeze process

comment:6 in reply to: ↑ 5 Changed 5 years ago by 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.

comment:7 in reply to: ↑ 5 Changed 5 years ago by 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.

comment:8 Changed 4 years ago by Quozl

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

comment:9 Changed 4 years ago by dsd

  • Cc dsd added

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?

comment:10 Changed 4 years ago by pgf

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.