From: Jonathan Cameron <jic23@kernel.org>
To: Matt Ranostay <mranostay@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Cc: "Marek Vašut" <marex@denx.de>
Subject: Re: RFC: humidity sensor heaters
Date: Sat, 22 Aug 2015 18:44:49 +0100 [thread overview]
Message-ID: <55D8B511.3060000@kernel.org> (raw)
In-Reply-To: <CAKzfze9RxmqD1KgewziH=-xWkfr31P7WNUyM707swMx1RCWgfA@mail.gmail.com>
On 21/08/15 04:56, Matt Ranostay wrote:
> Jonathan et all,
>
> So I am currently working on a driver for the TI HDC100x series of
> temp + humidity sensors, and have a question on how we should handler
> the heater functionality.
>
> This seems quite common in high accuracy relative humidity sensors to
> have a resistive element within the sensor to heat up the device and
> get rid of any condensation that happens in a high humidity
> environment.
>
> Now it could be a one off sysfs entry within the driver like
> "heater_status" but it seems something we want to more generic since
> this will be an issue in the future (aka si7005 driver for instance).
There are a few humidity sensors in hwmon (predate IIO and at least
one is my fault :) sht15 for example has heater_enable
Hmm. I wonder if we need something generic enough to account for
heaters that will run at various levels? Or current output or similar?
Perhaps we even treat it as an output channel.
out_current_heater_raw and
out_current_heater_raw_available with 0 and 1 for example
If we have info on the actual current then provide scale as well.
For the hdc1000 it would be 7.6
Does that work whilst remaining as generic as possible?
It does seem a little over the top, but does fit within standard interfaces
be it making good use of an extended name.
Jonathan
>
> Thoughts? Comments?
>
> Thanks,
>
> Matt
>
next prev parent reply other threads:[~2015-08-22 17:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 3:56 RFC: humidity sensor heaters Matt Ranostay
2015-08-22 17:44 ` Jonathan Cameron [this message]
2015-08-23 7:29 ` Matt Ranostay
2015-08-23 15:55 ` 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=55D8B511.3060000@kernel.org \
--to=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=mranostay@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 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).