Rudolf,
I've been tied up and just got back to this. Thanks much for the
"stripped down" version. It looked much like my last attempt though I'd
missed on some of the registers... I think you are right, this is
simple enough that there isn't much sense in combining the two drivers,
so I'll scrap that...
As for accuracy, the way these thermistors are implemented, the only way
to get any reasonable "accuracy" is to use as statistical approach and
look for means and trends. They just aren't accurate enough nor
responsive enough other than to give a relative approximation. However,
that really should be good enough to be alerted to problems.
I'm including the k10temp.c that I compiled into the Fedora 8 kernel
distro (2.6.24.4). I made a few minor changes to clean up warnings.
I'm also ready to generate a patch when we think this thing is ready. I
can now run a make in the kernel and all builds fine.
To test, I did as you suggested and just replaced the k8temp.c with your
new one. If anyone else wants to try, I compiled it with:
cd /usr/src/BUILD/kernel-2.6.24/linux-2.6.24.i686
make -C /lib/modules/2.6.24.4-64.fc8/build SUBDIRS=`pwd` modules
cp k8temp.ko /lib/modules/2.6.24.4-64.fc8/kernel/drivers/hwmon/
( I strongly suggest backing up k8temp.c in the source directory, and
k8temp.ko in the module path before attempting - for those trying this...)
So, running sensors now gives:
# modprobe k8temp
# sensors
it8718-isa-0228
Adapter: ISA adapter
in0: +1.07 V (min = +0.00 V, max = +4.08 V)
in1: +1.90 V (min = +0.00 V, max = +4.08 V)
in2: +3.38 V (min = +0.00 V, max = +4.08 V)
in3: +3.01 V (min = +0.00 V, max = +4.08 V)
in4: +3.01 V (min = +0.00 V, max = +4.08 V)
in5: +3.25 V (min = +0.00 V, max = +4.08 V)
in6: +4.08 V (min = +0.00 V, max = +4.08 V)
in7: +0.00 V (min = +0.00 V, max = +4.08 V)
in8: +3.07 V
fan1: 1859 RPM (min = 10 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
temp1: +39 C (low = +127 C, high = +127 C) sensor =
thermistor
temp2: +41 C (low = +127 C, high = +70 C) sensor = diode
temp3: +84 C (low = +127 C, high = +127 C) sensor =
thermistor
vid: +0.000 V
k10temp-pci-00c3
Adapter: PCI adapter
As you can see, I'm still figuring out how to configure lm_sensors for
my GA-MA790FX-DS5... However, temp1 looks ok and matches what I'm
seeing in the BIOS.
So, what do you think? Close enough for folks to give it a try?
Thanks again,
Fred Beck
Rudolf Marek wrote:
> Hi Fred,
>
> I think we can CC the list too, so others know that we work on this.
> I'm CCing some people which got interrested too.
>
>> Now I'm down to the specifics peculiar to the k10 family. I see that
>> the calculation for CurTmp is different for k10,
>> but am a bit confused on the core selection code as pertains to the
>> k10 and a bit lost in the AMD BKDG. Seems to
>> be a bit of conflict on how many sensors there are (1 vs. 4). It also
>
> I think it is just one, It might be undocumented for any other sensors.
>
>> appears that the k10 reports a relative temp rather
>> than an absolute (referenced to 49) like the k8's did.
>
> Yes the temperature is just non-physical. So to make the driver sense
> we need to know the MAX value. The thermal guide is still not
> published, but Jordan is hopefully still trying ;) There is some
> suspicion that it is 70C (TControlMAX from older processor family).
>
> I'm trying too, but now I want to get sorted some errata problems -
> k8temps are sometimes wrong. Btw all K10 processors still suffers from
> errata 319 Inaccurate Temperature Measurement
>
> Description
> The internal thermal sensor used for CurTmp (F3xA4[31:21]), hardware
> thermal control (HTC), software thermal control (STC), and the
> sideband temperature sensor interface (SB-TSI) may report inconsistent
> values.
>
>
> So question is if to go for the driver at all :/
>
>> Eventually, I was thinking that this driver should be called kxtemp,
>> or something similar and support both k8/k10.
>> There would need to be a bit more work on CPUID, but that shouldn't
>> be too difficult. Anyway, as an example, I have:
>>
>> #define TEMP_FROM_REG_K08(val) (((((val) >> 16) & 0xff) - 49) *
>> 1000)
>> #define TEMP_FROM_REG_K10(val) (((((val) >> 16) & 0xff) / 8) *
>> 1000)
>
> Hmm the reg is 0xA4 and temp is in bits 31:21 so perhaps >>16 is wrong
> too?
>
>> Haven't subscribed to lm-sensors since it appears that you are
>> basically the only one working on this. I need some guidance,
>> but am willing to help. Am an old (rusty) kernel hacker, though have
>> not played with CPU/NB registers before. Mostly
>> peripheral drivers and tcp/ip stack code tuning.
>
> Well never mind I can certainly help.
>
>> Look forward to working with you on this,
>
> Question is if we can go just for one driver, it depends on amount of
> changes.
> I'm attaching some striped down version driver, which MIGHT work.
> Quick hack, but well will see.
>
> Just replace your k8temp.c with one attached and recompile kernel. Run
> sufficiently knew 'sensors' command, maybe it will print something
> useful ;)
>
> Thanks,
> Rudolf
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: k10temp.c
Type: text/x-csrc
Size: 4488 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080418/50596f54/attachment.bin
