1. 11 8月, 2015 1 次提交
  2. 22 6月, 2015 1 次提交
  3. 19 5月, 2015 1 次提交
  4. 30 3月, 2015 1 次提交
    • C
      mfd: arizona: Correct type of gpio_defaults · 6e00ff07
      Charles Keepax 提交于
      gpio_defaults needs to be specified as an unsigned int rather than an
      int, because the intention of the DT binding is that all out of range
      values for a 16-bit register will cause the defaults to be used,
      however, if gpio_defaults is an int then values that are larger than
      INT_MAX will become negative numbers and be written out directly to the
      hardware. As no where in the code replies on gpio_defaults being an int,
      the simplest fix is to just change it to unsigned.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      6e00ff07
  5. 04 3月, 2015 1 次提交
  6. 16 6月, 2014 1 次提交
  7. 22 5月, 2013 1 次提交
  8. 08 4月, 2013 3 次提交
  9. 02 4月, 2013 5 次提交
  10. 14 2月, 2013 1 次提交
  11. 08 2月, 2013 2 次提交
  12. 21 1月, 2013 1 次提交
  13. 15 1月, 2013 4 次提交
  14. 28 11月, 2012 1 次提交
    • M
      Input - arizona-haptics: Add driver haptics module on Arizona CODECs · 9dd555e2
      Mark Brown 提交于
      The Arizona CODECs contain a haptics module providing vibration feedback
      support. Implement basic support for this, providing simple start/stop and
      signal magnitude control.
      
      Since the output path for haptics is routed through the CODEC audio routing
      it is modelled as a signal generator within ASoC, the haptics driver calls
      DAPM to start and stop the output drivers. An appropriate output path must
      be configured via ALSA to connect the haptics source to the correct output.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      9dd555e2
  15. 16 7月, 2012 1 次提交
  16. 10 7月, 2012 1 次提交
  17. 23 6月, 2012 1 次提交
    • M
      mfd: arizona: Core driver · 3cc72986
      Mark Brown 提交于
      Several forthcoming Wolfson devices are based on a common platform
      known as Arizona allowing a great deal of reuse of driver code. This
      patch adds core support for these devices.
      
      In order to handle systems which do not use the generic clock API a
      simple wrapper for the 32kHz clock domain in the devices is provided.
      Once the generic clock API is widely available this code will be moved
      over to use that.
      
      For simplicity some WM5102 specific code is included in the core driver,
      the effort involved in splitting the device out isn't worth it.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      3cc72986