All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukrut Bellary <sbellary@baylibre.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Matti Vaittinen" <mazziesaccount@gmail.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Angelo Compagnucci" <angelo.compagnucci@gmail.com>,
	"Nishanth Menon" <nm@ti.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/5] iio: adc: ti-adc128s052: Use shift and realbits
Date: Sat, 28 Jun 2025 13:01:53 -0700	[thread overview]
Message-ID: <aGBKMcZGYOcXmKdB@dev-linux> (raw)
In-Reply-To: <20250614142743.23ee2203@jic23-huawei>

On Sat, Jun 14, 2025 at 02:27:43PM +0100, Jonathan Cameron wrote:
> On Sat, 14 Jun 2025 02:15:01 -0700
> Sukrut Bellary <sbellary@baylibre.com> wrote:
> 
> > This adcxx communicates with a host processor via an SPI/Microwire Bus
> > interface. The device family responds with 12-bit data, of which the LSB bits
> > are transmitted by the lower resolution devices as 0. The unavailable bits are
> > 0 in LSB. Shift is calculated per resolution and used in scaling and raw data
> > read.
> > 
> > Create a separate structure for each device type instead of an array.
> > These changes help to reuse the driver to support the family of devices with
> > name ADC<bb><c>S<sss>, where
> > * bb is the resolution in number of bits (8, 10, 12)
> > * c is the number of channels (1, 2, 4, 8)
> > * sss is the maximum conversion speed (021 for 200 kSPS, 051 for 500 kSPS
> > and 101 for 1 MSPS)
> > 
> > Complete datasheets are available at TI's website here:
> > https://www.ti.com/lit/ds/symlink/adc<bb><c>s<sss>.pdf
> > 
> > Co-developed-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
> > ---
> >  drivers/iio/adc/ti-adc128s052.c | 115 ++++++++++++++++++--------------
> >  1 file changed, 66 insertions(+), 49 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ti-adc128s052.c b/drivers/iio/adc/ti-adc128s052.c
> > index 1b46a8155803..2b206745e53d 100644
> > --- a/drivers/iio/adc/ti-adc128s052.c
> > +++ b/drivers/iio/adc/ti-adc128s052.c
> > @@ -41,13 +41,14 @@ struct adc128 {
> >  	} __aligned(IIO_DMA_MINALIGN);
> >  };
> >  
> > -static int adc128_adc_conversion(struct adc128 *adc, u8 channel)
> > +static int adc128_adc_conversion(struct adc128 *adc,
> > +				 struct iio_chan_spec const *channel)
> >  {
> >  	int ret;
> >  
> >  	guard(mutex)(&adc->lock);
> >  
> > -	adc->buffer[0] = channel << 3;
> > +	adc->buffer[0] = channel->channel << 3;
> >  	adc->buffer[1] = 0;
> >  
> >  	ret = spi_write(adc->spi, &adc->buffer, sizeof(adc->buffer));
> > @@ -58,7 +59,10 @@ static int adc128_adc_conversion(struct adc128 *adc, u8 channel)
> >  	if (ret < 0)
> >  		return ret;
> >  
> > -	return be16_to_cpu(adc->buffer16) & 0xFFF;
> > +	ret = (be16_to_cpu(adc->buffer16) >> channel->scan_type.shift) &
> > +	       GENMASK(channel->scan_type.realbits - 1, 0);
> > +
> Even though it is a bit long I'd go with
> 
> 	return (be16_to_cpu(adc->buffer16) >> channel->scan_type.shift) &
> 		GENMASK();
>
Thanks for the review.
I will fix this in v5.

> > +	return ret;
> >  }
> >  
> >  static int adc128_read_raw(struct iio_dev *indio_dev,
> > @@ -71,7 +75,7 @@ static int adc128_read_raw(struct iio_dev *indio_dev,
> >  	switch (mask) {
> >  	case IIO_CHAN_INFO_RAW:
> >  
> > -		ret = adc128_adc_conversion(adc, channel->channel);
> > +		ret = adc128_adc_conversion(adc, channel);
> >  		if (ret < 0)
> >  			return ret;
> >  
> > @@ -81,7 +85,7 @@ static int adc128_read_raw(struct iio_dev *indio_dev,
> >  	case IIO_CHAN_INFO_SCALE:
> >  
> >  		*val = adc->vref_mv;
> > -		*val2 = 12;
> > +		*val2 = channel->scan_type.realbits;
> >  		return IIO_VAL_FRACTIONAL_LOG2;
> >  
> >  	default:
> > @@ -90,15 +94,24 @@ static int adc128_read_raw(struct iio_dev *indio_dev,
> >  
> >  }
> >  
> > -#define ADC128_VOLTAGE_CHANNEL(num)	\
> > -	{ \
> > -		.type = IIO_VOLTAGE, \
> > -		.indexed = 1, \
> > -		.channel = (num), \
> > -		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> > -		.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) \
> > +#define _ADC128_VOLTAGE_CHANNEL(num, real_bits)				\
> > +	{								\
> 
> I would minimise the churn and stick to existing style of one space then \
> I don't think we have any specific style guidance around this.
>
I will fix this in v5.

> > +		.type = IIO_VOLTAGE,					\
> > +		.indexed = 1,						\
> > +		.channel = (num),					\
> > +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
> > +		.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),	\
> > +		.scan_index = (num),					\
> > +		.scan_type = {						\
> > +			.sign = 'u',					\
> > +			.realbits = (real_bits),			\
> > +			.storagebits = 16,				\
> > +			.shift = (12 - real_bits),			\
> > +		},							\
> >  	}
> >  
> > +#define ADC128_VOLTAGE_CHANNEL(num) _ADC128_VOLTAGE_CHANNEL(num, 12)
> 
> I wonder if it would be clearer to just have the 12 explicit in each entry
> and skip this two levels of macro thing?
>
Do you mean to pass realbits to
ADC128_VOLTAGE_CHANNEL/_ADC128_VOLTAGE_CHANNEL as e.g.,

static const struct iio_chan_spec adc122s021_channels[] = {
        ADC128_VOLTAGE_CHANNEL(0, 12),
        ADC128_VOLTAGE_CHANNEL(1, 12),
};

I think we added 2nd level macros as ADC082_VOLTAGE_CHANNEL,
ADC102_VOLTAGE_CHANNEL, etc., to have a visual distinction for a different
part nos.
But I am ok if you prefer ADC128_VOLTAGE_CHANNEL with a second parameter
as real_bits.

> > +
> >  static const struct iio_chan_spec adc128s052_channels[] = {
> >  	ADC128_VOLTAGE_CHANNEL(0),
> >  	ADC128_VOLTAGE_CHANNEL(1),
> > @@ -124,26 +137,30 @@ static const struct iio_chan_spec adc124s021_channels[] = {
> >  
> >  static const char * const bd79104_regulators[] = { "iovdd" };
> >  
> > -static const struct adc128_configuration adc128_config[] = {
> > -	{
> > -		.channels = adc128s052_channels,
> > -		.num_channels = ARRAY_SIZE(adc128s052_channels),
> > -		.refname = "vref",
> > -	}, {
> > -		.channels = adc122s021_channels,
> > -		.num_channels = ARRAY_SIZE(adc122s021_channels),
> > -		.refname = "vref",
> > -	}, {
> > -		.channels = adc124s021_channels,
> > -		.num_channels = ARRAY_SIZE(adc124s021_channels),
> > -		.refname = "vref",
> > -	}, {
> > -		.channels = adc128s052_channels,
> > -		.num_channels = ARRAY_SIZE(adc128s052_channels),
> > -		.refname = "vdd",
> > -		.other_regulators = &bd79104_regulators,
> > -		.num_other_regulators = 1,
> > -	},
> > +static const struct adc128_configuration adc122s021_config = {
> > +	.channels = adc122s021_channels,
> > +	.num_channels = ARRAY_SIZE(adc122s021_channels),
> > +	.refname = "vref",
> > +};
> 
> Ideal would be to have this as a precursor patch rather than adding complexity
> to this one which is focused on the bits related stuff.
> 
> It's a good change to have but does make it harder to spot the main
> content in here.
> 
>
I will split this in v5.

> > +
> > +static const struct adc128_configuration adc124s021_config = {
> > +	.channels = adc124s021_channels,
> > +	.num_channels = ARRAY_SIZE(adc124s021_channels),
> > +	.refname = "vref",
> > +};
> 

  reply	other threads:[~2025-06-28 20:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-14  9:14 [PATCH v4 0/5] iio: adc: ti-adc128s052: Add support for adc102s051 Sukrut Bellary
2025-06-14  9:15 ` [PATCH v4 1/5] dt-bindings: iio: adc: ti,adc128s052: Add adc08c and adc10c family Sukrut Bellary
2025-06-16  7:19   ` Krzysztof Kozlowski
2025-06-28 19:34     ` Sukrut Bellary
2025-06-14  9:15 ` [PATCH v4 2/5] iio: adc: ti-adc128s052: Use shift and realbits Sukrut Bellary
2025-06-14 13:27   ` Jonathan Cameron
2025-06-28 20:01     ` Sukrut Bellary [this message]
2025-06-29 16:26       ` Jonathan Cameron
2025-06-30  1:10         ` Sukrut Bellary
2025-06-14  9:15 ` [PATCH v4 3/5] iio: adc: ti-adc128s052: cleanup changes Sukrut Bellary
2025-06-16  5:56   ` Matti Vaittinen
2025-06-14  9:15 ` [PATCH v4 4/5] iio: adc: ti-adc128s052: Add lower resolution devices support Sukrut Bellary
2025-06-14 18:45   ` Andy Shevchenko
2025-06-28 23:09     ` Sukrut Bellary
2025-06-28 23:30       ` David Lechner
2025-06-29  6:06         ` Andy Shevchenko
2025-06-30  1:02           ` Sukrut Bellary
2025-06-14  9:15 ` [PATCH v4 5/5] MAINTAINERS: maintainer for TI's ADCs' driver ti-adc128s052 Sukrut Bellary

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=aGBKMcZGYOcXmKdB@dev-linux \
    --to=sbellary@baylibre.com \
    --cc=andy@kernel.org \
    --cc=angelo.compagnucci@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=nm@ti.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.