1. 12 10月, 2018 1 次提交
  2. 07 9月, 2018 1 次提交
  3. 31 8月, 2018 1 次提交
    • H
      i2c: designware: Re-init controllers with pm_disabled set on resume · 9d9a152e
      Hans de Goede 提交于
      On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C
      busses which the OS shares with the PUNIT as these need special handling.
      Until now we called dev_pm_syscore_device(dev, true) for I2C controllers
      with this flag set to keep these I2C controllers always on.
      
      After commit 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and
      resume from hibernation"), this no longer works. This commit modifies
      lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran
      before it, so that it does not run on a resume from hibernate (or from S3).
      
      On these systems the conditions for lpss_iosf_enter_d3_state() to run
      never become true, so lpss_iosf_exit_d3_state() never gets called and
      the 2 LPSS DMA controllers never get forced into D0 mode, instead they
      are left in their default automatic power-on when needed mode.
      
      The not forcing of D0 mode for the DMA controllers enables these systems
      to properly enter S0ix modes, which is a good thing.
      
      But after entering S0ix modes the I2C controller connected to the PMIC
      no longer works, leading to e.g. broken battery monitoring.
      
      The _PS3 method for this I2C controller looks like this:
      
                  Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
                  {
                      If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06)))
                      {
                          Return (Zero)
                      }
      
                      PSAT |= 0x03
                      Local0 = PSAT /* \_SB_.I2C5.PSAT */
                  }
      
      Where PMID = 0x05, so we enter the Return (Zero) path on these systems.
      
      So even if we were to not call dev_pm_syscore_device(dev, true) the
      I2C controller will be left in D0 rather then be switched to D3.
      
      Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all*
      I2C controllers are in D3 mode. This combined with the I2C controller no
      longer working now that we reach S0ix states on these systems leads to me
      believing that the PUNIT itself puts the I2C controller in D3 when all
      other conditions for entering S0ix states are true.
      
      Since now the I2C controller is put in D3 over a suspend/resume we must
      re-initialize it afterwards and that does indeed fix it no longer working.
      
      This commit implements this fix by:
      
      1) Making the suspend_late callback a no-op if pm_disabled is set and
      making the resume_early callback skip the clock re-enable (since it now was
      not disabled) while still doing the necessary I2C controller re-init.
      
      2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend
      and resume callbacks are actually called. Normally this would cause the
      ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc
      since it is shared with the PUNIT, but in this special case the _PS3 method
      is a no-op so we can safely allow a "fake" suspend / resume.
      
      Fixes: 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      9d9a152e
  4. 20 8月, 2018 1 次提交
  5. 09 8月, 2018 1 次提交
  6. 05 8月, 2018 1 次提交
  7. 04 7月, 2018 5 次提交
  8. 15 5月, 2018 1 次提交
    • A
      i2c: designware: refactor low-level enable/disable · 9f4659ba
      Alexander Monakov 提交于
      Low-level controller enable function __i2c_dw_enable is overloaded to
      also handle disabling. What's worse, even though the documentation
      requires polling the IC_ENABLE_STATUS register when disabling, this
      is not done: polling needs to be requested specifically by calling
      __i2c_dw_enable_and_wait, which can also poll on enabling, but that
      doesn't work if the IC_ENABLE_STATUS register is not implemented.
      This is quite confusing if not in fact backwards.
      
      Especially since the documentation says that disabling should be
      followed by polling, the driver should be using a separate function
      where it does one-shot disables to make the optimization stand out.
      
      This refactors the two functions so that requested status is given
      in the name rather than in a boolean argument. Specifically:
      
       - __i2c_dw_enable: enable without polling (in accordance with docs)
       - __i2c_dw_disable: disable and do poll (also as suggested by docs)
       - __i2c_dw_disable_nowait: disable without polling (Linux-specific)
      
      No functional change.
      Signed-off-by: NAlexander Monakov <amonakov@ispras.ru>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      [wsa: fixed blank lines in header file]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      9f4659ba
  9. 10 5月, 2018 1 次提交
  10. 18 3月, 2018 1 次提交
  11. 22 2月, 2018 1 次提交
  12. 21 2月, 2018 1 次提交
    • B
      i2c: designware: must wait for enable · fba4adbb
      Ben Gardner 提交于
      One I2C bus on my Atom E3845 board has been broken since 4.9.
      It has two devices, both declared by ACPI and with built-in drivers.
      
      There are two back-to-back transactions originating from the kernel, one
      targeting each device. The first transaction works, the second one locks
      up the I2C controller. The controller never recovers.
      
      These kernel logs show up whenever an I2C transaction is attempted after
      this failure.
      i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
      i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready
      
      Waiting for the I2C controller status to indicate that it is enabled
      before programming it fixes the issue.
      
      I have tested this patch on 4.14 and 4.15.
      
      Fixes: commit 2702ea7d ("i2c: designware: wait for disable/enable only if necessary")
      Cc: linux-stable <stable@vger.kernel.org> #4.13+
      Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      fba4adbb
  13. 28 11月, 2017 1 次提交
  14. 04 7月, 2017 1 次提交
  15. 20 6月, 2017 3 次提交
  16. 01 6月, 2017 1 次提交
  17. 22 3月, 2017 1 次提交
    • H
      i2c: designware: Never suspend i2c-busses used for accessing the system PMIC · 41c80b8a
      Hans de Goede 提交于
      Currently we are already setting a pm_runtime_disabled flag and disabling
      runtime-pm for i2c-busses used for accessing the system PMIC on x86.
      But this is not enough, there are ACPI opregions which may want to access
      the PMIC during late-suspend and early-resume, so we need to completely
      disable pm to be safe.
      
      This commit renames the flag from pm_runtime_disabled to pm_disabled and
      adds the following new behavior if the flag is set:
      
      1) Call dev_pm_syscore_device(dev, true) which disables normal suspend /
         resume and remove the pm_runtime_disabled check from dw_i2c_plat_resume
         since that will now never get called. This fixes suspend_late handlers
         which use ACPI PMIC opregions causing errors like these:
      
        PM: Suspending system (freeze)
        PM: suspend of devices complete after 1127.751 msecs
        i2c_designware 808622C1:06: timeout waiting for bus ready
        ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion]
        acpi 80860F14:02: Failed to change power state to D3hot
        PM: late suspend of devices failed
      
      2) Set IRQF_NO_SUSPEND irq flag. This fixes resume_early handlers which
         handlers which use ACPI PMIC opregions causing errors like these:
      
        PM: resume from suspend-to-idle
        i2c_designware 808622C1:06: controller timed out
        ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion]
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      41c80b8a
  18. 02 3月, 2017 1 次提交
  19. 15 2月, 2017 1 次提交
  20. 10 2月, 2017 1 次提交
  21. 26 11月, 2016 1 次提交
    • J
      Revert "i2c: designware: do not disable adapter after transfer" · 89119f08
      Jarkko Nikula 提交于
      This reverts commit 0317e6c0.
      
      Srinivas reported recently touchscreen and touchpad stopped working in
      Haswell based machine in Linux 4.9-rc series with timeout errors from
      i2c_designware:
      
      [   16.508013] i2c_designware INT33C3:00: controller timed out
      [   16.508302] i2c_hid i2c-MSFT0001:02: failed to change power setting.
      [   17.532016] i2c_designware INT33C3:00: controller timed out
      [   18.556022] i2c_designware INT33C3:00: controller timed out
      [   18.556315] i2c_hid i2c-ATML1000:00: failed to retrieve report from device.
      
      I managed to reproduce similar errors on another Haswell based machine
      where touchscreen initialization fails maybe in every 1/5 - 1/2 boots.
      Since root cause for these errors is not clear yet and debugging is
      ongoing it's better to revert this commit as we are near to release.
      Reported-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      89119f08
  22. 24 11月, 2016 2 次提交
  23. 18 11月, 2016 1 次提交
  24. 25 10月, 2016 1 次提交
  25. 09 9月, 2016 1 次提交
  26. 26 8月, 2016 6 次提交
  27. 20 6月, 2016 1 次提交
  28. 13 2月, 2016 1 次提交
    • J
      i2c: designware: Prevent runtime suspend during adapter registration · cd998ded
      Jarkko Nikula 提交于
      There can be unnecessary runtime suspend-resume cycle during
      i2c-designware-platdrv probe when it registers the I2C adapter device. This
      happens because i2c-designware-platdrv is set to initially active platform
      device in its probe function and is a parent of I2C adapter.
      
      In that case power.usage_count of i2c-designware device is zero and
      pm_runtime_get()/pm_runtime_put() cycle during probe could put it into
      runtime suspend. This happens when the i2c_register_adapter() calls the
      device_register():
      
      i2c_register_adapter
        device_register
          device_add
            bus_probe_device
              device_initial_probe
                __device_attach
                  if (dev->parent) pm_runtime_get_sync(dev->parent)
                  ...
                  if (dev->parent) pm_runtime_put(dev->parent)
      
      After that the i2c_register_adapter() continues registering I2C slave
      devices. In case slave device probe does I2C transfers the parent will
      resume again and thus get a needless runtime suspend/resume cycle during
      adapter registration.
      
      Prevent this while retaining the runtime PM status of i2c-designware by
      only incrementing/decrementing device power usage count during I2C
      adapter registration. That makes sure there won't be spurious runtime PM
      status changes and lets the driver core to idle the device after probe
      finishes.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      cd998ded