1. 29 May, 2016 7 commits
    • Crestez Dan Leonard's avatar
      iio: st_sensors: Disable DRDY at init time · 99147606
      Crestez Dan Leonard authored
      This fixes odd behavior after reboot.
      
      The fact that we set the device to powerdown mode is not sufficient to
      prevent DRDY being active because we might still have an unread sample.
      
      Even if powerdown was sufficient keeping DRDY disabled while trigger is
      not active is a good idea.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Signed-off-by: default avatarCrestez Dan Leonard <leonard.crestez@intel.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      99147606
    • Crestez Dan Leonard's avatar
      iio: st_sensors: Init trigger before irq request · ff05916f
      Crestez Dan Leonard authored
      This fixes a possible race where an interrupt arrives before complete
      initialization and crashes because iio_trigger_get_drvdata returns NULL.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Signed-off-by: default avatarCrestez Dan Leonard <leonard.crestez@intel.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      ff05916f
    • Linus Walleij's avatar
      iio: st_sensors: switch to a threaded interrupt · 65925b65
      Linus Walleij authored
      commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
      ("iio: st_sensors: verify interrupt event to status") caused
      a regression when reading ST sensors from a HRTimer trigger
      rather than the intrinsic interrupts: the HRTimer may
      trigger faster than the sensor provides new values, and
      as the check against new values available as a cause of
      the interrupt trigger was done in the poll function,
      this would bail out of the HRTimer interrupt with
      IRQ_NONE.
      
      So clearly we need to only check the new values available
      from the proper interrupt handler and not from the poll
      function, which should rather just read the raw values
      from the registers, put them into the buffer and be happy.
      
      To achieve this: switch the ST Sensors over to using a true
      threaded interrupt handler.
      
      In the interrupt thread, check if new values are available,
      else yield to the (potential) next device on the same
      interrupt line to check the registers. If the interrupt
      was ours, proceed to poll the values.
      
      Instead of relying on iio_trigger_generic_data_rdy_poll() as
      a top half to wake up the thread that polls the sensor for
      new data, have the thread call iio_trigger_poll_chained()
      after determining that is is the proper source of the
      interrupt. This is modelled on drivers/iio/accel/mma8452.c
      which is already using a properly threaded interrupt handler.
      
      In order to get the same precision in timestamps as
      previously, where samples would be timestamped in the
      poll function pf->timestamp when calling
      iio_trigger_generic_data_rdy_poll() we introduce a
      local timestamp in the sensor data, set it in the top half
      (fastpath) of the interrupt handler and provide that to the
      core when calling iio_push_to_buffers_with_timestamp().
      
      Additionally: if the active scanmask is not set for the
      sensor no IRQs should be enabled and we need to bail out
      with IRQ_NONE. This can happen if spurious IRQs fire when
      installing the threaded interrupt handler.
      
      Tested with hard interrupt triggers on LIS331DL, then also
      tested with hrtimers on the same sensor by creating a 75Hz
      HRTimer and using it to poll the sensor.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Reported-by: default avatarCrestez Dan Leonard <cdleonard@gmail.com>
      Tested-by: default avatarCrestez Dan Leonard <cdleonard@gmail.com>
      Tested-by: default avatarJonathan Cameron <jic23@kernel.org>
      Fixes: 97865fe4 ("iio: st_sensors: verify interrupt event to status")
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      65925b65
    • Linus Walleij's avatar
      iio: light: bh1780: assign a static name · 0dd09ca4
      Linus Walleij authored
      Using the struct i2c_device->id field for naming the light sensor
      is a bad idea: when booting from the pure device tree this is NULL
      and that causes the device not to have the "name" property in
      sysfs and that in turn confuses the "lsiio" command to stop listing
      devices.
      
      So instead of using the device .id, use the hard string "bh1780",
      which works just fine.
      
      Fixes: 1f0477f1 ("iio: light: new driver for the ROHM BH1780")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      0dd09ca4
    • Linus Walleij's avatar
      iio: bh1780: dereference the client properly · 13c27e94
      Linus Walleij authored
      The code in runtime_[suspend|resume] was assuming that the
      i2c client data was the bh1780 state container, but it contains
      the IIO device. So first dereference the IIO device from the
      i2c client, then get the state container using the iio_priv()
      call.
      
      Fixes: 1f0477f1 ("iio: light: new driver for the ROHM BH1780")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      13c27e94
    • Matt Ranostay's avatar
      iio: humidity: hdc100x: fix IIO_TEMP channel reporting · 09bc0dda
      Matt Ranostay authored
      IIO_TEMP channel was being incorrectly reported back as Celsius when it
      should have been milliCelsius. This is via an incorrect scale value being
      returned to userspace.
      Signed-off-by: default avatarMatt Ranostay <mranostay@gmail.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      09bc0dda
    • Gregor Boirie's avatar
      iio:st_pressure: fix sampling gains (bring inline with ABI) · d43a4115
      Gregor Boirie authored
      Temperature channels report scaled samples in Celsius although expected as
      milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio.
      Gains are not implemented at all for LPS001WP pressure and temperature
      channels.
      
      This patch ensures that proper offsets and scales are exposed to userpace
      for both pressure and temperature channels.
      Also fix a NULL pointer exception when userspace reads content of sysfs
      scale attribute when gains are not defined.
      Signed-off-by: default avatarGregor Boirie <gregor.boirie@parrot.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      d43a4115
  2. 22 May, 2016 3 commits
  3. 21 May, 2016 3 commits
  4. 14 May, 2016 1 commit
  5. 04 May, 2016 4 commits
  6. 03 May, 2016 22 commits