From: Hartmut Knaack <knaack.h@gmx.de>
To: Octavian Purdila <octavian.purdila@intel.com>, linux-iio@vger.kernel.org
Cc: srinivas.pandruvada@intel.com
Subject: Re: [RFC 2/8] iio: bmc150: refactor slope duration and threshold update
Date: Sun, 23 Nov 2014 22:58:17 +0100 [thread overview]
Message-ID: <54725879.6030602@gmx.de> (raw)
In-Reply-To: <1416246966-3083-3-git-send-email-octavian.purdila@intel.com>
Octavian Purdila schrieb am 17.11.2014 18:56:
> Move the slope duration and threshold update in separate functions
> to reduce code duplicate between chip init and motion interrupt setup.
>
> The patch also moves the update from the motion interrupt setup
> function to the write event function so that we can later refactor the
> interrupt code.
>
> Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
> ---
> drivers/iio/accel/bmc150-accel.c | 109 ++++++++++++++++++++++-----------------
> 1 file changed, 62 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
> index 22c096c..5bfb09d 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -266,6 +266,51 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val,
> return -EINVAL;
> }
>
> +static int bmc150_accel_update_slope_threshold(struct bmc150_accel_data *data,
> + int val)
> +{
> + int ret = 0;
> +
> + val &= 0xFF;
> +
> + ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_6,
> + val);
> + if (ret < 0) {
> + dev_err(&data->client->dev, "Error writing reg_int_6\n");
> + return ret;
> + }
> + data->slope_thres = val;
> +
> + dev_dbg(&data->client->dev, "%s: %x\n", __func__, val);
> +
> + return ret;
> +}
> +
> +static int bmc150_accel_update_slope_duration(struct bmc150_accel_data *data,
> + int val)
> +{
> + int ret;
> +
> + val &= BMC150_ACCEL_SLOPE_DUR_MASK;
> +
> + ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_INT_5);
> + if (ret < 0) {
> + dev_err(&data->client->dev, "Error reading reg_int_5\n");
> + return ret;
> + }
> + ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_5,
> + val | ret);
You will have more joy if you clear the appropriate bits in ret before setting new ones.
> + if (ret < 0) {
> + dev_err(&data->client->dev, "Error write reg_int_5\n");
> + return ret;
> + }
> + data->slope_dur = val;
> +
> + dev_dbg(&data->client->dev, "%s: %x\n", __func__, val);
> +
> + return ret;
> +}
> +
> static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
> {
> int ret;
> @@ -304,32 +349,16 @@ static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
>
> data->range = BMC150_ACCEL_DEF_RANGE_4G;
>
> - /* Set default slope duration */
> - ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_INT_5);
> - if (ret < 0) {
> - dev_err(&data->client->dev, "Error reading reg_int_5\n");
> - return ret;
> - }
> - data->slope_dur |= BMC150_ACCEL_DEF_SLOPE_DURATION;
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_INT_5,
> - data->slope_dur);
> - if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_int_5\n");
> + /* Set default slope duration and thresholds */
> + ret = bmc150_accel_update_slope_duration(data,
> + BMC150_ACCEL_DEF_SLOPE_DURATION);
> + if (ret < 0)
> return ret;
> - }
> - dev_dbg(&data->client->dev, "slope_dur %x\n", data->slope_dur);
>
> - /* Set default slope thresholds */
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_INT_6,
> - BMC150_ACCEL_DEF_SLOPE_THRESHOLD);
> - if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_int_6\n");
> + ret = bmc150_accel_update_slope_threshold(data,
> + BMC150_ACCEL_DEF_SLOPE_THRESHOLD);
> + if (ret < 0)
> return ret;
> - }
> - data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
> - dev_dbg(&data->client->dev, "slope_thres %x\n", data->slope_thres);
>
> /* Set default as latched interrupts */
> ret = i2c_smbus_write_byte_data(data->client,
> @@ -372,24 +401,6 @@ static int bmc150_accel_setup_any_motion_interrupt(
> }
>
> if (status) {
> - /* Set slope duration (no of samples) */
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_INT_5,
> - data->slope_dur);
> - if (ret < 0) {
> - dev_err(&data->client->dev, "Error write reg_int_5\n");
> - return ret;
> - }
> -
> - /* Set slope thresholds */
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_INT_6,
> - data->slope_thres);
> - if (ret < 0) {
> - dev_err(&data->client->dev, "Error write reg_int_6\n");
> - return ret;
> - }
> -
> /*
> * New data interrupt is always non-latched,
> * which will have higher priority, so no need
> @@ -726,7 +737,7 @@ static int bmc150_accel_read_event(struct iio_dev *indio_dev,
> *val = data->slope_thres;
> break;
> case IIO_EV_INFO_PERIOD:
> - *val = data->slope_dur & BMC150_ACCEL_SLOPE_DUR_MASK;
> + *val = data->slope_dur;
> break;
> default:
> return -EINVAL;
> @@ -743,23 +754,27 @@ static int bmc150_accel_write_event(struct iio_dev *indio_dev,
> int val, int val2)
> {
> struct bmc150_accel_data *data = iio_priv(indio_dev);
> + int ret;
>
> if (data->ev_enable_state)
> return -EBUSY;
>
> switch (info) {
> case IIO_EV_INFO_VALUE:
> - data->slope_thres = val;
> + mutex_lock(&data->mutex);
> + ret = bmc150_accel_update_slope_threshold(data, val);
> + mutex_unlock(&data->mutex);
> break;
> case IIO_EV_INFO_PERIOD:
> - data->slope_dur &= ~BMC150_ACCEL_SLOPE_DUR_MASK;
> - data->slope_dur |= val & BMC150_ACCEL_SLOPE_DUR_MASK;
> + mutex_lock(&data->mutex);
> + ret = bmc150_accel_update_slope_duration(data, val);
> + mutex_unlock(&data->mutex);
> break;
> default:
> - return -EINVAL;
> + ret = -EINVAL;
> }
>
> - return 0;
> + return ret;
> }
>
> static int bmc150_accel_read_event_config(struct iio_dev *indio_dev,
>
next prev parent reply other threads:[~2014-11-23 21:58 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 17:55 [RFC 0/8] iio: add support for hardware fifo Octavian Purdila
2014-11-17 17:55 ` [RFC 1/8] " Octavian Purdila
2014-11-18 13:37 ` jic23
2014-11-18 15:21 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 2/8] iio: bmc150: refactor slope duration and threshold update Octavian Purdila
2014-11-23 21:58 ` Hartmut Knaack [this message]
2014-11-23 22:16 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 3/8] iio: bmc150: refactor interrupt enabling Octavian Purdila
2014-11-23 22:02 ` Hartmut Knaack
2014-11-23 22:24 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 4/8] iio: bmc150: exit early if event / trigger state is not changed Octavian Purdila
2014-11-17 17:56 ` [RFC 5/8] iio: bmc150: introduce bmc150_accel_interrupt Octavian Purdila
2014-11-17 17:56 ` [RFC 6/8] iio: bmc150: introduce bmc150_accel_trigger Octavian Purdila
2014-11-23 23:06 ` Hartmut Knaack
2014-11-24 10:42 ` Octavian Purdila
2014-11-24 20:26 ` Hartmut Knaack
2014-11-25 16:06 ` Octavian Purdila
2014-11-17 17:56 ` [RFC 7/8] iio: bmc150: introduce bmc150_accel_event Octavian Purdila
2014-11-17 17:56 ` [RFC 8/8] iio: bmc150: add support for hardware fifo Octavian Purdila
2014-11-18 13:49 ` jic23
2014-11-18 15:31 ` Octavian Purdila
2014-11-24 10:37 ` Hartmut Knaack
2014-11-18 13:24 ` [RFC 0/8] iio: " jic23
2014-11-18 15:03 ` Octavian Purdila
2014-11-18 16:44 ` Lars-Peter Clausen
2014-11-18 17:04 ` Octavian Purdila
2014-11-18 17:23 ` Lars-Peter Clausen
2014-11-18 19:35 ` Octavian Purdila
2014-11-19 11:48 ` Lars-Peter Clausen
2014-11-19 12:33 ` Octavian Purdila
2014-12-12 12:57 ` Jonathan Cameron
2014-11-19 13:32 ` Octavian Purdila
2014-11-26 13:06 ` Octavian Purdila
2014-12-01 21:19 ` Lars-Peter Clausen
2014-12-02 9:13 ` Octavian Purdila
2014-12-12 13:10 ` Jonathan Cameron
2014-12-12 13:04 ` Jonathan Cameron
2014-12-12 12:52 ` Jonathan Cameron
2014-11-18 15:35 ` Pandruvada, Srinivas
2014-11-18 16:41 ` Lars-Peter Clausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54725879.6030602@gmx.de \
--to=knaack.h@gmx.de \
--cc=linux-iio@vger.kernel.org \
--cc=octavian.purdila@intel.com \
--cc=srinivas.pandruvada@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).