public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasileios Amoiridis <vassilisamir@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: lars@metafoo.de, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, anshulusr@gmail.com, gustavograzs@gmail.com,
	andriy.shevchenko@linux.intel.com, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 09/13] iio: chemical: bme680: Move ambient temperature to attributes
Date: Sat, 19 Oct 2024 19:58:56 +0200	[thread overview]
Message-ID: <ZxPzYNP7IXkWw_Hd@vamoirid-laptop> (raw)
In-Reply-To: <ZxPxpD8gtikOxzOe@vamoirid-laptop>

On Sat, Oct 19, 2024 at 07:51:32PM +0200, Vasileios Amoiridis wrote:
> On Sat, Oct 19, 2024 at 02:59:25PM +0100, Jonathan Cameron wrote:
> > On Mon, 14 Oct 2024 22:14:23 +0200
> > Vasileios Amoiridis <vassilisamir@gmail.com> wrote:
> > 
> > > On Sat, Oct 12, 2024 at 01:01:24PM +0100, Jonathan Cameron wrote:
> > > > On Thu, 10 Oct 2024 23:00:26 +0200
> > > > vamoirid <vassilisamir@gmail.com> wrote:
> > > >   
> > > > > From: Vasileios Amoiridis <vassilisamir@gmail.com>
> > > > > 
> > > > > Remove the ambient temperature from being a macro and implement it as
> > > > > an attribute. This way, it is possible to dynamically configure the
> > > > > ambient temperature of the environment to improve the accuracy of the
> > > > > measurements.
> > > > > 
> > > > > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>  
> > > > New ABI? Would need docs.
> > > > 
> > > > However, I 'think' we have a few cases where we handle this via the slightly
> > > > odd interface of out_temp_processed / _raw with a label saying it's
> > > > ambient temperature.
> > > > 
> > > > The tenuous argument is that we have heaters that actually control the
> > > > temperature and the affect of either heating the thing or just happening
> > > > to know the external temperature ends up being the same. Hence use
> > > > an output channel for this control.
> > > > 
> > > > Jonathan  
> > > 
> > > Hi Jonathan,
> > > 
> > > Thanks for taking the time to review this. I saw your previous messages,
> > > and I am not responding to all of them so as to not flood you with ACK
> > > messages.
> > > 
> > > For this one though I have to ask. The last commit of this series is
> > > adding support for an output current channel that controls the current
> > > that is being inserted into an internal plate that is heated up in order
> > > to have more precise acquisition of humidity and gas measurement. Does
> > > it makes sense to add an ambient temp output channel as well?
> > 
> > If we need to know that temperature to calculate the meaning of the pressure
> > channels then I think it does.
> > 
> > I am a little confused though as this device measures the temperature.
> > Why isn't that the right value to use?  Is that because the heater
> > is confusing things?
> > 
> >
> 
> Hi Jonathan,
> 
> Thank you very much for your message! So, I digged a bit more into the
> device datasheet and I found out that the ambient temperature can
> actually be taken directly from the measured temperature (p.22 of [1]),
> I can use this one. This means, that the ambient temp can be fully
> dropped since the temperature of the sensor is the information we need.
> Is it ok to drop it fully since it is an ABI change? If not how should I
> approach this?
> 

Actually in the end, no ABI change because the temperature will be
taken from the internal measurement so nothing that has to do with
userspace so there is no ABI change here, my mistake!

Vasilis

> Another thing that I had missed because of the way the code was written
> is that actually we can (and should) use output channel for setting the
> temperature of the internal heater plate. This sensor essentially has an
> internal heater plate that allows it to measure the VOC. Currently if
> you check the driver [2], the value of the requested temperature of the
> heater is set only once in the probe function and stays all the time
> like this. This doesn't allow for much flexibility. But it is something
> that I will do in another series and not this one, since this one is
> already quite heavy.
> 
> Cheers,
> Vasilis
> 
> PS: I don't understand why Bosch designed the sensor in this way. Since
> the value of the ambient temp can be either hardcoded or the actual
> value of the temperature sensor, they could have had all this logic in
> hardware. They could actually even implement the compensation functions
> in hardware and just return RAW values to us. It's kind of the same
> situation with the BME280 and BMP{1,2,3,5}80 drivers that we have.
> 
> [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf
> [2]: https://elixir.bootlin.com/linux/v6.11.4/source/drivers/iio/chemical/bme680_core.c#L989
> > > 
> > > Cheers,
> > > Vasilis
> > > 
> >

  reply	other threads:[~2024-10-19 17:59 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 21:00 [PATCH v1 00/13]: chemical: bme680: 2nd set of clean and add vamoirid
2024-10-10 21:00 ` [PATCH v1 01/13] iio: chemical: bme680: Fix indentation and unnecessary spaces vamoirid
2024-10-11  9:55   ` Andy Shevchenko
2024-10-11 18:45     ` Vasileios Aoiridis
2024-10-10 21:00 ` [PATCH v1 02/13] iio: chemical: bme680: avoid using camel case vamoirid
2024-10-11 10:00   ` Andy Shevchenko
2024-10-11 18:50     ` Vasileios Aoiridis
2024-10-12 20:34       ` Andy Shevchenko
2024-10-10 21:00 ` [PATCH v1 03/13] iio: chemical: bme680: fix startup time vamoirid
2024-10-11 10:00   ` Andy Shevchenko
2024-10-11 18:51     ` Vasileios Aoiridis
2024-10-12 11:45       ` Jonathan Cameron
2024-10-12 20:36       ` Andy Shevchenko
2024-10-10 21:00 ` [PATCH v1 04/13] iio: chemical: bme680: move to fsleep() vamoirid
2024-10-10 21:00 ` [PATCH v1 05/13] iio: chemical: bme680: refactorize set_mode() mode vamoirid
2024-10-11 10:02   ` Andy Shevchenko
2024-10-11 18:53     ` Vasileios Aoiridis
2024-10-12 11:48   ` Jonathan Cameron
2024-10-10 21:00 ` [PATCH v1 06/13] dt-bindings: iio: add binding for BME680 driver vamoirid
2024-10-11  3:11   ` Rob Herring (Arm)
2024-10-11  6:51   ` Krzysztof Kozlowski
2024-10-11 18:44     ` Vasileios Aoiridis
2024-10-12 11:49       ` Jonathan Cameron
2024-10-10 21:00 ` [PATCH v1 07/13] iio: chemical: bme680: add regulators vamoirid
2024-10-11 10:05   ` Andy Shevchenko
2024-10-11 18:55     ` Vasileios Aoiridis
2024-10-12 11:53   ` Jonathan Cameron
2024-10-10 21:00 ` [PATCH v1 08/13] iio: chemical: bme680: add power management vamoirid
2024-10-11 10:10   ` Andy Shevchenko
2024-10-11 19:02     ` Vasileios Aoiridis
2024-10-12 11:58       ` Jonathan Cameron
2024-10-12 20:40       ` Andy Shevchenko
2024-10-10 21:00 ` [PATCH v1 09/13] iio: chemical: bme680: Move ambient temperature to attributes vamoirid
2024-10-11 10:12   ` Andy Shevchenko
2024-10-11 19:03     ` Vasileios Aoiridis
2024-10-12 12:01   ` Jonathan Cameron
2024-10-14 20:14     ` Vasileios Amoiridis
2024-10-19 13:59       ` Jonathan Cameron
2024-10-19 17:51         ` Vasileios Amoiridis
2024-10-19 17:58           ` Vasileios Amoiridis [this message]
2024-10-10 21:00 ` [PATCH v1 10/13] iio: chemical: bme680: generalize read_*() functions vamoirid
2024-10-10 21:00 ` [PATCH v1 11/13] iio: chemical: bme680: Add SCALE and RAW channels vamoirid
2024-10-10 21:00 ` [PATCH v1 12/13] iio: chemical: bme680: Add triggered buffer support vamoirid
2024-10-11 10:37   ` Andy Shevchenko
2024-10-11 19:07     ` Vasileios Aoiridis
2024-10-12 12:04       ` Jonathan Cameron
2024-10-12 12:09         ` Jonathan Cameron
2024-10-10 21:00 ` [PATCH v1 13/13] iio: chemical: bme680: Add support for preheat current vamoirid
2024-10-11 10:39   ` Andy Shevchenko
2024-10-11 19:08     ` Vasileios Aoiridis
2024-10-12 20:47       ` Andy Shevchenko
2024-10-12 12:36   ` Jonathan Cameron
2024-10-11 10:42 ` [PATCH v1 00/13]: chemical: bme680: 2nd set of clean and add Andy Shevchenko
2024-10-11 18:39   ` Vasileios Aoiridis

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=ZxPzYNP7IXkWw_Hd@vamoirid-laptop \
    --to=vassilisamir@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anshulusr@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gustavograzs@gmail.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox