XO-1 DCON trouble with new kernels

[Mitch Bradley]

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

On 11/13/2010 1:08 PM, Daniel Drake wrote:
> Hi,
>
> 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
> happen.
> 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?
>
> Thanks,
> Daniel