Opened 7 years ago

Last modified 7 years ago

#1412 new enhancement

Switch from driving the panel from the Geode to the DCON when the display is idle.

Reported by: jg Owned by: bernie
Priority: high Milestone: 8.2.0 (was Update.2)
Component: x window system Version:
Keywords: power Cc: cjb, JordanCrouse
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description (last modified by jg)

If the GPU is idle for some length of time, (say, several frame times), it will almost certainly make sense to turn off the video drivers to the DCON and switch to DCON mode, to reduce the power consumption caused by the video drivers and the memory accesses to main memory.

X knows if someone is using the GPU; we have a place to stand for the system software to make this decision.

JG's not quite sure the best implementation strategy; we could have a dead-man switch in the kernel driver, or set up some sort of idle timer in the X server (or probably other implementation strategies as well).

As always, we should measure the benefit to understand the proper idle time: the cost here is the latency for the Geode to resume driving the display (which is short, but possibly perceptable). And it may want to be policy based as well, depending on whether we are on battery power or not.

Attachments (3)

add-fb-set-power.patch (19.4 KB) - added by JordanCrouse 7 years ago.
dcon-hack-3.patch (5.1 KB) - added by dilinger 7 years ago.
ajax's freeze-dcon-when-idle patch
x (5.9 KB) - added by dilinger 7 years ago.
drop dcon_{en,dis}able, simplify file handling, reverse freeze polarity, etc

Download all attachments as: .zip

Change History (17)

comment:1 Changed 7 years ago by jg

  • Description modified (diff)

comment:2 follow-up: Changed 7 years ago by JordanCrouse

Bear in mind - it will cost us up to a frame of time to switch back into CPU mode. The DCON always keeps a frames worth of data in its internal memory; so when we switch back to CPU mode, we have to wait for a frames worth of data to fill the memory before switching back to CPU mode, otherwise, the DCON will gitch, @56Hz, thats at most a 17ms delay.

At one time, we also suffered the 64ms delay of turning back on the panel power (which has no effect on our actual power usage, but the bit also controls the panel data pins, so it must be enabled). I think we can safely leave the panel power on when we switch into DCON mode. I believe it will cost us a little more power, but with the shorter delay, we can switch into DCON mode more often.

comment:3 Changed 7 years ago by jg

  • Keywords power added
  • Milestone changed from CTest to BTest-4
  • Priority changed from normal to high

comment:4 in reply to: ↑ 2 Changed 7 years ago by gnu

Replying to JordanCrouse:

Bear in mind - it will cost us up to a frame of time to switch back into CPU mode. The DCON always keeps a frames worth of data in its internal memory; so when we switch back to CPU mode, we have to wait for a frames worth of data to fill the memory before switching back to CPU mode, otherwise, the DCON will gitch, @56Hz, thats at most a 17ms delay.

The DCON spec 0.8 says there's no delay to switch back into CPU mode. Whether that matches the chip remains to be seen. If the CPU raises DCONLOAD, the DCON will continue the current frame til the bottom, then switch immediately to displaying data from the CPU video interface, starting at the trailing edge of the CPU's vertical retrace pulse. After DCONLOAD is high and the DCON has switched, the internal memory is not cycling; the CPU video data flows straight through into the panel. When DCONLOAD is lowered, the DCON will keep flowing CPU data straight through, til vertical retrace. Then it keeps flowing data through for one more frame, while it writes an entire frame into its internal RAM. Then at the second vertical retrace, it switches to displaying with the internal memory and internal timing (and it interrupts the CPU to tell it to turn off the CPU video). Thus the "frame delay" happens at the shutoff end, not the turnon end (and we hope that when we're about to shut off the CPU video, each frame is identical to the previous one, so it doesn't matter which one the DCON grabs).

comment:5 Changed 7 years ago by wmb@…

The turn-on delay occurs because you are supposed to synchronize the GPU vertical frame to coincide with the DCON's, to prevent display artifacts. You have to wait for a DCON vertical retrace, then turn on the CPU's display clock.

Reference: DCON Specification, page 11, second paragraph.

Even if the CPU's DOTCLK remains on, the possibility of clock drift must be considered, in which case we might have to restart the clock synchronously with the DCON frame to avoid display artifacts. Experimentation will be necessary to establish what level of complexity is required. Based on my experience with DCON so far, the job is not likely to be a "slam dunk".

comment:6 Changed 7 years ago by jg

  • Owner changed from rsmith to ajax
  • Verified unset

comment:7 Changed 7 years ago by wmb@…

Richard measured a savings of 60 mW by changing the DCON refresh rate from 50 Hz to 25 Hz.

comment:8 Changed 7 years ago by kimquirk

  • Milestone changed from BTest-4 to Trial-2

Moving to next software release, Trial-2. (If this does get done for a B4 build, we should change the build number on the bug back.)

comment:9 Changed 7 years ago by JordanCrouse

This is heating up. The executive summary so far - we're having trouble lining up the GPU vsync with the blanking period on the DCON - discussions about how that might work are varied. For my part, I've changed the powerup and powerdown functions to be more generic and allow us to do
multiple power states if needed in the DCON driver. Attaching the patch - it will get tested and committed following the B4 effort.

Changed 7 years ago by JordanCrouse

comment:10 Changed 7 years ago by jg

  • Milestone changed from Trial-2 to Trial-3

Kernel patch still buggy, deferring to Trial-3.

Note the dot clock can also get shut down.

comment:11 Changed 7 years ago by dilinger

Ok, ajax's patches to combat flicker when switching between DCON and CPU sources have been committed to the kernel. The other missing part of this is the code for the X driver to enable switching to DCON mode when the X server is not in the process of redrawing the screen. I have two patches; the original one from ajax, which doesn't appear to work for us, and an updated patch with cleanups, debugging, and some renamed functions.

Changed 7 years ago by dilinger

ajax's freeze-dcon-when-idle patch

Changed 7 years ago by dilinger

  • Attachment x added

drop dcon_{en,dis}able, simplify file handling, reverse freeze polarity, etc

comment:13 Changed 7 years ago by dilinger

  • Owner changed from ajax to bernie

Here's to hoping bernie can make it go..

comment:14 Changed 7 years ago by jg

  • Milestone changed from Trial-3 to First Deployment, V1.0
Note: See TracTickets for help on using tickets.