Need programmable delay to turn off DCON chip.

[jg]

While the DCON can power down the LCD on its own after a programmable delay (already being used by the DPMS code in the X server, I believe), the DCON itself consumes lots of power (several hundred millwatts). We need to get it off when not in use after a second delay. I'm concerned about a child reading a book and forgetting to get the screen completely off.

We need to be able to set a timeout to turn off the DCON as well, complimentary to the DCON's control of the LCD panel.

[David.Lin]

The EC has supported the command (0x26) for enable/disable DCOM. I don’t know what you want. Can you tell me the detail you want?

[jg]

David, I need to be able to set a time at which the DCON will be turned off. Otherwise, I have to wake the system up just to turn off the screen, which is complicated and messy.

Glad to hear the basic feature is there, though.

[rsmith]

Replying to jg:

David, I need to be able to set a time at which the DCON will be turned off. Otherwise, I have to wake the system up just to turn off the screen, which is complicated and messy.

Some questions I have:

What do you want to use to reset the timeout? Key/touch pad activity and the Game Keys or when the host wakes up and processes a command and thus does EC activity. What is this timeout measured in seconds? Minutes? Whats the default?

The kernel need to sprout knowledge of DCON init. Whats the mechanism for the kernel to discover that the dcon has been powered down and that it needs to re-enable it? I don't think you want the kernel to re-do the init every wakeup so the kernel will either have to query the EC on wakeup for this info or keep its own timer and state info.

There are some generic things like power up time here to consider as well. I don't know how long it takes the dcon to stabilize after you power it on. Can we properly detect dcon command failure in the kernel and know that we have/have not re-established dcon init 100% correctly?

I'm not so sure that the EC doing this on its own is going to be that much cleaner than just waking up the kernel via an RTC to do it. Turning off is the easy part.

[David.Lin]

According to Richard's mail, I think we should not support this function on EC.

[kimquirk]

Changing ownership to Richard to make the call.

[jg]

Here's the scoop.

Say I'm in ebook mode do we really want to wake the system up just to fully power off the screen and fully suspend? Maybe so.

Next step: Richard, jg and cjb should meet to discuss the best way to meet the need of a system that has been left alone in ebook mode getting the screen and dcon fully powered off after an appropriate (set of) delays, so that it does not drain the battery for absolutely no good reason. But we now have to figure this out.

[wmb@…]

My vote is to do this in the kernel. I strongly feel that the EC is already doing more than it can do reliably. Adding more functions to it is just asking for trouble.

[jg]

not even clear it should be in the kernel... It may be something we do in ohm, by waking up completely...

let's see where the OHM path leads, before we presume we have to hack the kernel or EC...

[cjb]

We're not sure of the priority on this one -- Jim/Kim/cjb plan to meet 11/7 to discuss.

[jg]

Jordan says there's still a risk of crashes when setting RTC alarms, if they have a short duration.

[cjb]

Pushing this to 8.2.1.

[gnu]

Why do we need to delay turning off the DCON chip? We now turn off the WiFi immediately when it's not needed, and re-power it as soon as it is needed. I think we should try powering off the DCON chip anytime we're asking the DCON chip to power off the screen. This would save a bunch of power, have no user-visible effect, and doesn't require any more complex timers. What it does require is the ability to power-on and reinitialize the DCON when we next need it.

(Only if powering the DCON back on requires some long, visible delay, will this cause any trouble for the end user.)

PS: Waking the CPU. having Ohm turn things on or off, then decide to shut down the CPU again, is simple. We are already doing it, mostly when we have bugs in ohm that make it go right back to sleep after a wakeup. Such as when it used to get confused about the state of the lid-closed switch.

[cjb]

Hi,

I think we should try powering off the DCON chip anytime we're asking the DCON chip to power off the screen.

We already do that. This bug is talking about the scenario of:

• we're going into idle suspend, so we dim the screen
• but if we haven't been woken up five minutes later, then we want to save power by turning off the screen and DCON
• but we can't run any code on the CPU because we turned it off.

Waking the CPU. having Ohm turn things on or off, then decide to shut down the CPU again, is simple.

Only if you rely on something else to trigger the waking for you. We haven't yet set wakeups for ourself, and that's the main feature of this bug. (I'm not saying it's difficult, just that it's new code to set timed wakeups, and track whether a timed wakeup is the reason we just woke up.)

[gregorio]

Took relnote off this one.

We have enough details on power save "instablity" in the notes already.

That said, it looks like a good one to address in a future release.

Thanks,

Greg S