From: Lars-Peter Clausen <lars@metafoo.de>
To: Matt Ranostay <mranostay@gmail.com>,
marex@denx.de, matt@ohporter.com, pantelis.antoniou@gmail.com,
jic23@kernel.org
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR
Date: Sun, 02 Aug 2015 11:42:16 +0200 [thread overview]
Message-ID: <55BDE5F8.9090201@metafoo.de> (raw)
In-Reply-To: <1438401484-22101-3-git-send-email-mranostay@gmail.com>
On 08/01/2015 05:58 AM, Matt Ranostay wrote:
[...]
> +
> +struct lidar_data {
> + struct mutex lock;
> + struct iio_dev *indio_dev;
> + struct i2c_client *client;
> +
> + /* config */
> + int calib_bias;
> +
> + u16 buffer[5]; /* 2 byte distance + 8 byte timestamp */
Needs to be in its own cacheline to avoid issues if the I2C controller is
using DMA.
u16 buffer[5] ____cacheline_aligned;
> +};
[...]
> +static inline int lidar_read_byte(struct lidar_data *data, int reg)
I'd drop the inline. The compiler is smart enough to figure out whether it
makes sense to inline it or not.
> +{
> + struct i2c_client *client = data->client;
> + int ret;
> +
> + ret = i2c_smbus_write_byte(client, reg);
> + if (ret < 0) {
> + dev_err(&client->dev, "cannot write addr value");
> + return ret;
> + }
> +
> + ret = i2c_smbus_read_byte(client);
> + if (ret < 0) {
> + dev_err(&client->dev, "cannot read data value");
> + return ret;
> + }
Instead of using a write_byte/read_byte combination rather use
i2c_smbus_read_byte_data(). I think that will do the same, but in one atomic
operation.
> +
> + return ret;
> +}
[...]
> +static int lidar_read_measurement(struct lidar_data *data, u16 *reg)
> +{
> + int ret;
> + int val;
> +
> + ret = lidar_read_byte(data, LIDAR_REG_DATA_HBYTE);
> + if (ret < 0)
> + return ret;
> + val = ret << 8;
> +
> + ret = lidar_read_byte(data, LIDAR_REG_DATA_LBYTE);
> + if (ret < 0)
> + return ret;
> + val |= ret;
> +
> + /* correct any possible overflow or underflow */
> + val += data->calib_bias / 10000;
Typically calib bias is only meant for a offset correction that is done in
hardware rather than in software. What's the usecase for doing it in
kernelspace rather than in userspace?
> + if (val < 0)
> + val = 0;
> +
> + if (val > LIDAR_REG_DATA_MAX)
> + val = LIDAR_REG_DATA_MAX;
> +
> + *reg = val;
> +
> + return 0;
> +}
[...]
> +static int lidar_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct lidar_data *data = iio_priv(indio_dev);
> + int ret = -EINVAL;
> +
> + if (iio_buffer_enabled(indio_dev) && mask == IIO_CHAN_INFO_RAW)
> + return -EBUSY;
> +
> + mutex_lock(&data->lock);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW: {
> + u16 reg;
> +
> + ret = lidar_get_measurement(data, ®);
> + if (!ret) {
> + *val = reg / 100;
> + *val2 = (reg % 100) * 10000;
> + ret = IIO_VAL_INT_PLUS_MICRO;
The raw attribute is supposed to return the raw value as a IIO_VAL_INT. A
scale attribute should be used to indicate the conversion factor to get the
proper unit.
> + }
> + break;
> + }
> + case IIO_CHAN_INFO_CALIBBIAS:
> + *val = 0;
> + *val2 = data->calib_bias;
> + ret = IIO_VAL_INT_PLUS_MICRO;
> + break;
> + }
> +
> + mutex_unlock(&data->lock);
> +
> + return ret;
> +}
[...]
> +static struct iio_info lidar_info = {
const
> + .driver_module = THIS_MODULE,
> + .read_raw = lidar_read_raw,
> + .write_raw = lidar_write_raw,
> +};
[...]
> +static struct i2c_driver lidar_driver = {
> + .driver = {
> + .name = LIDAR_DRV_NAME,
> + .owner = THIS_MODULE,
You added a DT vendor prefix, but there is no of match table for the driver.
> + },
> + .probe = lidar_probe,
> + .remove = lidar_remove,
> + .id_table = lidar_id,
> +};
> +module_i2c_driver(lidar_driver);
next prev parent reply other threads:[~2015-08-02 9:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-01 3:58 [PATCH 0/2] iio: proximity: add PulsedLight LIDAR sensor support Matt Ranostay
2015-08-01 3:58 ` [PATCH 1/2] devicetree: add PulsedLight vendor prefix Matt Ranostay
2015-08-01 3:58 ` [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR Matt Ranostay
2015-08-01 8:39 ` Vladimir Barinov
2015-08-01 21:17 ` Jonathan Cameron
2015-08-01 22:22 ` Matt Ranostay
2015-08-02 7:36 ` Vladimir Barinov
2015-08-02 18:18 ` Jonathan Cameron
2015-08-02 9:42 ` Lars-Peter Clausen [this message]
2015-08-02 18:23 ` Jonathan Cameron
2015-08-02 18:39 ` Lars-Peter Clausen
2015-08-02 19:52 ` Jonathan Cameron
2015-08-02 21:28 ` Matt Ranostay
2015-08-03 8:00 ` Lars-Peter Clausen
2015-08-03 8:19 ` Matt Ranostay
2015-08-02 9:45 ` Lars-Peter Clausen
-- strict thread matches above, loose matches on Subject: below --
2015-08-12 6:01 [PATCH v5 0/2] iio: proximity: add PulsedLight LIDAR sensor support Matt Ranostay
2015-08-12 6:01 ` [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR Matt Ranostay
2015-08-16 8:24 ` Jonathan Cameron
2015-08-18 2:33 ` Matt Ranostay
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=55BDE5F8.9090201@metafoo.de \
--to=lars@metafoo.de \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=matt@ohporter.com \
--cc=mranostay@gmail.com \
--cc=pantelis.antoniou@gmail.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).