intel i2cs : Manage i2c runtime power management from userspace |
|||||
Issue descriptionRecent Intel architectures (Braswell, Skylake, Apollo Lake, Kaby Lake...) have their i2c devices as PCIe devices, which drop down to D3 state when not used for a little bit. See : https://code.google.com/p/chrome-os-partner/issues/detail?id=54986#c69 This is not great because many of the devices we have on the i2c busses are input devices, so delay is something the user can perceive. This feature request is to have something in userspace manage these devices so that they are runtime_status == active most of the time when the user may use the input devices. Just an example, on my Reef system, here's the touchscreen's i2c's device/power nodes : /sys/bus/i2c/devices/i2c-9/device/power In that directory is control, which is set to "auto" and autosuspend_delay_ms, which is set to "1000" Potential approaches : 1. Leave i2c power/control to auto, but set the autosuspend_delay_ms to a higher value, for example 10 minutes 2. Leave autosuspend_delay_ms set to 1000, but have something (power manager, or powersave, maybe?) set control from "on" -> "auto" only when the screen is off, or when appropriate for bus. (thinking that when we are in tablet mode, we can go ahead and set the i2c bus for the trackpad to "auto" immediately. #1 is easy. I could write a quick udev rule to do that. #2 is better for the long term, but we'll have to find a way to express this as policy, maybe related to the powerd tagging changes that currently manage power/wakeup.
,
Jan 12 2017
For approach #2, powerd should already be configuring wakeup and inhibit for these devices, so yeah, it's probably pretty easy to just add another udev tag that tells it to also configure autosuspend.
,
Jan 13 2017
on caroline : 3.5mw difference between when the screen is on (pch_prim_core : 34.16 vs 30.74) 3.75mw difference when the screen is off (pch_prim_core : 27.43 vs 31.25) Will verify the same on Reef.
,
Feb 17 2017
,
Mar 2 2017
Given there's already management of these input devices w/in powerd it sounds like it would be easy to add there such that we're in 'auto' during screen-off and 'on'. However given our minimal time spent in screen off and the small power delta would it be simpler to just add a udev rule for these devices? Could we identify just those that are inputs & behind pcie? Would it just be per platform? Also, https://buganizer.corp.google.com/issues/35774937#comment14 mentions, Most of the latency is attributed to an 100ms msleep in the pci driver d3cold resume path. The duration of that msleep defaults to 100ms if a shorter value hasn't been specified though ACPI. We believe the delay is entirely unneeded and have assigned a coreboot engineer to modify the ACPI _DSM accordingly. Could this or something similar be unnecessarily delaying d3 exit on the kernel side? Ravi can you grab the numbers for reef like those in #c4. Then re-assign to me.
,
Nov 7
This is something that has come back up on Octopus. Derek, could you measure for Octopus like what was done in #4?
,
Nov 29
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by snanda@chromium.org
, Jan 11 2017