#10068 NORM 1.5-sof: Black Xv overlay when starting Record
Zarro Boogs per Child
bugtracker at laptop.org
Wed Mar 24 18:44:03 EDT 2010
#10068: Black Xv overlay when starting Record
---------------------------------------+------------------------------------
Reporter: cjb | Owner: jon.nettleton
Type: defect | Status: new
Priority: normal | Milestone: 1.5-software-update
Component: x window system | Version: not specified
Resolution: | Keywords:
Next_action: never set | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
---------------------------------------+------------------------------------
Comment(by wmb at firmworks.com):
OFW does indeed establish the values of quite a few display-related
registers on resume - but for the most part it sets them to known-good
values instead of trying to do the save/restore dance.
Results of analyzing register diffs between LeaveVT-sleep and EnterVT-
sleep:
a) Some registers should only matter when using a legacy VGA display mode
- i.e. irrelevant in a frame buffer mode: SR04,15,16,1a,1c,1d
CR00-0A,10-18,33,35 GR05,06,07 AR10-13 Misc bit 5
b) Some registers apply to the primary display controller, unused for the
XO: SR 44,45,46
c) OFW uses slightly different timing (56.2 MHz) than the Linux driver
(56.8 MHz): SR4a,4b,4c CR56,57m5em5f
d) Others: CR36 affects nonexistent external CRT. CR6a is for indexed
color mode.
e) Read-only registers: SR3d,3e,5b,5c CR60,61
f) LVDS stuff and LCD power sequencing that is irrelevant for OLPC:
CR88,8a-90,99
g) Performance tuning: SR58,59 CR68,94,95
Misc bit 7 - vertical sync polarity - might possibly be a problem.
The value of CR9B (0x00) in EnterVT-sleep seems blatantly wrong. When I
set that register to 0 in OFW, I lose the raster entirely. The correct
value 0x1b selects the secondary display engine as the data source to feed
to the DCON.
--
Ticket URL: <http://dev.laptop.org/ticket/10068#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list