#
355562 |
|
09-Dec-2019 |
mav |
MFC r350624 (by cem): amdtemp(4), amdsmn(4): Attach to Ryzen 3 (Zen 2) hostbridges
PR: 239607
|
#
343325 |
|
22-Jan-2019 |
mav |
MFC r342977 (by cem): amdtemp(4): Add support for Family 15h, Model >=60h
Family 15h is a bit of an oddball. Early models used the same temperature register and spec (mostly[1]) as earlier CPU families.
Model 60h-6Fh and 70-7Fh use something more like Family 17h's Service Management Network, communicating with it in a similar fashion. To support them, add support for their version of SMU indirection to amdsmn(4) and use it in amdtemp(4) on these models.
While here, clarify some of the deviceid macros in amdtemp(4) that were added with arbitrary, incorrect family numbers, and remove ones that were not used. Additionally, clarify intent and condition of heterogenous multi-socket system detection.
[1]: 15h adds the "adjust range by -49°C if a certain condition is met," which previous families did not have.
Reported by: D. C. <tjoard AT gmail.com> PR: 234657 Tested by: D. C. <tjoard AT gmail.com>
|
#
343324 |
|
22-Jan-2019 |
mav |
MFC r340426 (by cem): amdtemp(4): Fix temperature reporting on AMD 2990WX
Update the AMD family 17h temperature reporting based on AMD Tech Doc 56255 OSRR, section 4.2.1.
For CPUS w/CUR_TEMP_RANGE_SEL set, scale the reported temperature into the range -49..206; i.e., subtract 49°C.
Submitted by: gallatin@ Reported by: bcran@
|
#
343323 |
|
22-Jan-2019 |
mav |
MFC r340425 (by cem): amdsmn(4)/amdtemp(4): Attach to Ryzen 2 hostbridges
As reported, tested, and patch supplied by Johannes.
There may be future work to do to support multiple sensors, but for now, any sensor at all is a strict improvement for Ryzen 2 systems.
PR: 228480 Submitted by: Johannes Lundberg <johalun0 AT gmail.com> (earlier version) Reported by: deischen@, Johannes, and numerous others
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
329767 |
|
22-Feb-2018 |
truckman |
MFC r323067, r323184, r323185, r323195, r323196 (by cem)
------------------------------------------------------------------------ r323067 | cem | 2017-08-31 11:39:18 -0700 (Thu, 31 Aug 2017) | 4 lines
amdtemp.4: Update BKDG URL to current location
Sponsored by: Dell EMC Isilon
------------------------------------------------------------------------ r323184 | cem | 2017-09-05 08:13:41 -0700 (Tue, 05 Sep 2017) | 10 lines
Add smn(4) driver for AMD System Management Network
AMD Family 17h CPUs have an internal network used to communicate between the host CPU and the PSP and SMU coprocessors. It exposes a simple 32-bit register space.
Reviewed by: avg (no +1), mjoras, truckman Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12217
------------------------------------------------------------------------ r323185 | cem | 2017-09-05 08:19:14 -0700 (Tue, 05 Sep 2017) | 13 lines
amdtemp(4): Add support for Family 17h temperature sensor
The sensor value is formatted similarly to previous models (same bitfield sizes, same units), but must be read off of the internal System Management Network (SMN) from the System Management Unit (SMU) co-processor.
PR: 218264 Reported and tested by: Nils Beyer <nbe AT renzel.net> Reviewed by: avg (no +1), mjoras, truckman Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12217
------------------------------------------------------------------------ r323195 | cem | 2017-09-05 13:35:25 -0700 (Tue, 05 Sep 2017) | 8 lines
amdtemp(4): Do not probe not matching hostbridges
Some systems have hostbs that do not match our PCI device id criteria. Detect and ignore these devices in probe.
PR: 218264 Sponsored by: Dell EMC Isilon
------------------------------------------------------------------------ r323196 | cem | 2017-09-05 14:00:33 -0700 (Tue, 05 Sep 2017) | 8 lines
amdsmn(4): Do not probe not matching hostbridges
Similar to r323195, but for amdsmn(4) driver (which borrowed some design).
Ignore hostbs that do not match our PCI device id criteria.
Sponsored by: Dell EMC Isilon
PR: 218264 Differential Revision: https://reviews.freebsd.org/D12217
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
300421 |
|
22-May-2016 |
loos |
Fix the deciKelvin to Celsius conversion in kernel.
After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C reference and as result, the temperature read in sysctl(8) now exibits a +0.1C difference.
This commit fix the kernel references to match the reference value used in sysctl(8) after r285994.
Sponsored by: Rubicon Communications (Netgate)
|
#
298270 |
|
19-Apr-2016 |
loos |
Add PCI ID for family 10h model 30h to amdtemp(4).
This adds support to CPU found in PC Engines APU2 series.
MFC after: 3 weeks Sponsored by: Rubicon Communications (Netgate)
|
#
273034 |
|
13-Oct-2014 |
brueffer |
Add one more AMD Kaveri APU device ID.
Submitted by: Remy Nonnenmacher <remy.nonnenmacher@activnetworks.com> MFC after: 1 week
|
#
263169 |
|
14-Mar-2014 |
brueffer |
Add support for AMD Family 16h (Kabini) sensor devices.
PR: 186587 Submitted by: David Rufino <david.rufino at gmail.com> MFC after: 2 weeks
|
#
254924 |
|
26-Aug-2013 |
jmg |
Add support for my: CPU: AMD A10-5700 APU with Radeon(tm) HD Graphics (3393.89-MHz K8-class CPU)
|
#
246128 |
|
30-Jan-2013 |
sbz |
Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays
Reviewed by: cognet Approved by: cognet
|
#
241885 |
|
22-Oct-2012 |
eadler |
This isn't functionally identical. In some cases a hint to disable unit 0 would in fact disable all units.
This reverts r241856
Approved by: cperciva (implicit)
|
#
241856 |
|
22-Oct-2012 |
eadler |
Now that device disabling is generic, remove extraneous code from the device drivers that used to provide this feature.
Reviewed by: des Approved by: cperciva MFC after: 1 week
|
#
232090 |
|
23-Feb-2012 |
jkim |
- Add support for Family 12h, 14h and 15h processors. - Remove all attempts to guess physical temperature using DiodeOffset. There are too many reports that it varies wildly depending on motherboard. Instead, if it is known to scale well and its offset is known from other temperature sensors on board, the user may set "dev.amdtemp.0.sensor_offset" tunable to compensate the difference. Document the caveats in amdtemp(4). - Add a quirk for Socket AM2 Revision G processors. These processors are known to have a different offset according to Linux k8temp driver. - Warn about Family 10h Erratum 319. These processors have broken sensors. - Report temperature in more logical orders under dev.amdtemp node. For example, "dev.amdtemp.0.sensor0.core0" is now "dev.amdtemp.0.core0.sensor0". - Replace K8, K10 and K11 with official processor names in amdtemp(4).
|
#
197205 |
|
14-Sep-2009 |
jkim |
Restore (undocumented) support for early revisions and add more comments.
Reported by: kris
|
#
197103 |
|
11-Sep-2009 |
jkim |
Fix typos in comments from the previous commit.
|
#
197102 |
|
11-Sep-2009 |
jkim |
Improve amdtemp(4) significantly:
- Improve newer AMD processor support (Family 0Fh Revision F and later). - Adjust offset if DiodeOffet is set and valid. Note it is experimental but it seems to give us more realistic temperatures. Newer Linux driver blindly adds 21C for Family 0Fh desktop processors, however. - Always populate dev.cpu and dev.amdtemp sysctl trees regardless of probe order for consistency. Previously, dev.cpu.N.temperature was not populated if amdtemp was loaded later than ACPI CPU driver and temperatures were not accessible from dev.amdtemp.N.sensor0 tree for Family 10h/11h processors. - Read the CPUID from PCI register instead of CPUID instruction to prevent possible revision mismatches on multi-socket system. - Change macros and variables to make them closer to AMD documents. - Fix style(9) nits and improve comments.
|
#
196403 |
|
20-Aug-2009 |
jhb |
Temporarily revert the new-bus locking for 8.0 release. It will be reintroduced after HEAD is reopened for commits by re@.
Approved by: re (kib), attilio
|
#
196037 |
|
02-Aug-2009 |
attilio |
Make the newbus subsystem Giant free by adding the new newbus sxlock. The newbus lock is responsible for protecting newbus internIal structures, device states and devclass flags. It is necessary to hold it when all such datas are accessed. For the other operations, softc locking should ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device and bus are invoked when loading the driver or when the suspend/resume take place. For other 'spourious' operations trying to access/modify the newbus topology, newbus lock needs to be automatically acquired and dropped.
For the moment Giant is also acquired in some key point (modules subsystem) in order to avoid problems before the 8.0 release as module handlers could make assumptions about it. This Giant locking should go just after the release happens.
Please keep in mind that the public interface can be expanded in order to provide more support, if there are really necessities at some point and also some bugs could arise as long as the patch needs a bit of further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl No answer by: ariff, thompsa, yongari Tested by: pho, G. Trematerra <giovanni dot trematerra at gmail dot com>, Brandon Gooch <jamesbrandongooch at gmail dot com> Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)
|
#
189774 |
|
13-Mar-2009 |
rpaulo |
Fix comment explaining where this driver came from.
MFC after: 2 weeks
|
#
189769 |
|
13-Mar-2009 |
rpaulo |
Rename all the variables/function names/structs/etc. to reflect the driver name change. While there, update copyright.
MFC after: 2 weeks
|
#
189768 |
|
13-Mar-2009 |
rpaulo |
Rename the k8temp driver to amdtemp.
MFC after: 2 weeks
|
#
185434 |
|
29-Nov-2008 |
rpaulo |
Check the return value of config_intrhook_establish().
Found with: Coverity Prevent(tm) CID: 2115
|
#
182722 |
|
03-Sep-2008 |
rpaulo |
Fix the sysctl function parameters. We were only querying Sensor 0.
Noticed by: des MFC after: 3 days
|
#
180326 |
|
06-Jul-2008 |
rpaulo |
Fix comment: s/before/after.
|
#
180313 |
|
05-Jul-2008 |
rpaulo |
Add a missing call to config_intrhook_establish().
|
#
180312 |
|
05-Jul-2008 |
rpaulo |
Use config_intrhook API to create the dev.cpu.N.temperature sysctl node. Our hook creates the sysctl node before root is mounted, but after cpu is probed. It seems that k8temp can be loaded before the cpu module and, in those cases, dev.cpu.0.temperature was not created.
PR: 124939
|
#
178988 |
|
14-May-2008 |
rpaulo |
Actually, don't rely on the unsafe MAX() macro. Use imax() as provided in the PR patch.
Pointed out by: bde PR: 123542
|
#
178949 |
|
11-May-2008 |
rpaulo |
Don't use libkern's max() function as that's for unsigned numbers only. Instead use the worldwide known MAX() function. This should fix problems with negative values showing up on dev.cpu.%d.temperature. This is slightly different from the fix in the PR.
Submitted by: KOIE Hidetaka <hide at koie.org> PR: 123542
|
#
178392 |
|
21-Apr-2008 |
rpaulo |
Kill $P4$ id.
Noticed by: rwatson
|
#
178151 |
|
12-Apr-2008 |
rpaulo |
MFp4: k8temp, a driver to monitor AMD K8 CPU temperature via builtin sensors. Based on the Linux driver by the same name.
Tested by: many (see freebsd-amd64)
|