1. 28 8月, 2015 1 次提交
  2. 27 8月, 2015 1 次提交
  3. 25 8月, 2015 3 次提交
  4. 24 8月, 2015 1 次提交
  5. 21 8月, 2015 1 次提交
  6. 17 8月, 2015 1 次提交
  7. 15 8月, 2015 1 次提交
  8. 13 8月, 2015 1 次提交
  9. 11 8月, 2015 1 次提交
    • M
      mfd: watchdog: iTCO_wdt: Expose watchdog properties using platform data · 420b54de
      Matt Fleming 提交于
      Intel Sunrisepoint (Skylake PCH) has the iTCO watchdog accessible across
      the SMBus, unlike previous generations of PCH/ICH where it was on the
      LPC bus. Because it's on the SMBus, it doesn't make sense to pass around
      a 'struct lpc_ich_info', and leaking the type of bus into the iTCO
      watchdog driver is kind of backwards anyway.
      
      This change introduces a new 'struct itco_wdt_platform_data' for use
      inside the iTCO watchdog driver and by the upcoming Intel Sunrisepoint
      code, which neatly avoids having to include lpc_ich headers in the i801
      i2c driver.
      
      This change is overdue because lpc_ich_info has already found its way
      into other TCO watchdog users, notably the intel_pmc_ipc driver where
      the watchdog actually isn't on the LPC bus as far as I can see.
      
      A simple translation layer is provided for converting from the existing
      'struct lpc_ich_info' inside the lpc_ich mfd driver.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Acked-by: Darren Hart <dvhart@linux.intel.com> [drivers/x86 refactoring]
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      420b54de
  10. 07 8月, 2015 1 次提交
  11. 05 8月, 2015 1 次提交
    • N
      Input: atmel_mxt_ts - use deep sleep mode when stopped · 7f3884f7
      Nick Dyer 提交于
      The hardcoded 0x83 CTRL setting overrides other settings in that byte,
      enabling extra reporting that may not be useful on a particular platform.
      
      Implement improved suspend mechanism via deep sleep. By writing zero to
      both the active and idle cycle times the maXTouch device can be put into a
      deep sleep mode, using minimal power. It is necessary to issue a calibrate
      command after the chip has spent any time in deep sleep, however a soft
      reset is unnecessary.
      
      Use the old method on Chromebook Pixel via platform data option.
      
      This patch also deals with the situation where the power configuration is
      zero on probe, which would mean that the device never wakes up to execute
      commands.
      
      After a config download, the T7 power configuration may have changed so it
      is necessary to re-read it.
      Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
      Acked-by: NBenson Leung <bleung@chromium.org>
      Acked-by: NYufeng Shen <miletus@chromium.org>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      7f3884f7
  12. 27 7月, 2015 1 次提交
  13. 25 7月, 2015 1 次提交
  14. 24 7月, 2015 1 次提交
  15. 16 7月, 2015 1 次提交
  16. 12 7月, 2015 2 次提交
  17. 09 7月, 2015 1 次提交
  18. 22 6月, 2015 1 次提交
  19. 18 6月, 2015 1 次提交
  20. 17 6月, 2015 1 次提交
    • D
      remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 · a01bc0d5
      Dave Gerlach 提交于
      Add a remoteproc driver to load the firmware and boot a small
      Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
      Wakeup M3 remote processor is an integrated Cortex M3 that allows
      the SoC to enter the lowest possible power state by taking control
      from the MPU after it has gone into its own low power state and
      shutting off any additional peripherals.
      
      The Wakeup M3 processor has two internal memory regions - 16 kB of
      unified instruction memory called UMEM used to store executable
      code, and 8 kB of data memory called DMEM used for all data sections.
      The Wakeup M3 processor executes its code entirely from within the
      UMEM and uses the DMEM for any data. It does not use any external
      memory or any other external resources. The device address view has
      the UMEM at address 0x0 and DMEM at address 0x80000, and these are
      computed automatically within the driver based on relative address
      calculation from the corresponding device tree IOMEM resources.
      These device addresses are used to aid the core remoteproc ELF
      loader code to properly translate and load the firmware segments
      through the .rproc_da_to_va ops.
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      a01bc0d5
  21. 12 6月, 2015 2 次提交
  22. 10 6月, 2015 1 次提交
  23. 01 6月, 2015 1 次提交
  24. 23 5月, 2015 1 次提交
  25. 10 5月, 2015 1 次提交
  26. 09 5月, 2015 1 次提交
  27. 08 5月, 2015 1 次提交
  28. 06 5月, 2015 1 次提交
  29. 05 5月, 2015 1 次提交
  30. 29 4月, 2015 1 次提交
  31. 10 4月, 2015 1 次提交
  32. 28 3月, 2015 1 次提交
  33. 27 3月, 2015 2 次提交
  34. 26 3月, 2015 1 次提交
  35. 19 3月, 2015 1 次提交
新手
引导
客服 返回
顶部