From: jim.cromie@gmail.com (Jim Cromie)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [PATCH] f75383 /f75384 driver
Date: Sun, 20 Aug 2006 18:16:46 +0000 [thread overview]
Message-ID: <44E8A70E.6090102@gmail.com> (raw)
In-Reply-To: <1155997256.19938.6.camel@rapsure.rapsure.net>
Brian Beardall wrote:
> On Sat, 2006-08-19 at 14:49 -0600, Jim Cromie wrote:
>
>> Brian Beardall wrote:
>>
>>
>>> and so they can be handled with one code execution line. Is there
>>> a dev in lm_sensors to allow the change in read frequencies?
>>>
>>>
>> Im not sure what you mean here.
>> Do you want some sensor reads to fetch *fresher* data than others ?
>>
>>
>>>>> + struct f75383_data *data = f75383_update_device(dev);
>>>>>
>>>>>
>> you could add a 2nd param to your update-device, allowing caller to
>> indicate desired freshness.
>> or you could carve update_device for separate sensors, and fetch each
>>
>> separately.
>>
> The entire device reads the temperature sensors depending on a a
> register value. So I can make in read at different Hz, or I can also
> make it only update when a call is made to the device. However I have it
> setup for 15Hz update right now.
>
I still dont get what youre after - theres no question here.
IIUC, the standard usage of lm-sensor kernel modules is to support
user-demanded queries,
such as those done by a user-space daemon.
In this context, why does your driver have/need 15hz anything
- is it 'scanning' its own inputs, looking for out-of-range values ?
It seems easy to expose the Freq as a mod-param,
which is then controllable at runtime via /proc/sys/<something> (IIRC)
but Im unclear on what its for.
>>
>>>> hth
>>>> jimc
>>>>
>>>>
>>>
>>>
>
>
>
prev parent reply other threads:[~2006-08-20 18:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-19 14:20 [lm-sensors] [PATCH] f75383 /f75384 driver Brian Beardall
2006-08-19 15:04 ` Jim Cromie
2006-08-19 20:02 ` Brian Beardall
2006-08-19 20:49 ` Jim Cromie
2006-08-20 1:27 ` Brian Beardall
2006-08-20 18:16 ` Jim Cromie [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=44E8A70E.6090102@gmail.com \
--to=jim.cromie@gmail.com \
--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.