lkml.org 
[lkml]   [2009]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs
    On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:
    > Jean Delvare wrote:
    > > On Mon, 23 Nov 2009 16:29:25 +0100, Clemens Ladisch wrote:
    > > > There still is the built-in diode to be read by the motherboard, but the
    > > > internal sensor was never intended to be an absolute measurement but
    > > > just as a means for controlling the cooling.
    > >
    > > Still we use it for that purpose at the moment. Maybe we simply should
    > > not?
    >
    > Well, the absolute measurements have essentially the same purpose, and
    > would not make much sense without comparing them to some absolute limit.

    Of course. The problem is that users don't know that the temperature
    isn't real, and then get puzzled when comparing with other temperature
    sensors in their system, which _do_ report physical temperatures.

    > In any case, it might make more sense to show such values as something
    > like "20 °C below maximum".

    I think so, yes. Now the difficulty is to come up with a suitable sysfs
    interface. Dropping the current interface altogether doesn't sound
    right as it will take time before a new version of libsensors is
    written and spread out and all applications add support for the new
    interface. In the meantime, I guess we want users to still see the
    approximate value.

    So ideally we would come up with an interface that adds up to the one
    we have currently. Future libsensors/applications could read the extra
    information to display the value in a different format so that the
    users see the difference.

    An idea I have about this is adding a sysfs file temp#_relative, which
    would contain the fake temperature value that is used as a reference
    for the thermal sensor in question. In the case of k10temp, the value
    would be 70000. So for example we would have:

    temp1_input: 46000
    temp1_relative: 70000

    Old applications would display this as 46°C while new ones would
    display "24°C below the limit". For coretemp this could be 85000 or
    100000 (at least in the case where we don't know the limit for sure.)

    If there are limits exported (temp1_max, temp1_crit etc.) the same
    offset could be applied to them too.

    This approach has the advantage of backwards compatibility. It may not
    be considered flexible enough though... For example it does not support
    sensors with totally arbitrary scales (where 1000 != 1°C.) I seem to
    remember we've seen this in the past?

    If others have ideas about how we can support this, I'm all ears.

    --
    Jean Delvare
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-11-24 14:29    [W:3.266 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site