1. 04 Jul, 2016 2 commits
    • Jonathan Cameron's avatar
      staging:iio:lis3l02dq drop separate driver · fc6bd727
      Jonathan Cameron authored
      Retire this venerable driver as the basic support is now in the
      generic st-sensors accelerometer driver.
      
      There are a few missing features in the new driver:
      * Threshold events.
      * Access to the calibration adjustment registers (patch shortly)
      
      In exchange it brings a cleaner and more maintainable code base that actually
      gets tested more than once every few years.  I'll actually be suprised
      if anyone other than me has a board with one of these on that is running
      an up to date kernel.
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      fc6bd727
    • Jonathan Cameron's avatar
      iio: accel: st_accel: Add lis3l02dq support · 4e68cfbf
      Jonathan Cameron authored
      Time to finally kill off the venerable (it was one of my first drivers)
      lis3l02dq driver in favour of adding support in the st sensors framework.
      
      This does loose us the event support that driver always had, but I think
      that will reappear at some point and in the meantime the maintenance
      advantages of dropping the 'special' driver for this one part outweigh
      the issues.
      
      It's worth noting this part is ancient and I may well be the only person
      who still has any on hardware running recent kernels.
      
      It has a few 'quirks'.
       - No WAI register so that just became optional.
       - A BDU option that really does block updates.  Completely.
         Whatever you do, you don't get any more data with it set.
         It is documented the same as more modern parts but I presume they
         are actually clearing for updates after a read of both bytes!
       - Fixed scale.
       - It's too quick.  Even at slowest rate (280Hz) I can't read out fast
         enough on my board (stargate 2) to beat new data coming in. Linus'
         repeat read patch doesn't help in this case. It just means I get 10
         readings before dying... So in reality this will get used with
         software triggers only unless someone has this long out of production
         device on a quick board.
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: Denis CIOCCA <denis.ciocca@st.com>
      Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      4e68cfbf
  2. 03 Jul, 2016 20 commits
  3. 02 Jul, 2016 1 commit
    • Linus Walleij's avatar
      iio: st_sensors: harden interrupt handling · 90efe055
      Linus Walleij authored
      Leonard Crestez observed the following phenomenon: when using
      hard interrupt triggers (the DRDY line coming out of an ST
      sensor) sometimes a new value would arrive while reading the
      previous value, due to latencies in the system.
      
      We discovered that the ST hardware as far as can be observed
      is designed for level interrupts: the DRDY line will be held
      asserted as long as there are new values coming. The interrupt
      handler should be re-entered until we're out of values to
      handle from the sensor.
      
      If interrupts were handled as occurring on the edges (usually
      low-to-high) new values could appear and the line be held
      asserted after that, and these values would be missed, the
      interrupt handler would also lock up as new data was
      available, but as no new edges occurs on the DRDY signal,
      nothing happens: the edge detector only detects edges.
      
      To counter this, do the following:
      
      - Accept interrupt lines to be flagged as level interrupts
        using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line
        is marked like this (in the device tree node or ACPI
        table or similar) it will be utilized as a level IRQ.
        We mark the line with IRQF_ONESHOT and mask the IRQ
        while processing a sample, then the top half will be
        entered again if new values are available.
      
      - If we are flagged as using edge interrupts with
        IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove
        IRQF_ONESHOT so that the interrupt line is not
        masked while running the thread part of the interrupt.
        This way we will never miss an interrupt, then introduce
        a loop that polls the data ready registers repeatedly
        until no new samples are available, then exit the
        interrupt handler. This way we know no new values are
        available when the interrupt handler exits and
        new (edge) interrupts will be triggered when data arrives.
        Take some extra care to update the timestamp in the poll
        loop if this happens. The timestamp will not be 100%
        perfect, but it will at least be closer to the actual
        events. Usually the extra poll loop will handle the new
        samples, but once in a blue moon, we get a new IRQ
        while exiting the loop, before returning from the
        thread IRQ bottom half with IRQ_HANDLED. On these rare
        occasions, the removal of IRQF_ONESHOT means the
        interrupt will immediately fire again.
      
      - If no interrupt type is indicated from the DT/ACPI,
        choose IRQF_TRIGGER_RISING as default, as this is necessary
        for legacy boards.
      
      Tested successfully on the LIS331DL and L3G4200D by setting
      sampling frequency to 400Hz/800Hz and stressing the system:
      extra reads in the threaded interrupt handler occurs.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Tested-by: default avatarCrestez Dan Leonard <cdleonard@gmail.com>
      Reported-by: default avatarCrestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      90efe055
  4. 30 Jun, 2016 11 commits
  5. 29 Jun, 2016 1 commit
    • Greg Kroah-Hartman's avatar
      Merge tag 'iio-for-4.8b' of... · 3c9a6793
      Greg Kroah-Hartman authored
      Merge tag 'iio-for-4.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
      
      Jonathan writes:
      
      Second round of new iio device support, features and cleanups in the 4.8 cycle
      
      Firstly some contact detail updates:
      * NXP took over freescale. Update the mma8452 header to reflect this.
      * Martin Kepplinger email address change in mma8452 header.
      * Adriana Reus has changed email address. Update .mailmap.
      * Matt Ranostay has changed email address. Update .mailmap.
      
      New Device Support
      * max1363
        - add the missing i2c_device_ids for a couple of parts so they can actually
          be used.
      * ms5867
        - add device ids for ms5805 and ms5837 parts.
      
      New Features
      * ad5755
        - DT support.  This one was a bit controversial and under review for a long
          time.  Still no one could come up with a better solution.
      * stx104
        - add gpio support
      * ti-adc081c
        - Add ACPI device ID matching.
      
      Core changes
      * Refuse to register triggers with duplicate names.  There is no way to
        distinguish between them so this makes no sense.  A few drivers do not
        generate unique names for each instance of the device present.  We can't
        fix this without changing ABI so leave them and wait for someone to
        actually take the rare step of two identical accelerometers on the same
        board.
      * buffer-dma
        - use ARRAY_SIZE in a few appropriate locations.
      
      Tools
      * Fix the fact that the --trigger-num option in generic_buffer didn't allow
        0 which is perfectly valid in the ABI.
      
      Cleanups
      * as3935
        - improve error reporting.
        - remove redundant zeroing of a field in iio_priv.
      * gp2ap020a00f
        - use the iio_device_claim_*_mode helpers rather than open coding locking
        around mode changes.
      * isl29125
        - use the iio_device_claim_*_mode helpers rather than open coding locking.
      * lidar
        - use the iio_device_claim_*_mode helpers rather than open coding locking.
      * mma8452
        - more detail in devices supported description in comments (addresses and
        similar)
      * sca3000
        - add a missing error check.
      * tcs3414
        - use the iio_device_claim_*_mode helpers rather than open coding locking.
      * tcs3472
        - use the iio_device_claim_*_mode helpers rather than open coding locking.
      3c9a6793
  6. 27 Jun, 2016 5 commits