XO-1 DCON trouble with new kernels
wmb at laptop.org
Sat Nov 13 18:30:53 EST 2010
The DCON does not "see" video memory directly - it works with the
real-time display data that is driven onto the wires that would normally
go to an LCD panel.
I wonder if, in the VT case, the driver is stopping the display
controller soon after clearing the DCONLOAD pin? In that case, I can
imagine that the DCON would be unable to capture new data because it
would no longer have PIXCLK, HYSNC, and VSYNC to time its acquisition of
a frame of data.
Naively, I would think that the loss of those timing signals might
prevent the "switched" interrupt, but I can't think of any other
possibility offhand, so check that. Maybe as a quick test you could add
a 40 ms delay right after clearing DCONLOAD, thus ensuring that the
display controller doesn't turn off until a couple of frame times have
On 11/13/2010 1:08 PM, Daniel Drake wrote:
> I'm hoping that someone can point me in the right direction, regarding
> how the DCON works.
> On new kernels, XO-1 DCON freeze doesn't work when you are on the
> virtual terminal. The current display does not seem to get loaded into
> the DCON memory, but then the freeze (video source switch) does
> The DCON code has not changed between these kernel versions.
> It still works OK when you are in X.
> To illustrate more:
> 1. Boot up XO
> 2. Change to virtual terminal
> 3. echo 1> /sys/devices/platform/dcon/freeze
> You now see the image that OFW froze the screen with before booting Linux
> 4. echo 0> /sys/devices/platform/dcon/freeze
> Unfreeze works fine.
> 5. Go into X
> 6. echo 1> /sys/devices/platform/dcon/freeze
> Display freezes fine, with the X display contents
> 7. echo 0> /sys/devices/platform/dcon/freeze
> 8. Go to virtual terminal
> 9. echo 1> /sys/devices/platform/dcon/freeze
> Display freezes fine, with the X display contents that were frozen in step 6
> I have examined the steps taken between the working (X) and
> non-working (VT) cases. They appear the same - after requesting the
> switch, an interrupt arrives, and status is read back as 2 at that
> time (switch to DCON mode complete).
> Any idea what could be the cause of this?
> For example, does the DCON only copy a certain region of video memory?
> Perhaps Linux VT is now using a different region.
> Or, any suggested diagnostics?
More information about the Devel