1. 11 3月, 2018 1 次提交
  2. 11 10月, 2017 2 次提交
  3. 10 10月, 2017 2 次提交
  4. 04 9月, 2017 1 次提交
  5. 23 8月, 2017 1 次提交
  6. 12 8月, 2017 1 次提交
  7. 25 6月, 2017 1 次提交
  8. 26 4月, 2017 1 次提交
  9. 02 4月, 2017 1 次提交
  10. 30 12月, 2016 2 次提交
  11. 12 11月, 2016 1 次提交
    • L
      iio: pressure: st_pressure: inline per-sensor data · 91a86a3b
      Linus Walleij 提交于
      We have #defines for all the individual sensor registers and
      value/mask pairs #defined at the top of the file and used at
      exactly one spot.
      
      This is usually good if the #defines give a meaning to the
      opaque magic numbers.
      
      However in this case, the semantic meaning is inherent in the
      name of the C99-addressable fields, and that means duplication
      of information, and only makes the code hard to maintain since
      you every time have to add a new #define AND update the site
      where it is to be used.
      
      Get rid of the #defines and just open code the values into the
      appropriate struct elements. Make sure to explicitly address
      the .hz and .value fields in the st_sensor_odr_avl struct
      so that the meaning of all values is clear.
      
      This patch is purely syntactic should have no semantic effect.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      91a86a3b
  12. 05 7月, 2016 6 次提交
  13. 30 5月, 2016 1 次提交
    • L
      iio: st_sensors: switch to a threaded interrupt · 65925b65
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Reported-by: NCrestez Dan Leonard <cdleonard@gmail.com>
      Tested-by: NCrestez Dan Leonard <cdleonard@gmail.com>
      Tested-by: NJonathan Cameron <jic23@kernel.org>
      Fixes: 97865fe4 ("iio: st_sensors: verify interrupt event to status")
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      65925b65
  14. 29 5月, 2016 3 次提交
  15. 20 4月, 2016 2 次提交
    • L
      iio: st_sensors: support open drain mode · 0e6f6871
      Linus Walleij 提交于
      Some types of ST Sensors can be connected to the same IRQ line
      as other peripherals using open drain. Add a device tree binding
      and a sensor data property to flip the right bit in the interrupt
      control register to enable open drain mode on the INT line.
      
      If the line is set to be open drain, also tag on IRQF_SHARED
      to the IRQ flags when requesting the interrupt, as the whole
      point of using open drain interrupt lines is to share them with
      more than one peripheral (wire-or).
      
      Cc: devicetree@vger.kernel.org
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Acked-by: NRob Herring <rob@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      0e6f6871
    • L
      iio: st_sensors: verify interrupt event to status · 97865fe4
      Linus Walleij 提交于
      This makes all ST sensor drivers check that they actually have
      new data available for the requested channel(s) before claiming
      an IRQ, by reading the status register (which is conveniently
      the same for all ST sensors) and check that the channel has new
      data before proceeding to read it and fill the buffer.
      
      This way sensors can share an interrupt line: it can be flaged
      as shared and then the sensor that did not fire will return
      NO_IRQ, and the sensor that fired will handle the IRQ and
      return IRQ_HANDLED.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      97865fe4
  16. 10 1月, 2016 1 次提交
    • L
      iio: st_sensors: support active-low interrupts · a9fd053b
      Linus Walleij 提交于
      Most ST MEMS Sensors that support interrupts can also handle sending
      an active low interrupt, i.e. going from high to low on data ready
      (or other interrupt) and thus triggering on a falling edge to the
      interrupt controller.
      
      Set up logic to inspect the interrupt line we get for a sensor: if
      it is triggering on rising edge, leave everything alone, but if it
      triggers on falling edges, set up active low, and if unsupported
      configurations appear: warn with errors and reconfigure the interrupt
      to a rising edge, which all interrupt generating sensors support.
      
      Create a local header for st_sensors_core.h to share functions
      between the sensor core and the trigger setup code.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      a9fd053b
  17. 16 8月, 2015 1 次提交
  18. 24 7月, 2015 1 次提交
  19. 27 4月, 2015 1 次提交
  20. 04 10月, 2014 3 次提交
  21. 07 7月, 2014 1 次提交
  22. 26 4月, 2014 2 次提交
    • L
      iio: st_sensors: move regulator retrieveal to core · ea7e586b
      Linus Walleij 提交于
      Currently the pressure sensor has code to retrieve and enable two
      regulators for Vdd and Vdd IO, but actually these voltage inputs
      are found on all of these ST sensors, so move the regulator
      handling to the core and make sure all the ST sensors call these
      functions on probe() and remove() to enable/disable power.
      
      Here also mover over to obtaining the regulator from the *parent*
      device of the IIO device, as the IIO device is created on-the-fly
      in this very subsystem it very unlikely evert have any regulators
      attached to it whatsoever. It is much more likely that the parent
      is a platform device, possibly instantiated from a device tree,
      which in turn have Vdd and Vdd IO supplied assigned to it.
      
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Denis CIOCCA <denis.ciocca@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      ea7e586b
    • L
      iio: st_sensors: announce registered sensors · 4f544ced
      Linus Walleij 提交于
      It is pretty helpful to know already from dmesg that a certain
      device is successfully registered, instead of having to browse
      sysfs to see if it's actually there.
      
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Denis CIOCCA <denis.ciocca@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      4f544ced
  23. 22 2月, 2014 1 次提交
  24. 24 9月, 2013 2 次提交
  25. 22 9月, 2013 1 次提交