An error occurred fetching the project authors.
  1. 14 Feb, 2020 2 commits
  2. 18 Jan, 2020 1 commit
  3. 08 Dec, 2019 1 commit
  4. 10 Nov, 2019 1 commit
  5. 22 Oct, 2019 1 commit
  6. 05 Oct, 2019 5 commits
  7. 05 Jun, 2019 1 commit
  8. 14 Apr, 2019 1 commit
    • Steve Moskovchenko's avatar
      iio: imu: mpu6050: Fix FIFO layout for ICM20602 · 1615fe41
      Steve Moskovchenko authored
      The MPU6050 driver has recently gained support for the
      ICM20602 IMU, which is very similar to MPU6xxx. However,
      the ICM20602's FIFO data specifically includes temperature
      readings, which were not present on MPU6xxx parts. As a
      result, the driver will under-read the ICM20602's FIFO
      register, causing the same (partial) sample to be returned
      for all reads, until the FIFO overflows.
      
      Fix this by adding a table of scan elements specifically
      for the ICM20602, which takes the extra temperature data
      into consideration.
      
      While we're at it, fix the temperature offset and scaling
      on ICM20602, since it uses different scale/offset constants
      than the rest of the MPU6xxx devices.
      Signed-off-by: default avatarSteve Moskovchenko <stevemo@skydio.com>
      Fixes: 22904bdf ("iio: imu: mpu6050: Add support for the ICM 20602 IMU")
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      1615fe41
  9. 02 Feb, 2019 1 commit
  10. 18 Aug, 2018 1 commit
  11. 15 Jul, 2018 1 commit
  12. 10 Jun, 2018 4 commits
  13. 06 May, 2018 2 commits
  14. 28 Apr, 2018 1 commit
  15. 21 Apr, 2018 1 commit
    • Martin Kelly's avatar
      iio:imu: inv_mpu6050: support more interrupt types · 5ec6486d
      Martin Kelly authored
      Currently, we support only rising edge interrupts, and in fact we assume
      that the interrupt we're given is rising edge (and things won't work if
      it's not). However, the device supports rising edge, falling edge, level
      low, and level high interrupts.
      
      Empirically, on my system, switching to level interrupts has fixed a
      problem I had with significant (~40%) interrupt loss with edge
      interrupts. This issue is likely related to the SoC I'm using (Allwinner
      H3), but being able to switch the interrupt type is still a very useful
      workaround.
      
      I tested this with each interrupt type and verified correct behavior in
      a logic analyzer.
      
      Add support for these interrupt types while also eliminating the error
      case of the device tree and driver using different interrupt types.
      Signed-off-by: default avatarMartin Kelly <mkelly@xevo.com>
      Acked-by: default avatarJean-Baptiste Maneyrol <jmaneyrol@invensense.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      5ec6486d
  16. 15 Apr, 2018 1 commit
  17. 30 Mar, 2018 1 commit
  18. 11 Jun, 2017 1 commit
  19. 03 Jun, 2017 1 commit
  20. 02 Apr, 2017 1 commit
    • Jonathan Cameron's avatar
      iio:imu:mpu6050 add explicit mpu9250 support · 0c8f492d
      Jonathan Cameron authored
      The mpu9250 is a SIP containing an mpu6500 and an ak8975.  If this was all
      there was too it there would be no need for explicit handling in the driver.
      Arguably the bindings would also only reflect the presence of an mpu6500 with
      the ak8975 hanging off it, as the kernel doesn't care that they are in one
      package.
      
      However, the WHOAMI value changes as well so best to add explicit support.
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      0c8f492d
  21. 03 Jul, 2016 1 commit
  22. 25 Apr, 2016 3 commits
  23. 23 Apr, 2016 1 commit
  24. 22 Apr, 2016 1 commit
  25. 25 Feb, 2016 4 commits
  26. 13 Feb, 2016 1 commit