devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Ciprian Regus <ciprian.regus@analog.com>
Cc: <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 4/5] drivers: iio: adc: LTC2499 support
Date: Sun, 4 Sep 2022 16:06:11 +0100	[thread overview]
Message-ID: <20220904160611.11beb352@jic23-huawei> (raw)
In-Reply-To: <20220901121700.1325733-4-ciprian.regus@analog.com>

On Thu, 1 Sep 2022 15:16:59 +0300
Ciprian Regus <ciprian.regus@analog.com> wrote:

> The LTC2499 is a 16-channel (eight differential), 24-bit,
> ADC with Easy Drive technology and a 2-wire, I2C interface.
> 
> Implement support for the LTC2499 ADC by extending the LTC2497
> driver. A new chip_info struct is added to differentiate between
> chip types and resolutions when reading data from the device.
> 
> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>

A few small comments inline, but looks pretty good to me.

Jonathan

> ---
> changes in v2:
>  - removed the bitfield.h and bitops.h includes, since they were not needed.
>  - removed a blank line.
>  - replaced the data buffer for the ltc2497_driverdata with a union.
>  - depending on frame size, i2c transfers use either 3 or 4 byte buffers, instead
>    of always using a __be32.
>  - added a comment which explains the output data format and how does sign extension.
>    happen.
>  - added the const modifier for the chip_info structs.
>  - renamed the chip_info struct to ltc2497_chip_info.
>  - renamed the chip_type enum to ltc2497_chip_type
>  - added probe fallback to using i2c_device_id in case OF fails.
>  - used BITS_TO_BYTES() instead of dividing by 8.
>  - used a tab instead of a space in a struct field declaration, which in v1 appeared as
>    if the line was deleted and added back.
>  - added back a trailing comma.
>  - rearranged variable declaration lines so that longer ones would be first.
>  - used pointers to a chip info struct in the i2c_device_id table, instead of enums. 
>  drivers/iio/adc/ltc2496.c      |  8 ++++-
>  drivers/iio/adc/ltc2497-core.c |  2 +-
>  drivers/iio/adc/ltc2497.c      | 56 +++++++++++++++++++++++++++++++---
>  drivers/iio/adc/ltc2497.h      | 11 +++++++
>  4 files changed, 70 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/adc/ltc2496.c b/drivers/iio/adc/ltc2496.c
> index dfb3bb5997e5..bf89d5ae19af 100644
> --- a/drivers/iio/adc/ltc2496.c
> +++ b/drivers/iio/adc/ltc2496.c
> @@ -15,6 +15,7 @@
>  #include <linux/iio/driver.h>
>  #include <linux/module.h>
>  #include <linux/mod_devicetable.h>
> +#include <linux/property.h>
>  
>  #include "ltc2497.h"
>  
> @@ -74,6 +75,7 @@ static int ltc2496_probe(struct spi_device *spi)
>  	spi_set_drvdata(spi, indio_dev);
>  	st->spi = spi;
>  	st->common_ddata.result_and_measure = ltc2496_result_and_measure;
> +	st->common_ddata.chip_info = device_get_match_data(dev);

Hmm. This driver doesn't provide the other i2c registration path
(i2c_device_id table) so this is fine.  Adding that table can be a problem
for whoever needs it sometime in the future (I'm fine with patches to add
it though if anyone wants to write one!)
>  
>  	return ltc2497core_probe(dev, indio_dev);
>  }
> @@ -85,8 +87,12 @@ static void ltc2496_remove(struct spi_device *spi)
>  	ltc2497core_remove(indio_dev);
>  }
>  
> +static const struct ltc2497_chip_info ltc2496_info = {
> +	.resolution = 16,
> +};
> +
>  static const struct of_device_id ltc2496_of_match[] = {
> -	{ .compatible = "lltc,ltc2496", },
> +	{ .compatible = "lltc,ltc2496", .data = &ltc2496_info, },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, ltc2496_of_match);
> diff --git a/drivers/iio/adc/ltc2497-core.c b/drivers/iio/adc/ltc2497-core.c
> index 2a485c8a1940..b2752399402c 100644
> --- a/drivers/iio/adc/ltc2497-core.c
> +++ b/drivers/iio/adc/ltc2497-core.c
> @@ -95,7 +95,7 @@ static int ltc2497core_read_raw(struct iio_dev *indio_dev,
>  			return ret;
>  
>  		*val = ret / 1000;
> -		*val2 = 17;
> +		*val2 = ddata->chip_info->resolution + 1;
>  
>  		return IIO_VAL_FRACTIONAL_LOG2;
>  
> diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c
> index f7c786f37ceb..2f660015f34b 100644
> --- a/drivers/iio/adc/ltc2497.c
> +++ b/drivers/iio/adc/ltc2497.c
> @@ -12,6 +12,7 @@
>  #include <linux/iio/driver.h>
>  #include <linux/module.h>
>  #include <linux/mod_devicetable.h>
> +#include <linux/property.h>
>  
>  #include "ltc2497.h"
>  
> @@ -19,11 +20,16 @@ struct ltc2497_driverdata {
>  	/* this must be the first member */
>  	struct ltc2497core_driverdata common_ddata;
>  	struct i2c_client *client;
> +	u32 recv_size;
> +	u32 sub_lsb;
>  	/*
>  	 * DMA (thus cache coherency maintenance) may require the
>  	 * transfer buffers to live in their own cache lines.
>  	 */
> -	__be32 buf __aligned(IIO_DMA_MINALIGN);
> +	union {
> +		__be32 d32;
> +		u8 d8[3];
> +	} data __aligned(IIO_DMA_MINALIGN);
>  };
>  
>  static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata,
> @@ -34,13 +40,29 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata,
>  	int ret;
>  
>  	if (val) {
> -		ret = i2c_master_recv(st->client, (char *)&st->buf, 3);
> +		if (st->recv_size == 3)
> +			ret = i2c_master_recv(st->client, (char *)&st->data.d8, st->recv_size);
> +		else
> +			ret = i2c_master_recv(st->client, (char *)&st->data.d32, st->recv_size);
> +
>  		if (ret < 0) {
>  			dev_err(&st->client->dev, "i2c_master_recv failed\n");
>  			return ret;
>  		}
>  
> -		*val = (be32_to_cpu(st->buf) >> 14) - (1 << 17);
> +		/*
> +		 * The data format is 16/24 bit 2s complement, but with an upper sign bit on the
> +		 * resolution + 1 position, which is set for positive values only. Given this
> +		 * bit's value, subtracting BIT(resolution + 1) from the ADC's result is
> +		 * equivalent to a sign extension.

Description looks good to me.  Thanks for adding.

> +		 */
> +		if (st->recv_size == 3) {
> +			*val = (get_unaligned_be24(st->data.d8) >> st->sub_lsb)
> +				- BIT(ddata->chip_info->resolution + 1);
> +		} else {
> +			*val = (be32_to_cpu(st->data.d32) >> st->sub_lsb)
> +				- BIT(ddata->chip_info->resolution + 1);
> +		}
>  	}
>  

>  
> +static const struct ltc2497_chip_info ltc2497_info[] = {
> +	[TYPE_LTC2497] = {
> +		.resolution = 16,
> +		.name = NULL,
> +	},
> +	[TYPE_LTC2499] = {
> +		.resolution = 24,
> +		.name = "ltc2499",
> +	},
> +};
> +
>  static const struct i2c_device_id ltc2497_id[] = {
> -	{ "ltc2497", 0 },
> +	{ "ltc2497", (kernel_ulong_t)&ltc2497_info[TYPE_LTC2497] },
> +	{ "ltc2499", (kernel_ulong_t)&ltc2497_info[TYPE_LTC2497] },

TYPE_LTC2499

Guess you haven't tested this particular path but should be easy to
force it by not setting the of_device_id table pointer (or you could
use a board file but that's more trouble than ti's worth).

>  	{ }
>  };
>  MODULE_DEVICE_TABLE(i2c, ltc2497_id);
>  
>  static const struct of_device_id ltc2497_of_match[] = {
> -	{ .compatible = "lltc,ltc2497", },
> +	{ .compatible = "lltc,ltc2497", .data = &ltc2497_info[TYPE_LTC2497] },
> +	{ .compatible = "lltc,ltc2499", .data = &ltc2497_info[TYPE_LTC2499] },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, ltc2497_of_match);
> diff --git a/drivers/iio/adc/ltc2497.h b/drivers/iio/adc/ltc2497.h
> index d0b42dd6b8ad..95f6a5f4d4a6 100644
> --- a/drivers/iio/adc/ltc2497.h
> +++ b/drivers/iio/adc/ltc2497.h
> @@ -4,9 +4,20 @@
>  #define LTC2497_CONFIG_DEFAULT		LTC2497_ENABLE
>  #define LTC2497_CONVERSION_TIME_MS	150ULL
>  
> +enum ltc2497_chip_type {
> +	TYPE_LTC2496,

Hmm. this is a little interesting given there is no
such entry in the info table so that table will get pushed out
to have an empty first entry.  Maybe push this chip_type definition
down into the relevant c file and drop the LTC2496 entry (which will
then seem fine as that .c file doesn't cover that part.

> +	TYPE_LTC2497,
> +	TYPE_LTC2499,
> +};
> +


  parent reply	other threads:[~2022-09-04 15:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 12:16 [PATCH v2 1/5] dt-bindings: iio: adc: Add docs for LTC2499 Ciprian Regus
2022-09-01 12:16 ` [PATCH v2 2/5] Add the LTC2496 MAINTAINERS entry Ciprian Regus
2022-09-04 14:54   ` Jonathan Cameron
2022-09-01 12:16 ` [PATCH v2 3/5] Remove duplicate matching entry Ciprian Regus
2022-09-01 12:16 ` [PATCH v2 4/5] drivers: iio: adc: LTC2499 support Ciprian Regus
2022-09-01 13:23   ` Krzysztof Kozlowski
2022-09-02 11:06     ` Jonathan Cameron
2022-09-02 11:37       ` Andy Shevchenko
2022-09-04 14:55         ` Jonathan Cameron
2022-09-05  8:58           ` Krzysztof Kozlowski
2022-09-01 20:00   ` kernel test robot
2022-09-04 15:08     ` Jonathan Cameron
2022-09-01 20:10   ` kernel test robot
2022-09-04 15:06   ` Jonathan Cameron [this message]
2022-09-01 12:17 ` [PATCH v2 5/5] drivers: iio: adc: Rename the LTC2499 iio device Ciprian Regus
2022-09-04 15:09   ` Jonathan Cameron
2022-09-01 13:27 ` [PATCH v2 1/5] dt-bindings: iio: adc: Add docs for LTC2499 Krzysztof Kozlowski
2022-09-04 14:53 ` Jonathan Cameron

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=20220904160611.11beb352@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=ciprian.regus@analog.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.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).