1. 31 5月, 2020 2 次提交
    • S
      i2c: designware: Add Baikal-T1 System I2C support · fcb82a93
      Serge Semin 提交于
      Baikal-T1 System Controller is equipped with a dedicated I2C Controller
      which functionality is based on the DW APB I2C IP-core, the only
      difference in a way it' registers are accessed. There are three access
      register provided in the System Controller registers map, which indirectly
      address the normal DW APB I2C registers space. So in order to have the
      Baikal-T1 System I2C Controller supported by the common DW APB I2C driver
      we created a dedicated Dw I2C controller model quirk, which retrieves the
      syscon regmap from the parental dt node and creates a new regmap based on
      it.
      Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@kernel.org>
      fcb82a93
    • S
      i2c: designware: Convert driver to using regmap API · 0daede80
      Serge Semin 提交于
      Seeing the DW I2C driver is using flags-based accessors with two
      conditional clauses it would be better to replace them with the regmap
      API IO methods and to initialize the regmap object with read/write
      callbacks specific to the controller registers map implementation. This
      will be also handy for the drivers with non-standard registers mapping
      (like an embedded into the Baikal-T1 System Controller DW I2C block, which
      glue-driver is a part of this series).
      
      As before the driver tries to detect the mapping setup at probe stage and
      creates a regmap object accordingly, which will be used by the rest of the
      code to correctly access the controller registers. In two places it was
      appropriate to convert the hand-written read-modify-write and
      read-poll-loop design patterns to the corresponding regmap API
      ready-to-use methods.
      
      Note the regmap IO methods return value is checked only at the probe
      stage. The rest of the code won't do this because basically we have
      MMIO-based regmap so non of the read/write methods can fail (this also
      won't be needed for the Baikal-T1-specific I2C controller).
      Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      [wsa: fix type of 'rx_valid' and remove outdated kdoc var description]
      Signed-off-by: NWolfram Sang <wsa@kernel.org>
      0daede80
  2. 30 5月, 2020 1 次提交
  3. 22 5月, 2020 4 次提交
  4. 13 5月, 2020 2 次提交
  5. 22 3月, 2020 2 次提交
  6. 21 3月, 2019 1 次提交
  7. 23 2月, 2019 1 次提交
    • H
      i2c: designware: Do not allow i2c_dw_xfer() calls while suspended · 27515415
      Hans de Goede 提交于
      On most Intel Bay- and Cherry-Trail systems the PMIC is connected over I2C
      and the PMIC is accessed through various means by the _PS0 and _PS3 ACPI
      methods (power on / off methods) of various devices.
      
      This leads to suspend/resume ordering problems where a device may be
      resumed and get its _PS0 method executed before the I2C controller is
      resumed. On Cherry Trail this leads to errors like these:
      
           i2c_designware 808622C1:06: controller timed out
           ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
           ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR
           video LNXVIDEO:00: Failed to change power state to D0
      
      But on Bay Trail this caused I2C reads to seem to succeed, but they end
      up returning wrong data, which ends up getting written back by the typical
      read-modify-write cycle done to turn on various power-resources.
      
      Debugging the problems caused by this silent data corruption is quite
      nasty. This commit adds a check which disallows i2c_dw_xfer() calls to
      happen until the controller's resume method has completed.
      
      Which turns the silent data corruption into getting these errors in
      dmesg instead:
      
          i2c_designware 80860F41:04: Error i2c_dw_xfer call while suspended
          ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
          ACPI Error: Method parse/execution failed \_SB.PCI0.GFX0._PS0, AE_ERROR
      
      Which is much better.
      
      Note the above errors are an example of issues which this patch will
      help to debug, the actual fix requires fixing the suspend order and
      this has been fixed by a different commit.
      
      Note the setting / clearing of the suspended flag in the suspend / resume
      methods is NOT protected by i2c_lock_bus(). This is intentional as these
      methods get called from i2c_dw_xfer() (through pm_runtime_get/put) a nd
      i2c_dw_xfer() is called with the i2c_bus_lock held, so otherwise we would
      deadlock. This means that there is a theoretical race between a non runtime
      suspend and the suspended check in i2c_dw_xfer(), this is not a problem
      since normally we should not hit the race and this check is primarily a
      debugging tool so hitting the check if there are suspend/resume ordering
      problems does not need to be 100% reliable.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      27515415
  8. 25 10月, 2018 1 次提交
  9. 12 10月, 2018 1 次提交
  10. 07 9月, 2018 1 次提交
  11. 03 9月, 2018 2 次提交
  12. 20 8月, 2018 1 次提交
  13. 09 8月, 2018 1 次提交
  14. 04 7月, 2018 2 次提交
  15. 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
  16. 10 1月, 2018 1 次提交
    • R
      PM: i2c-designware-platdrv: Optimize power management · 02e45646
      Rafael J. Wysocki 提交于
      Optimize the power management in i2c-designware-platdrv by making it
      set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which
      allows some code to be dropped from its PM callbacks.
      
      First, setting DPM_FLAG_SMART_SUSPEND causes the intel-lpss driver
      to avoid resuming i2c-designware-platdrv devices in its ->prepare
      callback, so they can stay in runtime suspend after that point even
      if the direct-complete feature is not used for them.
      
      It also causes the ACPI PM domain and the PM core to avoid invoking
      "late" and "noirq" suspend callbacks for these devices if they are
      in runtime suspend at the beginning of the "late" phase of device
      suspend during system suspend.  That guarantees dw_i2c_plat_suspend()
      to be called for a device only if it is not in runtime suspend.
      
      Moreover, it causes the device's runtime PM status to be set to
      "active" after calling dw_i2c_plat_resume() for it, so the
      driver doesn't need internal flags to avoid invoking either
      dw_i2c_plat_suspend() or dw_i2c_plat_resume() twice in a row.
      
      Second, setting DPM_FLAG_LEAVE_SUSPENDED enables the optimization
      allowing the device to stay suspended after system resume under
      suitable conditions, so again the driver doesn't need to take
      care of that by itself.
      
      Accordingly, the internal "suspended" and "skip_resume" flags
      used by the driver are not necessary any more, so drop them and
      simplify the driver's PM callbacks.
      
      Additionally, notice that dw_i2c_plat_complete() only needs to
      schedule runtime PM resume for the device if platform firmware
      has been involved in resuming the system, so make it call
      pm_resume_via_firmware() to check that.  Also make it check the
      runtime PM status of the device instead of its direct_complete
      flag which also works if the device remained suspended due to
      the DPM_FLAG_LEAVE_SUSPENDED driver flag.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: NWolfram Sang <wsa@the-dreams.de>
      Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      02e45646
  17. 28 11月, 2017 3 次提交
  18. 05 10月, 2017 1 次提交
    • R
      PM: i2c-designware-platdrv: Suspend/resume at the late/early stages · 54152772
      Rafael J. Wysocki 提交于
      As reported by Rajat Jain, there are problems when ACPI operation
      region handlers or similar, called at the ->resume_early() time, for
      I2C client devices try to access an I2C controller that has already
      been suspended at that point.  To avoid that, move the suspend/resume
      of i2c-designware-platdrv to the late/early stages, respectively.
      
      While at it, avoid resuming the device from runtime suspend in the
      driver's ->suspend callback which isn't particularly nice.  [A better
      approach would be to make the driver track the PM state of the device
      so that it doesn't need to resume it in ->suspend, so implement it.]
      
      First, drop dw_i2c_plat_suspend() added by commit a23318fe (i2c:
      designware: Fix system suspend) and rename dw_i2c_plat_runtime_suspend()
      back to dw_i2c_plat_suspend().
      
      Second, point the driver's ->late_suspend and ->early_resume
      callbacks, rather than its ->suspend and ->resume callbacks,
      to dw_i2c_plat_suspend() and dw_i2c_plat_resume(), respectively,
      so that they are not executed in parallel with each other, for
      example if runtime resume of the device takes place during system
      suspend.
      
      Finally, add "suspended" and "skip_resume" flags to struct dw_i2c_dev
      and make dw_i2c_plat_suspend() and dw_i2c_plat_resume() use them to
      avoid suspending or resuming the device twice in a row and to avoid
      resuming a previously runtime-suspended device during system resume.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NJohannes Stezenbach <js@sig21.net>
      Tested-by: NRajat Jain <rajatja@google.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      54152772
  19. 04 7月, 2017 2 次提交
  20. 28 6月, 2017 2 次提交
  21. 20 6月, 2017 3 次提交
  22. 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
  23. 09 3月, 2017 1 次提交
  24. 02 3月, 2017 3 次提交