linux/drivers/iio/accel/bmc150-accel.h
Stephan Gerhold 52ae7c708d iio: accel: bmc150: Add support for BMC156
BMC156 is another accelerometer that works just fine with the bmc150-accel
driver. It's very similar to BMC150 (also a accelerometer + magnetometer
combo) but with only one accelerometer interrupt pin. It would make sense
if only INT1 was exposed but someone at Bosch decided to only have an
INT2 pin.

Try to deal with this by making use of the INT2 support introduced
in the previous commit and force using INT2 for BMC156. To detect
that we need to bring up a simplified version of the previous type IDs.

Note that unlike the type IDs removed in commit c06a6aba68
("iio: accel: bmc150: Drop misleading/duplicate chip identifiers")
here I only add one for the special case of BMC156. Everything else
still happens by reading the CHIP_ID register since the chip type
information often is not accurate in ACPI tables.

Tested-by: Nikita Travkin <nikita@trvn.ru> # BMC156
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210802155657.102766-5-stephan@gerhold.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-08-08 16:48:30 +01:00

96 lines
2.7 KiB
C

/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _BMC150_ACCEL_H_
#define _BMC150_ACCEL_H_
#include <linux/atomic.h>
#include <linux/iio/iio.h>
#include <linux/mutex.h>
#include <linux/regulator/consumer.h>
#include <linux/workqueue.h>
struct regmap;
struct i2c_client;
struct bmc150_accel_chip_info;
struct bmc150_accel_interrupt_info;
/*
* We can often guess better than "UNKNOWN" based on the device IDs
* but unfortunately this information is not always accurate. There are some
* devices where ACPI firmware specifies an ID like "BMA250E" when the device
* actually has a BMA222E. The driver attempts to detect those by reading the
* chip ID from the registers but this information is not always enough either.
*
* Therefore, this enum should be only used when the chip ID detection is not
* enough and we can be reasonably sure that the device IDs are reliable
* in practice (e.g. for device tree platforms).
*/
enum bmc150_type {
BOSCH_UNKNOWN,
BOSCH_BMC156,
};
struct bmc150_accel_interrupt {
const struct bmc150_accel_interrupt_info *info;
atomic_t users;
};
struct bmc150_accel_trigger {
struct bmc150_accel_data *data;
struct iio_trigger *indio_trig;
int (*setup)(struct bmc150_accel_trigger *t, bool state);
int intr;
bool enabled;
};
enum bmc150_accel_interrupt_id {
BMC150_ACCEL_INT_DATA_READY,
BMC150_ACCEL_INT_ANY_MOTION,
BMC150_ACCEL_INT_WATERMARK,
BMC150_ACCEL_INTERRUPTS,
};
enum bmc150_accel_trigger_id {
BMC150_ACCEL_TRIGGER_DATA_READY,
BMC150_ACCEL_TRIGGER_ANY_MOTION,
BMC150_ACCEL_TRIGGERS,
};
struct bmc150_accel_data {
struct regmap *regmap;
struct regulator_bulk_data regulators[2];
struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
struct mutex mutex;
u8 fifo_mode, watermark;
s16 buffer[8];
/*
* Ensure there is sufficient space and correct alignment for
* the timestamp if enabled
*/
struct {
__le16 channels[3];
s64 ts __aligned(8);
} scan;
u8 bw_bits;
u32 slope_dur;
u32 slope_thres;
u32 range;
int ev_enable_state;
int64_t timestamp, old_timestamp; /* Only used in hw fifo mode. */
const struct bmc150_accel_chip_info *chip_info;
enum bmc150_type type;
struct i2c_client *second_device;
void (*resume_callback)(struct device *dev);
struct delayed_work resume_work;
struct iio_mount_matrix orientation;
};
int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq,
enum bmc150_type type, const char *name,
bool block_supported);
int bmc150_accel_core_remove(struct device *dev);
extern const struct dev_pm_ops bmc150_accel_pm_ops;
extern const struct regmap_config bmc150_regmap_conf;
#endif /* _BMC150_ACCEL_H_ */