Commit Graph

21 Commits

Author SHA1 Message Date
Vlad Dogaru c16bff4844 iio: accel: bmc150: decouple buffer and triggers
If the interrupt pins are not available, we should still be able to use
the buffer with an external trigger.  However, we won't be able to use
the hardware fifo since we have no means of signalling when the
watermark is reached.

I also added a comment to indicate that the timestamps in
bmc150_accel_data are only used for hardware fifo, since initially I was
confused about duplication with pf->timestamp.

Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Reviewed-by: Octavian Purdila <octavian.purdila@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-05-17 10:57:27 +01:00
Greg Kroah-Hartman c610f7f772 Merge 4.0-rc7 into staging-next
We want those fixes (iio primarily) into the -next branch to help with
merge and testing issues.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-07 11:03:02 +02:00
Octavian Purdila 3bbec97733 iio: bmc150_accel: add support for hardware fifo
We only advertise hardware fifo support if the I2C bus supports full
I2C or smbus I2C block data reads since it is mandatory to read the
full frame in one read (otherwise the rest of the frame is discarded).

The hardware fifo is enabled only when triggers are not active because:

(a) when using the any-motion trigger the user expects to see samples
based on ROC events, but the fifo stores samples based on the sample
frequency

(b) the data-ready trigger is waking the CPU for for every sample, so
using the hardware fifo does not have any benefit

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-29 16:17:11 +01:00
Octavian Purdila 7d963215f6 iio: bmc150: introduce bmc150_accel_trigger
Add a separate structure for triggers and add the infrastructure to
support an arbitrary number of triggers. Each trigger is associated
with an interrupt and has an enabled/disabled state.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-14 18:56:16 +00:00
Octavian Purdila 3e825ec98d iio: bmc150: introduce bmc150_accel_interrupt
Since both triggers and events can share an interrupt, add a data
structure that tracks the users of an interrupt so that it enables or
disables it only for the first users and respectively last user.

This will allows us to easily add more events or triggers.

The patch also adds an interrupt enabled counter, so that we can
easily know if we need to put the device in normal mode when the
resume callback is issued.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-14 18:56:04 +00:00
Sathyanarayanan Kuppuswamy 0ba8da961b iio: bmc150: change sampling frequency
Currently driver reports device bandwidth list as available
sampling frequency. But sampling frequency is actually twice
the device bandwidth. This patch fixes this issue.

Signed-off-by: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@intel.com>
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-14 18:35:59 +00:00
Octavian Purdila 70dddeee89 iio: fix drivers that check buffer->scan_mask
If the in-kernel push interface is used we may have a different masks
on the device buffer and the kernel buffer and in this case the device
should generate data for the reunion of the buffers, which is
available at indio_dev->active_scan_mask.

Compiled tested only except for bmc150-accel which was tested at
runtime with the hardware.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-07 19:17:07 +00:00
Uwe Kleine-König b457f53a2a iio: improve usage of gpiod API
Since 39b2bbe3d7 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for
outputs.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-02-22 09:49:22 +00:00
Octavian Purdila 14ee64f438 iio: bmc150: exit early if event / trigger state is not changed
Previous of this patch the check was only done if we enabled the event
and it was already enabled. We can do the same if the event is
disabled and we want to disable it.

The patch also adds the same check on the trigger code.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-02-08 10:40:25 +00:00
Octavian Purdila 8e22f477e1 iio: bmc150: refactor interrupt enabling
This patch combines the any motion and new data interrupts function
into a single, generic, interrupt enable function. On top of this, we
can later refactor triggers to make it easier to add new triggers.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-02-08 10:38:10 +00:00
Octavian Purdila 802a3aef30 iio: bmc150: refactor slope duration and threshold update
Move the slope duration and threshold update in a separate function to
reduce code duplicate between chip init and motion interrupt setup.

Also move the slope update code from the interrupt setup function to
the trigger set state function so that we can later refactor the
interrupt code.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-02-08 10:36:41 +00:00
Rafael J. Wysocki e3d857e1ae Merge branch 'pm-runtime'
* pm-runtime: (25 commits)
  i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c
  dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
  MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  hwrandom / exynos / PM: Use CONFIG_PM in #ifdef
  block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
  USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
  PM: Merge the SET*_RUNTIME_PM_OPS() macros
  PM / Kconfig: Do not select PM directly from Kconfig files
  PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core
  ...
2014-12-08 20:00:44 +01:00
Rafael J. Wysocki 6f0a13f25e iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/iio/.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2014-12-04 01:08:13 +01:00
Srinivas Pandruvada 9e8e228f2b iio: accel: bmc150: set low default thresholds
Set the threshold to low by default. With this thresholds any movement
on the device with this sensor will generate event.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-11-16 20:25:00 +00:00
Srinivas Pandruvada 1174124c45 iio: accel: bmc150: Fix iio_event_spec direction
Change event spec direction from
IIO_EV_DIR_RISING | IIO_EV_DIR_FALLING
to
IIO_EV_DIR_EITHER

Suggested-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-11-16 20:23:48 +00:00
Srinivas Pandruvada 8d5a978192 iio: accel: bmc150: Send x, y and z motion separately
This chip is capable to identify motion across x, y and z axes. So
send different events.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-11-16 20:22:39 +00:00
Srinivas Pandruvada aaeecd8044 iio: accel: bmc150: Error handling when mode set fails
When mode set fails due to some transient failures, it will atleast
reset the state of runtime usage count and also let the runtime
suspend retry from the driver framework.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-11-16 20:22:34 +00:00
Laurentiu Palcu 8ecbb3c3c7 iio: accel: BMC150: add support for other Bosch chips
The following chips are either similar or have only the resolution
different. Hence, change this driver to support these chips too:

BMI055  - combo chip (accelerometer part is identical to BMC150's)
BMA255  - identical to BMC150's accelerometer
BMA222E - 8 bit resolution
BMA250E - 10 bit resolution
BMA280  - 14 bit resolution

Additionally:
 * add bmc150_accel_match_acpi_device() function to check that the device
   has been enumerated through ACPI;
 * rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
   since the ACPI matching has been moved to the new function.  Also, this
   will allow for the GPIO matching to be done against a device tree too, not only
   ACPI tree;
 * rename bmc150_scale_info struct member 'range' to 'reg_range' to be
   consistent with the naming convention used elsewhere in the driver
   and declare it u8, instead of int;
 * change CONFIG description to list all supported chips;

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-09-13 21:35:46 +01:00
Laurentiu Palcu b31b05cf62 iio: accel: BMC150: fix issues when CONFIG_PM_RUNTIME is not set
When CONFIG_PM_RUNTIME is not set, the following issues are seen:
 * warning message at compilation time:
    warning: 'bmc150_accel_get_startup_times' defined but not used [-Wunused-function]
 * bmc150_accel_set_power_state() will always fail and reading the
   accelerometer data is impossible;
   This occurs because of the call to pm_runtime_put_autosuspend calls
   __pm_runtime_suspend which returns -ENOSYS.

This commit fixes these.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-08-30 11:44:26 +01:00
Laurentiu Palcu 823615e2de iio: accel: BMC150: fix scale value for 16G
According to documentation ([1] - page 27), the range for 16G is
7.81mg/LSB. Converted to SI, this is:
    7.81 * 10^-3 * 9.80665 m/s^2 / LSB = 0.0765899365 m/s^2 / LSB

[1] http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-08-30 11:35:11 +01:00
Srinivas Pandruvada bd7fe5b719 iio: accel: BMC150 accel support
This change implements BMC150 accelerometer driver. A BMC150 package
consist of a compass and an accelerometer. This driver only implements
accelerometer part.
Spec downloaded from:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf

This sensor chip supports many advanced features, but this driver
implements minimum feature set which is a must to be useful.
This driver can be enhanced incrementally.
If the sensor vendor wants to update full featured version, they
can substitute or enhance this driver when they get chance.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-08-07 11:43:49 +01:00