From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Date: Tue, 24 Nov 2009 14:09:57 +0000 Subject: Re: [lm-sensors] [PATCH v3] k10temp: temperature sensor for AMD Message-Id: <4B0BE935.1050708@ladisch.de> List-Id: References: <4AF91F70.10106@ladisch.de> <4B06501B.8080509@ladisch.de> <87ws1l5wcl.fsf@depni.sinp.msu.ru> <4B0673D7.5010006@ladisch.de> <20091120123016.19d98ab4@hyperion.delvare> <4B068402.7020606@ladisch.de> <20091120131855.7f8f8722@hyperion.delvare> <4B0A3DB6.9090703@ladisch.de> <20091123145154.5b2b5735@hyperion.delvare> <4B0AAA55.3040702@ladisch.de> <20091123200527.1114cbc2@hyperion.delvare> <4B0B9CB1.3090808@ladisch.de> <20091124142654.76f4d166@hyperion.delvare> In-Reply-To: <20091124142654.76f4d166@hyperion.delvare> MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 To: Jean Delvare Cc: Serge Belyshev , linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org SmVhbiBEZWx2YXJlIHdyb3RlOgo+IE9uIFR1ZSwgMjQgTm92IDIwMDkgMDk6NDM6MjkgKzAxMDAs IENsZW1lbnMgTGFkaXNjaCB3cm90ZToKPiA+IEluIGFueSBjYXNlLCBpdCBtaWdodCBtYWtlIG1v cmUgc2Vuc2UgdG8gc2hvdyBzdWNoIHZhbHVlcyBhcyBzb21ldGhpbmcKPiA+IGxpa2UgIjIwIMKw QyBiZWxvdyBtYXhpbXVtIi4KPiAKPiBJIHRoaW5rIHNvLCB5ZXMuIE5vdyB0aGUgZGlmZmljdWx0 eSBpcyB0byBjb21lIHVwIHdpdGggYSBzdWl0YWJsZSBzeXNmcwo+IGludGVyZmFjZS4gRHJvcHBp bmcgdGhlIGN1cnJlbnQgaW50ZXJmYWNlIGFsdG9nZXRoZXIgZG9lc24ndCBzb3VuZAo+IHJpZ2h0 IGFzIGl0IHdpbGwgdGFrZSB0aW1lIGJlZm9yZSBhIG5ldyB2ZXJzaW9uIG9mIGxpYnNlbnNvcnMg aXMKPiB3cml0dGVuIGFuZCBzcHJlYWQgb3V0IGFuZCBhbGwgYXBwbGljYXRpb25zIGFkZCBzdXBw b3J0IGZvciB0aGUgbmV3Cj4gaW50ZXJmYWNlLiBJbiB0aGUgbWVhbnRpbWUsIEkgZ3Vlc3Mgd2Ug d2FudCB1c2VycyB0byBzdGlsbCBzZWUgdGhlCj4gYXBwcm94aW1hdGUgdmFsdWUuCgprMTB0ZW1w IGlzIGEgbmV3IGRyaXZlciwgc28gbm8gb2xkIHN5c3RlbXMgd291bGQgYnJlYWsgaWYgaXQgaW50 cm9kdWNlZAphIG5ldyBjbGFzcyBvZiBtZWFzdXJlbWVudHMgd2l0aCBuYW1lcyBsaWtlLCBlLmcu LCByZWx0ZW1wI18qLgpXZSBjb3VsZCBhZGQgdGhpcyBpbiBwYXJhbGxlbCB3aXRoIHRoZSBvbGQg aW50ZXJmYWNlLiAgSWYgd2Ugd2FudGVkIHRvLgoKPiBTbyBpZGVhbGx5IHdlIHdvdWxkIGNvbWUg dXAgd2l0aCBhbiBpbnRlcmZhY2UgdGhhdCBhZGRzIHVwIHRvIHRoZSBvbmUKPiB3ZSBoYXZlIGN1 cnJlbnRseS4gRnV0dXJlIGxpYnNlbnNvcnMvYXBwbGljYXRpb25zIGNvdWxkIHJlYWQgdGhlIGV4 dHJhCj4gaW5mb3JtYXRpb24gdG8gZGlzcGxheSB0aGUgdmFsdWUgaW4gYSBkaWZmZXJlbnQgZm9y bWF0IHNvIHRoYXQgdGhlCj4gdXNlcnMgc2VlIHRoZSBkaWZmZXJlbmNlLgo+IAo+IEFuIGlkZWEg SSBoYXZlIGFib3V0IHRoaXMgaXMgYWRkaW5nIGEgc3lzZnMgZmlsZSB0ZW1wI19yZWxhdGl2ZSwg d2hpY2gKPiB3b3VsZCBjb250YWluIHRoZSBmYWtlIHRlbXBlcmF0dXJlIHZhbHVlIHRoYXQgaXMg dXNlZCBhcyBhIHJlZmVyZW5jZQo+IGZvciB0aGUgdGhlcm1hbCBzZW5zb3IgaW4gcXVlc3Rpb24u IEluIHRoZSBjYXNlIG9mIGsxMHRlbXAsIHRoZSB2YWx1ZQo+IHdvdWxkIGJlIDcwMDAwLiBTbyBm b3IgZXhhbXBsZSB3ZSB3b3VsZCBoYXZlOgo+IAo+IHRlbXAxX2lucHV0OiA0NjAwMAo+IHRlbXAx X3JlbGF0aXZlOiA3MDAwMAo+IAo+IE9sZCBhcHBsaWNhdGlvbnMgd291bGQgZGlzcGxheSB0aGlz IGFzIDQ2wrBDIHdoaWxlIG5ldyBvbmVzIHdvdWxkCj4gZGlzcGxheSAiMjTCsEMgYmVsb3cgdGhl IGxpbWl0Ii4KCkluIHRoaXMgY2FzZSwgdGVtcDFfcmVsYXRpdmUgaXMgaWRlbnRpY2FsIHdpdGgg dGVtcDFfbWF4LiAgSW4gdGhlCmdlbmVyYWwgY2FzZSwgdGhlcmUgYWx3YXlzIG11c3QgYmUgc29t ZSBraW5kIG9mIGxpbWl0ICh3aGV0aGVyICJtYXgiIG9yCiJjcml0IiBvciBzb21ldGhpbmcgZWxz ZSkgYWdhaW5zdCB3aGljaCB0aGUgdmFsdWVzIGFyZSBtZWFzdXJlZCwKb3RoZXJ3aXNlIGEgcmVs YXRpdmUgdmFsdWUgd291bGQgbm90IG1ha2Ugc2Vuc2UuCgpUaGlzIG1lYW5zIHRoYXQgb25lIG9m IHRoZSBhbHJlYWR5IGV4aXN0aW5nIGxpbWl0IHZhbHVlcyBtdXN0IGJlIHRoZQpyZWZlcmVuY2Ug YmFzZSwgc28gd2UnZCBuZWVkIGp1c3QgYSBtZWNoYW5pc20gdG8gc3BlY2lmeSB3aGljaCBvZiB0 aGVtCmlzIGl0LCBpLmUuLCAidGVtcDFfcmVsYXRpdmVfYmFzZTogbWF4Ii4gIElmIHdlJ2QgaGF2 ZQoidGVtcDFfcmVsYXRpdmU6IDcwMDAwIiwgdGhlIGFwcGxpY2F0aW9uIHdvdWxkIGhhdmUgdG8g c2VhcmNoIGFtb25nIHRoZQpsaW1pdCB2YWx1ZXMgZm9yIG9uZSB3aXRoIHRoZSBzYW1lIHZhbHVl LgoKKEl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB3aGljaCBvbmUgaXMgdGhlIGJhc2UsIGFzIGFs bCB2YWx1ZXMgYXJlCnJlbGF0aXZlIGFueXdheSwgc28gd2UgY291bGQganVzdCBkZWZpbmUgdGhh dCB0ZW1wI19tYXggaXMgdGhlIGJhc2U7CnNvIHdlJ2QgaGF2ZSAidGVtcDFfcmVsYXRpdmU6IHRy dWUiKS4KCj4gSXQgbWF5IG5vdCBiZSBjb25zaWRlcmVkIGZsZXhpYmxlIGVub3VnaCB0aG91Z2gu Li4gRm9yIGV4YW1wbGUgaXQgZG9lcwo+IG5vdCBzdXBwb3J0IHNlbnNvcnMgd2l0aCB0b3RhbGx5 IGFyYml0cmFyeSBzY2FsZXMgKHdoZXJlIDEwMDAgIT0gMcKwQy4pCgpXaGVuIHRoZSBzY2FsZSBk aWZmZXJzIGJ1dCBpcyBfa25vd25fLCB0aGUgZHJpdmVyIGNhbiBqdXN0IHJlc2NhbGUgaXRzCmlu dGVybmFsIHJlZ2lzdGVyIHZhbHVlcyB0byBtaWxsaWRlZ3JlZXMuCgpXaGVuIHdlIGhhdmUgc29t ZSBzY2FsZSBsaWtlICIwJS4uLjEwMCUiLCB0aGF0IHNob3VsZCBwcm9iYWJseSBiZQpleHBvcnRl ZCBhcyAicHdtI190YXJnZXQiIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuCgoKQmVzdCByZWdhcmRz LApDbGVtZW5zCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6 Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933031AbZKXOJz (ORCPT ); Tue, 24 Nov 2009 09:09:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932972AbZKXOJz (ORCPT ); Tue, 24 Nov 2009 09:09:55 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]:56332 "EHLO out4.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932956AbZKXOJy (ORCPT ); Tue, 24 Nov 2009 09:09:54 -0500 X-Sasl-enc: I26wPUrqQ74XMPVtIIN6YOohmygWdSbAWu8WyZsqgH20 1259071799 Message-ID: <4B0BE935.1050708@ladisch.de> Date: Tue, 24 Nov 2009 15:09:57 +0100 From: Clemens Ladisch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jean Delvare CC: Serge Belyshev , linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs References: <4AF91F70.10106@ladisch.de> <4B06501B.8080509@ladisch.de> <87ws1l5wcl.fsf@depni.sinp.msu.ru> <4B0673D7.5010006@ladisch.de> <20091120123016.19d98ab4@hyperion.delvare> <4B068402.7020606@ladisch.de> <20091120131855.7f8f8722@hyperion.delvare> <4B0A3DB6.9090703@ladisch.de> <20091123145154.5b2b5735@hyperion.delvare> <4B0AAA55.3040702@ladisch.de> <20091123200527.1114cbc2@hyperion.delvare> <4B0B9CB1.3090808@ladisch.de> <20091124142654.76f4d166@hyperion.delvare> In-Reply-To: <20091124142654.76f4d166@hyperion.delvare> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jean Delvare wrote: > On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote: > > 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. k10temp is a new driver, so no old systems would break if it introduced a new class of measurements with names like, e.g., reltemp#_*. We could add this in parallel with the old interface. If we wanted to. > 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". In this case, temp1_relative is identical with temp1_max. In the general case, there always must be some kind of limit (whether "max" or "crit" or something else) against which the values are measured, otherwise a relative value would not make sense. This means that one of the already existing limit values must be the reference base, so we'd need just a mechanism to specify which of them is it, i.e., "temp1_relative_base: max". If we'd have "temp1_relative: 70000", the application would have to search among the limit values for one with the same value. (It doesn't really matter which one is the base, as all values are relative anyway, so we could just define that temp#_max is the base; so we'd have "temp1_relative: true"). > It may not be considered flexible enough though... For example it does > not support sensors with totally arbitrary scales (where 1000 != 1°C.) When the scale differs but is _known_, the driver can just rescale its internal register values to millidegrees. When we have some scale like "0%...100%", that should probably be exported as "pwm#_target" or something like that. Best regards, Clemens