Hello all, I think I put all parties up in CC. Thanks to Andreas, I have received missing information about the TControlMax temperature. It means we can get further to a new driver. I did some experimental driver which works fine (attached as k8temp.c) Kryzstof Went even further and made changes to original k8temp driver. I will go for vacation soonish (middle of next week) and I'm very busy, but at least we can start. I will write a short list of things which needs to be discussed in the meanwhile: 1) driver name AMD proposes the change to amdtemp (from k8temp) I think we can merge the drivers together, it should be still simple. Jean, please do you remember how autoloading/driver name change is handled in the kernel? I have some feeling that it should be simple to handle. Please confirm. The name change can be done if we know that old name will work, so we dont break too much things around. 2) Maximum temperature. The new Phenom temperature is non-physical it means we must know the limit so we know when we cross it. Therefore our new driver must export either temp1_max or temp1_crit. The TcontrolMax is for all fam 10h CPUs 70 degrees. The Intel driver has temp1_max as maximum temperature from which all fans must start cooling. The temp1_crit is when the CPU will fail. I think the thremtrip_l is asserted for much higher temperatures, I think we can go for temp1_max. We can put the TcontrolMax into a variable, because for future revisions we may need cpuid to put there right value. 3) Errata #319 I think all CPU revisions still may have problem with the temp sensor inside the CPU (not the diode interface which is analog and works fine). Please can someone test mine k8temp.c attached, and report back the values you got? If we detect a CPU with the errata we should print a warning to syslog. 4) Kryzstof driver. Kryzstof already posted to me some changes for driver merger. Please can you repost them in form of patch here to mailing list? Please avoid white space changes. AMD suggest to call K10 fam10 because it is in fact family 10h and not K10. From CPUID perspective it is more model then family to make it worse ;) 5) merged driver architecture For the different code conditions I would propose some amdfam variable with model code (0xe) 0xf 0x10 and some if data->amdfam = FAM_E ... Now the neat trick how the PCI driver teach about CPUID. There is a register with CPUID inside function 3 (offset FC), we can read the CPUID from there, and get the model for 10h and fh model eh and older do not have this register. We cannot use cpuid_eax, because we may have two processors with different erratas and we need to know which is which PCI device. The old K8temp driver simply ignored this - the module code may be executed on different CPU other then PCI device we are operating on (multi CPU system not multicore). Therefore we can do: 1) for PCI ID of "old" family put amdfam with 0xf 2) for new fill 10h and save CPUID from the register FC 3) check the errata, print warning 4) future versions may need the cpuid info for different TcontolMax 5) for fam10 create new get temps funs, new formula 6) enhancements for older k8temp this should be done in separate patch. 6a) print warning about sensors inaccurancy for all model 0xf 6b) extend scale to .00 .25 .50 .75 6c) the automatic core detecting may detect single core cpu which were in fact dualcore but with disabled core. Typically the second core has -49. For some reason it gets printed on mine sempron G2 fam 0fh Of course this are just mine ideas, feel free to come with even better ideas ;) The code is very welcomed too, I can try to at least review it when I will have some free time. I can code this too but free time window is two/three weeks far. Thanks, Rudolf -------------- next part -------------- A non-text attachment was scrubbed... Name: k8temp.c Type: text/x-csrc Size: 4652 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080718/d51be536/attachment.bin
