Ticket #2765 (new defect)

Opened 7 years ago

Last modified 5 years ago

Need programmable delay to turn off DCON chip.

Reported by: jg Owned by: cjb
Priority: blocker Milestone: 9.1.0-cancelled
Component: power manager (OHM) Version:
Keywords: power cjbfor9.1.0 Cc: jg, rsmith, cjb, dilinger, gnu, mikus
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description (last modified by jg) (diff)

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.

Change History

  Changed 7 years ago by 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?

follow-up: ↓ 3   Changed 7 years ago by jg

  • cc jg added

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.

in reply to: ↑ 2   Changed 7 years ago by rsmith

  • cc rsmith added

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.

  Changed 7 years ago by David.Lin

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

  Changed 7 years ago by kimquirk

  • owner changed from David.Lin to rsmith

Changing ownership to Richard to make the call.

  Changed 6 years ago by jg

  • cc cjb added
  • priority changed from high to blocker
  • milestone changed from Untriaged to XM - killjoy

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.

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

  Changed 6 years ago by jg

  • cc dilinger added
  • component changed from embedded controller to power manager (OHM)
  • description modified (diff)
  • summary changed from EC needs programmable delay to turn off DCON chip. to Need programmable delay to turn off DCON chip.

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...

  Changed 6 years ago by jg

  • owner changed from rsmith to cjb

  Changed 6 years ago by cjb

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

  Changed 6 years ago by jg

  • keywords power, relnote added; power removed
  • milestone changed from Update.1 to Update.2

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

  Changed 6 years ago by cjb

  • next_action set to never set
  • milestone changed from 8.2.0 (was Update.2) to 8.2.1

Pushing this to 8.2.1.

  Changed 6 years ago by gnu

  • cc gnu added

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.

  Changed 6 years ago by 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.)

  Changed 6 years ago by gregorio

  • keywords power added; power, relnote removed

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

  Changed 5 years ago by mstone-xmlrpc

  • keywords cjbfor9.1.0 added
  • milestone changed from 8.2.1 to 9.1.0

Pushing out to 9.1.0, per edmcnierney's request.

  Changed 5 years ago by mikus

  • cc smith, mikus added; rsmith removed

  Changed 5 years ago by mikus

  • cc rsmith added; smith removed
Note: See TracTickets for help on using tickets.