1. 31 7月, 2017 2 次提交
  2. 28 6月, 2017 1 次提交
  3. 20 6月, 2017 3 次提交
  4. 23 5月, 2017 1 次提交
  5. 22 5月, 2017 1 次提交
  6. 19 5月, 2017 1 次提交
  7. 27 4月, 2017 1 次提交
  8. 20 4月, 2017 1 次提交
  9. 22 3月, 2017 2 次提交
    • H
      i2c: designware: Disable pm for PMIC i2c-bus even if there is no _SEM method · a3d411fb
      Hans de Goede 提交于
      Cherrytrail devices use the dw i2c-bus with uid 7 to access their PMIC.
      Even if the i2c-bus to the PMIC is not shared with the SoC's P-Unit
      and i2c-designware-baytrail.c thus does not set the pm_disabled flag,
      we still need to disable pm so that ACPI PMIC opregions can access the
      PMIC during late-suspend and early-resume.
      
      This fixes errors like these blocking suspend:
      
        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
      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>
      a3d411fb
    • 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
  10. 09 3月, 2017 1 次提交
  11. 02 3月, 2017 3 次提交
  12. 18 12月, 2016 1 次提交
  13. 30 11月, 2016 1 次提交
  14. 18 11月, 2016 2 次提交
  15. 26 8月, 2016 6 次提交
  16. 11 3月, 2016 1 次提交
  17. 10 1月, 2016 1 次提交
  18. 07 1月, 2016 1 次提交
  19. 05 1月, 2016 1 次提交
  20. 13 12月, 2015 2 次提交
  21. 07 12月, 2015 1 次提交
  22. 25 10月, 2015 1 次提交
    • D
      i2c: add ACPI support for I2C mux ports · 8eb5c87a
      Dustin Byford 提交于
      Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
      device property compatible string match), enumerating I2C client devices
      connected through an I2C mux needs a little extra work.
      
      This change implements a method for describing an I2C device hierarchy that
      includes mux devices by using an ACPI Device() for each mux channel along
      with an _ADR to set the channel number for the device.  See
      Documentation/acpi/i2c-muxes.txt for a simple example.
      
      To make this work the ismt, i801, and designware pci/platform devs now
      share an ACPI companion with their I2C adapter dev similar to how it's done
      in OF.  This is done on the assumption that power management functions will
      not be called directly on the I2C dev that is sharing the ACPI node.
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NDustin Byford <dustin@cumulusnetworks.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      8eb5c87a
  23. 24 10月, 2015 1 次提交
  24. 22 10月, 2015 1 次提交
  25. 18 10月, 2015 1 次提交
    • M
      i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348 · 56d4b8a2
      Mika Westerberg 提交于
      ACPI SSCN/FMCN methods were originally added because then the platform can
      provide the most accurate HCNT/LCNT values to the driver. However, this
      seems not to be true for Dell Inspiron 7348 where using these causes the
      touchpad to fail in boot:
      
        i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
        i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
        i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
        i2c_designware INT3433:00: controller timed out
      
      The values received from ACPI are (in fast mode):
      
        HCNT: 72
        LCNT: 160
      
      this translates to following timings (input clock is 100MHz on Broadwell):
      
        tHIGH: 720 ns (spec min 600 ns)
        tLOW: 1600 ns (spec min 1300 ns)
        Bus period: 2920 ns (assuming 300 ns tf and tr)
        Bus speed: 342.5 kHz
      
      Both tHIGH and tLOW are within the I2C specification.
      
      The calculated values when ACPI parameters are not used are (in fast mode):
      
        HCNT: 87
        LCNT: 159
      
      which translates to:
      
        tHIGH: 870 ns (spec min 600 ns)
        tLOW: 1590 ns (spec min 1300 ns)
        Bus period 3060 ns (assuming 300 ns tf and tr)
        Bus speed 326.8 kHz
      
      These values are also within the I2C specification.
      
      Since both ACPI and calculated values meet the I2C specification timing
      requirements it is hard to say why the touchpad does not function properly
      with the ACPI values except that the bus speed is higher in this case (but
      still well below the max 400kHz).
      
      Solve this by adding DMI quirk to the driver that disables using ACPI
      parameters on this particulare machine.
      Reported-by: NPavel Roskin <plroskin@gmail.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NPavel Roskin <plroskin@gmail.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      56d4b8a2
  26. 15 10月, 2015 2 次提交