Opened 5 years ago

Closed 5 years ago

Last modified 21 months ago

#11430 closed defect (fixed)

Xv / mmp-camera output corrupt after suspend/resume

Reported by: martin.langhoff Owned by: jnettlet
Priority: high Milestone:
Component: kernel Version: not specified
Keywords: Cc: corbet
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no


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.

Attachments (1)

sr.patch (4.7 KB) - added by corbet 5 years ago.
Patch for camera s/r.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by martin.langhoff

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

comment:3 Changed 5 years ago by 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:// 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.

Changed 5 years ago by corbet

Patch for camera s/r.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by corbet

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

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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 :)

comment:8 Changed 5 years ago by 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/ to something else.

comment:9 Changed 5 years ago by corbet

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

comment:10 Changed 5 years ago by Quozl

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

comment:11 Changed 5 years ago by martin.langhoff

  • Cc corbet added
  • Owner changed from corbet to jnettlet

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

So re-assigning

comment:12 Changed 5 years ago by martin.langhoff

  • Summary changed from mmp-camera output corrupt after suspend/resume to Xv / mmp-camera output corrupt after suspend/resume

comment:13 Changed 5 years ago by Quozl

  • Action Needed changed from never set to test in build

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

comment:14 Changed 5 years ago by 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.

comment:15 Changed 5 years ago by martin.langhoff

  • Resolution set to fixed
  • Status changed from new to closed

comment:16 Changed 21 months ago by Quozl

  • Milestone 1.75-software deleted

Milestone 1.75-software deleted

Note: See TracTickets for help on using tickets.