Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Simon Farnsworth <simon.farnsworth@onelan.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
> I prefer if you don't c/c me on that ;) Patchwork is the main source that I use
> on my patch reviews.
> 
Noted.

> Btw, I saw your patch yesterday (and skipped it, for now), as I never played
> with those pm QoS stuff before, nor I ever noticed anything like what you
> reported on saa7134 (but I can't even remember the last time I tested something
> on a saa7134 board ;) - so, it can be some new bug).
> 
> So, I'll postpone its review to when I have some time to actually test it
> especially as the same issue might also be happening on other drivers.
> 
It will affect other drivers as well; the basic cause is that modern chips
can enter a package deep sleep state that affects both CPU speed and latency
to start of DMA. On older systems, this couldn't happen - the Northbridge
kept running at all times, and DMA latencies were low.

However, on the Intel Sandybridge system I'm testing with, the maximum wake
latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
hold onto data for that long, and overflows, resulting in the corruption I'm
seeing. The pm QoS request fixes this for me, by telling the PM subsystem
that the SAA7134 cannot cope with a long latency on the first write of a DMA
transfer.

Now, some media bridges (like the ones driven by the cx18 driver) can cope
with very high latency before the beginning of a DMA burst. Andy Walls has
worked on the cx18 driver to cope in this situation, so it doesn't fail even
with the 109 microsecond DMA latency we have on Sandybridge.

Others, like the SAA7134, just don't have that much buffering, and we need
to ask the pm core to cope with it. I suspect that most old drivers will need
updating if anyone wants to use them with modern systems; either they'll have
an architecture like the cx18 series, and the type of work Andy has done will
fix the problem, or they'll behave like the saa7134, and need a pm_qos request
to ensure that the CPU package (and thus memory controller) stay awake.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]