1. 13 4月, 2016 3 次提交
    • J
      i2c: i801: Add runtime PM support with autosuspend · a7401ca5
      Jarkko Nikula 提交于
      Allow runtime PM so that PM and PCI core can put the device into low-power
      state when idle and resume it back when needed in those platforms that
      support PM for i801 device.
      
      Enable also autosuspend with 1 second delay in order to not needlessly
      toggle power state on and off if there are multiple transactions during
      short time.
      
      Device is resumed at the beginning of bus access and marked idle ready
      for autosuspend at the end of it.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Tested-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      a7401ca5
    • J
      i2c: i801: Convert to struct dev_pm_ops for suspend/resume · 2ee73c48
      Jarkko Nikula 提交于
      Stop using legacy PCI PM support and convert to standard dev_pm_ops.
      This provides more straightforward path to add runtime PM.
      
      While at it remove explicit PCI power state control and configuration space
      save/restore as the PCI core does it.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Tested-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      2ee73c48
    • L
      i2c: let I2C masters ignore their children for PM · 04f59143
      Linus Walleij 提交于
      When using a certain I2C device with runtime PM enabled on
      a certain I2C bus adaper the following happens:
      
      struct amba_device *foo
         \
         struct i2c_adapter *bar
            \
            struct i2c_client *baz
      
      The AMBA device foo has its device PM struct set to ignore
      children with pm_suspend_ignore_children(&foo->dev, true).
      This makes runtime PM work just fine locally in the driver:
      the fact that devices on the bus are suspended or resumed
      individually does not affect its operation, and the hardware
      does not power up unless transferring messages.
      
      However this child ignorance property is not inherited into
      the struct i2c_adapter *bar.
      
      On system suspend things will work fine.
      
      On system resume the following annoying phenomenon occurs:
      
      - In the pm_runtime_force_resume() path of
        struct i2c_client *baz, pm_runtime_set_active(&baz->dev); is
        eventually called.
      
      - This becomes __pm_runtime_set_status(&baz->dev, RPM_ACTIVE);
      
      - __pm_runtime_set_status() detects that RPM state is changed,
        and checks whether the parent is:
        not active (RPM_ACTIVE) and not ignoring its children
        If this happens it concludes something is wrong, because
        a parent that is not ignoring its children must be active
        before any children activate.
      
      - Since the struct i2c_adapter *bar does not ignore
        its children, the PM core thinks that it must indeed go
        online before its children, the check bails out with
        -EBUSY, i.e. the i2c_client *baz thinks it can't work
        because it's parent is not online, and it respects its
        parent.
      
      - In the driver the .resume() callback returns -EBUSY from
        the runtime_force_resume() call as per above. This leaves
        the device in a suspended state, leading to bad behaviour
        later when the device is used. The following debug
        print is made with an extra printg patch but illustrates
        the problem:
      
      [   17.040832] bh1780 2-0029: parent (i2c-2) is not active
                     parent->power.ignore_children = 0
      [   17.040832] bh1780 2-0029: pm_runtime_force_resume:
                     pm_runtime_set_active() failed (-16)
      [   17.040863] dpm_run_callback():
                     pm_runtime_force_resume+0x0/0x88 returns -16
      [   17.040863] PM: Device 2-0029 failed to resume: error -16
      
      Fix this by letting all struct i2c_adapter:s ignore their
      children: i2c children have no business doing keeping
      their parents awake: they are completely autonomous
      devices that just use their parent to talk, a usecase
      which must be power managed in the host on a per-message
      basis.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      04f59143
  2. 12 4月, 2016 16 次提交
  3. 09 4月, 2016 2 次提交
  4. 08 4月, 2016 1 次提交
  5. 01 4月, 2016 1 次提交
  6. 30 3月, 2016 1 次提交
    • W
      i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE · 8dcf3217
      Wolfram Sang 提交于
      Jan reported this:
      
      ===
      After enabling CONFIG_I2C_DEBUG_CORE my system was broken
      (no network, console login not possible). System log was
      flooded with the this message:
      
       ...
      [  608.052077] rtc-ds1307 0-0068: uevent
      [  608.052500] rtc-ds1307 0-0068: uevent
      [  608.052925] rtc-ds1307 0-0068: uevent
       ...
      
      The culprit is the dev_dbg printk in the i2c uevent handler.
      If this is activated (for instance by CONFIG_I2C_DEBUG_CORE)
      it results in an endless loop with systemd-journald.
      
      This happens if user-space scans the system log and reads the uevent
      file to get information about a newly created device, which seems fair
      use to me. Unfortunately reading the "uevent" file uses the same
      function that runs for creating the uevent for a new device,
      generating the next syslog entry.
      
      Ideally user-space would implement a recursion detection and
      after reading the same device file for the 1000th time call it a
      day, but nevertheless I think we should avoid this problem by
      removing the debug print completely or using another print variant.
      
      The same problem seems to be reported here:
      https://bugs.freedesktop.org/show_bug.cgi?id=76886
      ===
      
      His patch converted the message to pr_debug, but I think the debug can
      simply go. We have other means to see code paths these days. This
      enables us to clean up the function some more while we are here.
      Reported-by: NJan Glauber <jglauber@cavium.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Acked-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Tested-by: NJan Glauber <jglauber@cavium.com>
      8dcf3217
  7. 18 3月, 2016 3 次提交
  8. 15 3月, 2016 1 次提交
  9. 12 3月, 2016 4 次提交
  10. 11 3月, 2016 1 次提交
  11. 04 3月, 2016 4 次提交
  12. 02 3月, 2016 1 次提交
  13. 24 2月, 2016 2 次提交