(please cc me on replies - I'm not directly subscribed to linux-kernel or linux-pm)
I'm trying to track down why a Sandybridge system with a PCIe to PCI riser has problems after enabling GPU RC6, and I've reduced my problem to the menu cpuidle governor selecting high C-states from intel_idle, even though I've given a cpu_dma_latency requirement of 0 usecs. I have a TV capture card in the riser, and it appears that I get data lost whenever the package enters a high C state. My userspace opens /dev/cpu_dma_latency and writes (uint32_t)0 to this fd whenever we have things on-screen, closing the fd when we put the screen into DPMS off states. However, even with a userspace provided request of 0 usec, I'm seeing the CPU cores (and hence the entire package when GPU RC6 is enabled) enter C6 state. I've confirmed that forcing the governor to limit itself to C0 fixes my problem with: # for state in /sys/devices/system/cpu/cpu*/cpuidle/state[1-9]*/disable ; do echo 1 > $state ; done What do I need to do to get the menu cpuidle governor and the intel_idle cpuidle driver to respect the /dev/cpu_dma_latency pm_qos request of 0 usec and keep the Sandybridge CPU package out of low C states? Note that a CPU core in low C state is fine, as long as the DMA latency stays low. My goal is to keep the system in high-performance state when we're rendering digital signage on screen (as any glitching may upset viewers, and compared to the screen's full power use, we're irrelevant), but to go into lower power states when the screen is off (when we're only drawing power to keep the administrator interface available). My kernel is currently 3.7-rc1+, based on Linus git of Tuesday 16th October 2012. I'm happy to try patches, even if all they get you is better debug output to work out why the userspace request is ignored. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.