Recent viafb changes break OLPC DCON freeze

Hi,

The OLPC XO-1.5 has a display controller (dcon) which is able to drive
the display while the video device is powered off (e.g. while the
system is in suspend). It works on demand, (approximately) by grabbing
the latest displayed picture (at the hardware level), storing it in
dedicated DCON RAM, and continually reproducing it on the screen. This
is known as "DCON freeze" and can also be triggered while the video
device is still running by executing:

echo 1 > /sys/devices/platform/dcon/freeze
(enabled by CONFIG_FB_OLPC_DCON_1_5)

Unfortunately this has broken in recent kernels due to viafb changes:
when going into "DCON freeze", the DCON fails to capture the display
contents and instead displays garbage. I am testing this on viafb
outside of X.

There are some complications in debugging this and pinpointing a
single responsible commit.

Kernels v2.6.38 and previous work fine. However, in such kernels, OLPC
included an out-of-tree DCON driver. 2.6.38 includes a DCON driver (in
staging) but it was not usable at this point.

v2.6.39 has a functional DCON driver, but viafb in this kernel is
unusable on XO-1.5 due to an unrelated bug which only got fixed for
3.0:
http://www.spinics.net/lists/linux-fbdev/msg03132.html

v3.0 and onwards reproduces the failure.

To debug this, I took the approach of starting with 2.6.38, fixing the
DCON driver in that old kernel, then going through the viafb changes
until the point of breakage was found. This can be done as follows:

git reset --hard v2.6.38

First, fix the DCON driver:

151 more lines

Hi Daniel,

thanks a lot for your debugging. I'm busy at the moment so I'll keep it short.

On 11/17/2011 04:24 PM, Daniel Drake wrote:

A further data point on this issue: we once hit exactly the same thing
on XO-1 (geode lxfb). A non-OLPC commit caused the v/h sync output
polarity to change. The display still worked correctly, but the DCON
freeze functionality caused garbage in exactly the same way as this
viafb issue. This suggests that the display itself isn't too fussy
about video signal parameters, but the DCON controller is picky and
expects certain parameters. (see commit ad913da61aeb for the lxfb
fix).

As you mentioned it, I had a look at this driver. It looks like viafb does it
(polarity) just the other way around than geode. So it might be wort a try to
change in

drivers/video/via/share.h:
/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       NEGATIVE
#define M1200X900_R60_VSP       NEGATIVE

to

/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       POSITIVE
#define M1200X900_R60_VSP       POSITIVE

Any thoughts?

If the above works it's just that the thing was initially entered wrong and now
we hit it as we start setting the polarity for the correct devices, similar to
the issue with the refresh rate.
If it does not work I'll have a deeper look at it as soon as possible.


Best regards,

Florian Tobias Schandinat

On Thu, Nov 17, 2011 at 8:14 PM, Florian Tobias Schandinat
[off-list ref] wrote:

As you mentioned it, I had a look at this driver. It looks like viafb does it
(polarity) just the other way around than geode. So it might be wort a try to
change in

drivers/video/via/share.h:
/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       NEGATIVE
#define M1200X900_R60_VSP       NEGATIVE

to

/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       POSITIVE
#define M1200X900_R60_VSP       POSITIVE

That fixes the problem - thanks! Let me know if you'd like me to make
a patch with that change (I can do so on Monday).

It may still be worth you looking at the diagnosis - in particular I
think I may have found something that may clean up some of the
uncertainty in commit 32fab7bc

Thanks
Daniel

Hi Daniel,

On 11/18/2011 04:09 PM, Daniel Drake wrote:

On Thu, Nov 17, 2011 at 8:14 PM, Florian Tobias Schandinat
[off-list ref] wrote:

quoted

As you mentioned it, I had a look at this driver. It looks like viafb does it
(polarity) just the other way around than geode. So it might be wort a try to
change in

drivers/video/via/share.h:
/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       NEGATIVE
#define M1200X900_R60_VSP       NEGATIVE

to

/* 1200x900@60 Sync Polarity (DCON) */
#define M1200X900_R60_HSP       POSITIVE
#define M1200X900_R60_VSP       POSITIVE

That fixes the problem - thanks! Let me know if you'd like me to make
a patch with that change (I can do so on Monday).

Yes, I'd appreciate it. Then I could queue this patch for 3.2, you might also
consider adding a "Cc: stable@kernel.org" to it so previous releases also get
fixed up.

It may still be worth you looking at the diagnosis - in particular I
think I may have found something that may clean up some of the
uncertainty in commit 32fab7bc

True. Well I already know that it was required for some reason to get the
output, so I merged my branch with the fix before I merged the one with the
problematic patch, to make regression testing easier. So now we know the display
wiring on OLPC better than the driver did some releases ago, though I'd be
happier if I'd find a generic way to figure these display wiring out...


Thanks,

Florian Tobias Schandinat

Thanks
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html