Xv / mmp-camera output corrupt after suspend/resume

[martin.langhoff]

Steps to repro

• Install 11.3.1 development stream OS 9 (which has a S/R capable kernel)
• From a terminal, start a gstreamer pipeline, running /runin/runin-camera, while that is up...
• rtcwake -s 10 -m mem

When the system resumes, the camera output continues, but it looks like a gimp or photoshop "edge detect" filter.

[corbet]

Given that the code had never actually been through a suspend/resume cycle before, that seems like something close to a best-case result. And edge filters can be awfully nice...and it will be faster than running the GIMP on an XO...

I'll have a look at it soon.

[martin.langhoff]

Agreed -- I had assumed we'd get fireworks on the first s/r attempt, and was quite impressed with the results.

[corbet]

OK... the core problem is that the bozo who wrote the camera driver put suspend/resume on the "do this after it works" list, then never quite got around to doing it. So I had to add s/r support (pretty easy) and track down a couple of subtle issues in the s/g DMA code (not so easy). The result works for me. I'll attach a patch, or it can be pulled from:

git://git.lwn.net/linux-2.6.git arm-3.0-wip-cam

(I need to rename that repo one of these days...)

I do believe this one is fixed with this patch; please do let me know if that turns out to be the case.

[corbet]

Patch for camera s/r.

[martin.langhoff]

I've put the patch to test in one of our testbeds. Maybe it resolves some S/R hangs we've been seeing under runin.

It does _not_ resolve the odd video after resume. Now after resume we get a mix of 3 conditions, at random: black image, random posterizing or "edge" effect, normal.

So sometimes it resumes with a normal image. In that aspect, it's progress.

[corbet]

I put it through a lot of cycles and never got a corrupt image. Figures. How exactly are you getting this result?

[martin.langhoff]

This is under "runin" which is a "burnin"-style suite of scripts.

The simplest recipe I can think of is what's outlined in the description of this bug (gstreamer pipeline, then rtcwake). I haven't tested it under this simplified recipe though -- maybe there's something else at play.

Are you up to date on our general OS image? OS16 or OS17 should be about right. Maybe there is an additional problem in the Xv surface handling, and you're using an older X driver that doesn't hit it.

[corbet]

Most of my testing was the gstreamer/rtcwake mode. But I've been running the os17 version of runin almost nonstop working on the IRQ 48 problem, and the suspend cycles there have always worked so far.

For various reasons, I'm not actually running the os17 install; my USB key has a much older system. Booting straight os17, among other things, wants to "upgrade" my firmware into brick mode. With a bit of tweaking, though, I should be able to run the full os17 with my kernel. I'll get into that once I'm confident of my fixes for the IRQ issue.

I must admit I like the idea that it could be an xv issue and not my problem anymore :)

[pgf]

jon -- to prevent the auto-firmware-upgrade, do your first boot running on battery, or AC, but not both. that will suppress it that time. to suppress it permanently, rename /bootpart/boot/bootfw.zip to something else.

[corbet]

FWIW, just watching a video with mplayer (no camera involved) also yields corrupted visuals after a resume.

[Quozl]

Still a problem on os18, have you been able to reproduce, Jon?

[martin.langhoff]

I think Jon Corbet has declared it to be an Xv surface issue, and passed the hot potato to Jon Nettleton.

So re-assigning

[Quozl]

A fix is available, says Jon Nettleton. os24 plus additional packages, being tested.

[erikos]

I did do the test with '/runin/runin-camera' and 'rtcwake -s 10 -m mem' like mentioned in the description and the video was as expected after S/R, no extra effects added.