devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	marex-ynQEQJNshbs@public.gmane.org,
	lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org,
	vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v4 2/2] iio: proximity: add support for PulsedLight LIDAR
Date: Sat, 8 Aug 2015 16:05:09 +0100	[thread overview]
Message-ID: <55C61AA5.10105@kernel.org> (raw)
In-Reply-To: <1438749676-28781-3-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 05/08/15 05:41, Matt Ranostay wrote:
> Add support for the PulsedLight LIDAR rangefinder sensor which allows
> high speed (over 300Hz) distance measurements using Barker Coding within
> 40 meter range.
> 
> Support only tested on the "blue label" rev 2, but may work using low
> sample frequencies on the original version.
> 
> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Couple of bits inline.  Only one that really matters is I suspect
that simply calling it lidar (and naming the file lidar.c) is going
to give us problems if they or someone else produces a similar lidar
device in future.

Perhaps file name as pulsedlight-lidar-lite-v2.c
and name as lidar-lite-v2 for device tree etc.

Otherwise, nice little driver for a nice looking bit of kit.

Thanks,

Jonathan
> ---
>  drivers/iio/proximity/Kconfig  |  12 ++
>  drivers/iio/proximity/Makefile |   1 +
>  drivers/iio/proximity/lidar.c  | 294 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/iio/proximity/lidar.c
> 
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index 41a8d8f..e64fc5b 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -20,6 +20,18 @@ endmenu
>  
>  menu "Proximity sensors"
>  
> +config LIDAR
> +	tristate "PulsedLight LIDAR sensor"
> +	select IIO_BUFFER
> +	select IIO_TRIGGERED_BUFFER
> +	depends on I2C
> +	help
> +	  Say Y to build a driver for PulsedLight LIDAR range finding
> +	  sensor.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called lidar.
> +
>  config SX9500
>  	tristate "SX9500 Semtech proximity sensor"
>  	select IIO_BUFFER
> diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
> index 9818dc5..36a95f3 100644
> --- a/drivers/iio/proximity/Makefile
> +++ b/drivers/iio/proximity/Makefile
> @@ -4,4 +4,5 @@
>  
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_AS3935)		+= as3935.o
> +obj-$(CONFIG_LIDAR)		+= lidar.o
>  obj-$(CONFIG_SX9500)		+= sx9500.o
> diff --git a/drivers/iio/proximity/lidar.c b/drivers/iio/proximity/lidar.c
> new file mode 100644
> index 0000000..fdec9a2
> --- /dev/null
> +++ b/drivers/iio/proximity/lidar.c
> @@ -0,0 +1,294 @@
> +/*
> + * lidar.c - Support for PulsedLight LIDAR range finding sensor
> + *
> + * Copyright (C) 2015 Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * TODO: runtime pm, interrupt mode, and signal strength reporting
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/delay.h>
> +#include <linux/mutex.h>
> +#include <linux/module.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/trigger_consumer.h>
> +
> +#define LIDAR_REG_CONTROL		0x00
> +#define LIDAR_REG_CONTROL_ACQUIRE	BIT(2)
> +
> +#define LIDAR_REG_STATUS		0x01
> +#define LIDAR_REG_STATUS_INVALID	BIT(3)
> +#define LIDAR_REG_STATUS_READY		BIT(0)
> +
> +#define LIDAR_REG_DATA_HBYTE	0x0f
> +#define LIDAR_REG_DATA_LBYTE	0x10
> +
> +#define LIDAR_DRV_NAME "lidar"
> +
> +struct lidar_data {
> +	struct mutex lock;
> +	struct iio_dev *indio_dev;
> +	struct i2c_client *client;
> +
> +	u16 buffer[8]; /* 2 byte distance + 8 byte timestamp */
> +};
> +
> +static const struct iio_chan_spec lidar_channels[] = {
> +	{
> +		.type = IIO_DISTANCE,
> +		.info_mask_separate =
> +			BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> +		.scan_index = 0,
> +		.scan_type = {
> +			.sign = 'u',
> +			.realbits = 16,
> +			.storagebits = 16,
> +		},
> +	},
> +	IIO_CHAN_SOFT_TIMESTAMP(1),
> +};
> +
> +static int lidar_read_byte(struct lidar_data *data, int reg)
> +{
> +	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;
Drop this return ret as otherwise various static checkers
will moan at me (falling through gives the same result)
> +	}
> +
> +	return ret;
> +}
> +
> +static inline int lidar_write_control(struct lidar_data *data, int val)
> +{
> +	return i2c_smbus_write_byte_data(data->client, LIDAR_REG_CONTROL, val);
> +}
> +
> +static int lidar_read_measurement(struct lidar_data *data, u16 *reg)
> +{
> +	int ret;
> +	int val;
> +
> +	/*
> +	 * Device needs a STOP condition between address write, and data read
> +	 * so in turn i2c_smbus_read_byte_data cannot be used
Good documentation of this.  However, I'd move it to inside the read_byte
function above rather than here. 
> +	 */
> +
> +	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;
> +	*reg = val;
> +
> +	return 0;
> +}
> +
> +static int lidar_get_measurement(struct lidar_data *data, u16 *reg)
> +{
> +	struct i2c_client *client = data->client;
> +	int tries = 10;
> +	int ret;
> +
> +	/* start sample */
> +	ret = lidar_write_control(data, LIDAR_REG_CONTROL_ACQUIRE);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "cannot send start measurement command");
> +		return ret;
> +	}
> +
> +	while (tries--) {
> +		usleep_range(1000, 2000);
> +
> +		ret = lidar_read_byte(data, LIDAR_REG_STATUS);
> +		if (ret < 0)
> +			break;
> +
> +		/* return 0 since laser is likely pointed out of range */
> +		if (ret & LIDAR_REG_STATUS_INVALID) {
> +			*reg = 0;
> +			ret = 0;
> +			break;
> +		}
> +
> +		/* sample ready to read */
> +		if (!(ret & LIDAR_REG_STATUS_READY)) {
> +			ret = lidar_read_measurement(data, reg);
> +			break;
> +		}
> +		ret = -EIO;
> +	}
> +
> +	return ret;
> +}
> +
> +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;
> +
> +	mutex_lock(&data->lock);
> +
> +	if (iio_buffer_enabled(indio_dev) && mask == IIO_CHAN_INFO_RAW) {
> +		ret = -EBUSY;
> +		goto error_busy;
> +	}
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW: {
> +		u16 reg;
> +
> +		ret = lidar_get_measurement(data, &reg);
> +		if (!ret) {
> +			*val = reg;
> +			ret = IIO_VAL_INT;
> +		}
> +		break;
> +	}
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 0;
> +		*val2 = 10000;
> +		ret = IIO_VAL_INT_PLUS_MICRO;
> +		break;
> +	}
> +
> +error_busy:
> +	mutex_unlock(&data->lock);
> +
> +	return ret;
> +}
> +
> +static irqreturn_t lidar_trigger_handler(int irq, void *private)
> +{
> +	struct iio_poll_func *pf = private;
> +	struct iio_dev *indio_dev = pf->indio_dev;
> +	struct lidar_data *data = iio_priv(indio_dev);
> +	int ret;
> +
> +	ret = lidar_get_measurement(data, &data->buffer[0]);
data->buffer should be the same pointer unless I'm going crazy (always
a posibility)
> +	if (!ret) {
> +		iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> +						   iio_get_time_ns());
> +	} else {
> +		dev_err(&data->client->dev, "cannot read LIDAR measurement");
> +	}
> +
> +	iio_trigger_notify_done(indio_dev->trig);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static const struct iio_info lidar_info = {
> +	.driver_module = THIS_MODULE,
> +	.read_raw = lidar_read_raw,
> +};
> +
> +static int lidar_probe(struct i2c_client *client,
> +		       const struct i2c_device_id *id)
> +{
> +	struct lidar_data *data;
> +	struct iio_dev *indio_dev;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	indio_dev->info = &lidar_info;
> +	indio_dev->name = LIDAR_DRV_NAME;
> +	indio_dev->channels = lidar_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(lidar_channels);
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +
> +	data = iio_priv(indio_dev);
> +	i2c_set_clientdata(client, indio_dev);
> +
> +	data->client = client;
> +	data->indio_dev = indio_dev;
> +	mutex_init(&data->lock);
> +
> +	ret = iio_triggered_buffer_setup(indio_dev, NULL,
> +					 lidar_trigger_handler, NULL);
> +	if (ret)
> +		return ret;
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret)
> +		goto error_unreg_buffer;
> +
> +	return 0;
> +
> +error_unreg_buffer:
> +	iio_triggered_buffer_cleanup(indio_dev);
> +
> +	return ret;
> +}
> +
> +static int lidar_remove(struct i2c_client *client)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(client);
> +
> +	iio_device_unregister(indio_dev);
> +	iio_triggered_buffer_cleanup(indio_dev);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id lidar_id[] = {
> +	{"lidar", 0},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(i2c, lidar_id);
> +
> +static const struct of_device_id lidar_dt_ids[] = {
> +	{ .compatible = "pulsedlight,lidar" },

Not a more descriptive name?  Website suggests
things like
lidar-lite-v2

I just worry they'll come out with a completely incompatible
interface to some new unit that is also a lidar and we'll be
forever confused!

> +	{ }
> +};
> +
> +static struct i2c_driver lidar_driver = {
> +	.driver = {
> +		.name	= LIDAR_DRV_NAME,
> +		.of_match_table	= of_match_ptr(lidar_dt_ids),
> +	},
> +	.probe		= lidar_probe,
> +	.remove		= lidar_remove,
> +	.id_table	= lidar_id,
> +};
> +module_i2c_driver(lidar_driver);
> +
> +MODULE_AUTHOR("Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("PulsedLight LIDAR sensor");
> +MODULE_LICENSE("GPL");
> 

  parent reply	other threads:[~2015-08-08 15:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  4:41 [PATCH v4 0/2] iio: proximity: add PulsedLight LIDAR sensor support Matt Ranostay
     [not found] ` <1438749676-28781-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-05  4:41   ` [PATCH v4 1/2] devicetree: add PulsedLight vendor + device docs Matt Ranostay
2015-08-05  4:41   ` [PATCH v4 2/2] iio: proximity: add support for PulsedLight LIDAR Matt Ranostay
     [not found]     ` <1438749676-28781-3-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-08 15:05       ` Jonathan Cameron [this message]
     [not found]         ` <55C61AA5.10105-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-12  4:24           ` 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=55C61AA5.10105@kernel.org \
    --to=jic23-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org \
    --cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marex-ynQEQJNshbs@public.gmane.org \
    --cc=mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org \
    /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).