From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] ADT75 sensor
Date: Tue, 06 Feb 2007 15:12:04 +0000 [thread overview]
Message-ID: <20070206161204.a1b16cdc.khali@linux-fr.org> (raw)
In-Reply-To: <15533071.11811170705037131.JavaMail.root@jupiler.digium.com>
Hi Doug,
On Mon, 5 Feb 2007 13:50:37 -0600 (CST), Doug Bailey wrote:
> I am writing an interface for a Analog Devices ADT75 using
> a uClinux distribution for the blackfin processor. I want
> to use the HWMON interface to do this.
>
> The distribution does not specifically have an ADT75 sensor
> but does have a LM75 sensor. Unfortunately, the addition of
> the one-shot register in the ADT75 causes the LM75_detect
> portion of the driver to fail. In addition the temp
> precision is different on the ADT75 from the LM75.
Can you please provide the output of i2cdump for your ADT75 chip in
both byte and word modes?
> I don't see on your web site that anyone has already
> generated an ADT75 driver. Therefore I made the relatively
> simple modifications to make the LM75 into an ADT75. In
> doing this I have run into a couple of issues:
>
> - My problems come in that I do not have an i2c ID for the
> driver (There is no I2C_DRIVERID_ADT75.) Is there a way of
> getting one of these defined?
You really don't want to write a new driver. Insead you want to add
support for the ADT75 to the lm75 driver, so you don't need any driver
id. That way we avoid code duplication.
> - I would like to access a couple of the ADT75 registers through
> sysfs that currently do not have defined interfaces. (Most notably
> the one shot register and the fault queue registers.) Is there
> some guideline on how these should be defined?
Using the one-shot mode doesn't fit in the hwmon subsystem very well.
What interface would you like to offer exactly? My fear is that people
will start reporting to us that "it doesn't work" because applications
expect the sensor values to be updated in real time. Also, continuous
monitoring allows the alarm output to be triggered even if no
application is reading the value.
As for the fault queue, we do not have a standard for it, I tend to
believe that the BIOS should be setting it if needed. I've never seen
it useful in practice.
--
Jean Delvare
prev parent reply other threads:[~2007-02-06 15:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-05 19:50 [lm-sensors] ADT75 sensor Doug Bailey
2007-02-06 15:12 ` Jean Delvare [this message]
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=20070206161204.a1b16cdc.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=lm-sensors@vger.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.