All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Vasileios Amoiridis <vassilisamir@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	lars@metafoo.de, ang.iglesiasg@gmail.com,
	mazziesaccount@gmail.com, ak@it-klinger.de,
	petre.rodan@subdimension.ro, phil@raspberrypi.com,
	579lpy@gmail.com, linus.walleij@linaro.org,
	semen.protsenko@linaro.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/6] iio: pressure: Add triggered buffer support for BMP280 driver
Date: Sun, 24 Mar 2024 11:55:46 +0000	[thread overview]
Message-ID: <20240324115546.695d3e33@jic23-huawei> (raw)
In-Reply-To: <20240320174602.GA36450@vamoiridPC>

On Wed, 20 Mar 2024 18:46:02 +0100
Vasileios Amoiridis <vassilisamir@gmail.com> wrote:

> On Wed, Mar 20, 2024 at 01:16:03PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 19, 2024 at 01:29:25AM +0100, Vasileios Amoiridis wrote:  
> > > BMP2xx, BMP3xx, and BMP5xx use consecutive buffers for their
> > > temperature, pressure and humidity readings. This facilitates
> > > the use of burst reads in order to acquire data much faster
> > > and in a different way from the one used in oneshot captures.
> > > 
> > > BMP085 and BMP180 use a completely different measurement
> > > process that is well defined and is used in their buffer_handler().  
> > 
> > ...
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_TEMP_MSB,
> > > -			       data->buf, sizeof(data->buf));
> > > +			       data->buf, BMP280_NUM_TEMP_BYTES);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_PRESS_MSB,
> > > -			       data->buf, sizeof(data->buf));
> > > +			       data->buf, BMP280_NUM_PRESS_BYTES);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_HUMIDITY_MSB,
> > > -			       &data->be16, sizeof(data->be16));
> > > +			       &data->be16, BME280_NUM_HUMIDITY_BYTES);  
> >   
> > > -	adc_humidity = be16_to_cpu(data->be16);
> > > +	adc_humidity = get_unaligned_be16(&data->be16);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP380_REG_TEMP_XLSB,
> > > -			       data->buf, sizeof(data->buf));
> > > +			       data->buf, BMP280_NUM_TEMP_BYTES);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP380_REG_PRESS_XLSB,
> > > -			       data->buf, sizeof(data->buf));
> > > +			       data->buf, BMP280_NUM_PRESS_BYTES);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP580_REG_TEMP_XLSB, data->buf,
> > > -			       sizeof(data->buf));
> > > +			       BMP280_NUM_TEMP_BYTES);  
> >   
> > >  	ret = regmap_bulk_read(data->regmap, BMP580_REG_PRESS_XLSB, data->buf,
> > > -			       sizeof(data->buf));
> > > +			       BMP280_NUM_PRESS_BYTES);  
> > 
> > These smell to me as candidates to a separate patch with more explanation why.
> > (Yes, with the definitions you introduced.) But I leave it to Jonathan to
> > decide if we need to split.

The are somewhat confusing, though only when you start doing bulk reads
to do these makes sense - so I'm not sure how to do it as 2 patches.

Pity we don't have sizeof(be24) available.

> > 
> > ...
> > 
> > The below are applicable to the bmp280_buffer_handler(),
> > bmp380_buffer_handler() implementations as well.
> > 
> > ...
> >   
> > > +	/* Burst read data registers */
> > > +	ret = regmap_bulk_read(data->regmap, BMP580_REG_TEMP_XLSB,
> > > +			       data->buf, 6);  
> > 
> > Magic size.
> >   
> 
> Hi Andy,
> 
> Thank you again for your feedback. When I was writing it, it was 
> looking as a magic number to me as well but then I though that 
> since I put the comment above it could be obvious. Now that I see 
> it again, I think it was not a good idea and maybe some type of 
> definition like
> 
> 	#define BMP280_BURST_READ_NUM_BYTES 6
> 	#define BME280_BURST_READ_NUM_BYTES 8
I think these are sums of the other quantities.  Better to
express them as such if possible.

> 
> could look better and be more intuitive.
> 
> > ...
> >   
> > > +	/* Temperature calculations */
> > > +	memcpy(&chan_value, &data->buf[3], 3);  
> > 
> > _le24() + sign_extend32()?
> >   
> 
> In the next line from your comment the _le24 or _be24 takes place.
I think you can get that data directly rather than bouncing it via
a memcpy.
e.g.
adc_temp = FIELD_GET(BMP280_MEAS_TRIM_MASK, get_unaligned_be24(&data->buf[3]);

> If the sign_extend32() is needed here, shouldn't it also be used
> in all the oneshot captures as well?

Is this actually signed?  Compensated values are, but at this point
it's just a raw adc count.  So I'm not seeing why we'd sign extend it
(unless the device is returning a signed be24 - I haven't checked.)


> 
> > ...
> >   
> > > +	/* Pressure calculations */
> > > +	memcpy(&chan_value, &data->buf[0], 3);  
> > 
> > _le24() + sign_extend32()?
> > 
> > ...
> >   
> > >  	/*
> > > -	 * Maximum number of consecutive bytes read for a temperature or
> > > -	 * pressure measurement is 3.
> > > +	 * Maximum number of a burst read for temperature, pressure, humidity
> > > +	 * is 8 bytes.
> > >  	 */
> > > -	if (val_size > 3)
> > > +	if (val_size > 8)  
> > 
> > sizeof() / new definition for the buf[] size?
> >   
> 
> In a previous commit that I was fixing this SPI driver, Jonathan had mentioned
> that there is no need for a specific definition since it will only be used
> here so that's why I kept it as is.

Never trust me ;)  Size of the buf is sensible here.

Jonathan

> 
> Cheers,
> Vasilis
> > >  		return -EINVAL;  
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko
> > 
> >   


  parent reply	other threads:[~2024-03-24 11:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19  0:29 [PATCH v3 0/6] Series to add triggered buffer support to BMP280 driver Vasileios Amoiridis
2024-03-19  0:29 ` [PATCH v3 1/6] iio: pressure: BMP280 core driver headers sorting Vasileios Amoiridis
2024-03-20 11:00   ` Andy Shevchenko
2024-03-24 11:14     ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 2/6] iio: pressure: Introduce new cleanup routines to BMP280 driver *_raw() functions Vasileios Amoiridis
2024-03-20 11:00   ` Andy Shevchenko
2024-03-20 11:04     ` Andy Shevchenko
2024-03-24 11:20   ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 3/6] iio: pressure: Generalize read_{temp/press/humid}() functions Vasileios Amoiridis
2024-03-20 11:04   ` Andy Shevchenko
2024-03-24 11:36   ` Jonathan Cameron
2024-04-02 17:55     ` Vasileios Amoiridis
2024-04-06 10:02       ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 4/6] iio: pressure: Add SCALE and RAW values for channels Vasileios Amoiridis
2024-03-20 11:05   ` Andy Shevchenko
2024-03-19  0:29 ` [PATCH v3 5/6] iio: pressure: Add timestamp and scan_masks for BMP280 driver Vasileios Amoiridis
2024-03-20 11:07   ` Andy Shevchenko
2024-03-20 18:45     ` Vasileios Amoiridis
2024-03-20 20:38       ` Andy Shevchenko
2024-03-20 21:31         ` Vasileios Amoiridis
2024-03-21 11:22           ` Andy Shevchenko
2024-03-24 11:43   ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 6/6] iio: pressure: Add triggered buffer support " Vasileios Amoiridis
2024-03-20 11:16   ` Andy Shevchenko
2024-03-20 17:46     ` Vasileios Amoiridis
2024-03-20 21:25       ` Andy Shevchenko
2024-03-20 21:35         ` Vasileios Amoiridis
2024-03-24 11:55       ` Jonathan Cameron [this message]
2024-03-24 12:14   ` Jonathan Cameron
2024-04-02 18:08     ` Vasileios Amoiridis
2024-04-06 10:02       ` 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=20240324115546.695d3e33@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=579lpy@gmail.com \
    --cc=ak@it-klinger.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ang.iglesiasg@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=petre.rodan@subdimension.ro \
    --cc=phil@raspberrypi.com \
    --cc=semen.protsenko@linaro.org \
    --cc=vassilisamir@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 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.