This patch adds temperature monitoring support for F15h M60h processor.
- Add new pci device id for the relevant processor
- The functionality of REG_REPORTED_TEMPERATURE is moved to
D0F0xBC_xD820_0CA4 [Reported Temperature Control]
- So, use this to get CUR_TEMP value
- Add Kconfig, Doc entries to indicate support for this processor.
Signed-off-by: Aravind Gopalakrishnan <[email protected]>
---
Documentation/hwmon/k10temp | 2 +-
drivers/hwmon/Kconfig | 4 ++--
drivers/hwmon/k10temp.c | 22 ++++++++++++++++++++--
include/linux/pci_ids.h | 1 +
4 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
index ee6d30e..254d2f5 100644
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -11,7 +11,7 @@ Supported chips:
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
-* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri"
+* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", "Carrizo"
* AMD Family 16h processors: "Kabini", "Mullins"
Prefix: 'k10temp'
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 02d3d85..57ba400 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -280,8 +280,8 @@ config SENSORS_K10TEMP
If you say yes here you get support for the temperature
sensor(s) inside your CPU. Supported are later revisions of
the AMD Family 10h and all revisions of the AMD Family 11h,
- 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri) and
- 16h (Kabini/Mullins) microarchitectures.
+ 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri/Carrizo)
+ and 16h (Kabini/Mullins) microarchitectures.
This driver can also be built as a module. If so, the module
will be called k10temp.
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index f7b46f6..5da872f 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -51,13 +51,30 @@ MODULE_PARM_DESC(force, "force loading on processors with erratum 319");
#define REG_NORTHBRIDGE_CAPABILITIES 0xe8
#define NB_CAP_HTC 0x00000400
+/*
+ * For F15h M60h, functionality of REG_REPORTED_TEMPERATURE
+ * has been moved to D0F0xBC_xD820_0CA4 [Reported Temperature
+ * Control]
+ */
+#define NB_SMU_IND_ADDR 0xb8
+#define NB_SMU_IND_DATA 0xbc
+#define IND_ADDR_OFFSET 0xd8200ca4
+
static ssize_t show_temp(struct device *dev,
struct device_attribute *attr, char *buf)
{
u32 regval;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
+ pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
+ NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
+ pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
+ NB_SMU_IND_DATA, ®val);
+
+ } else
+ pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, ®val);
- pci_read_config_dword(to_pci_dev(dev),
- REG_REPORTED_TEMPERATURE, ®val);
return sprintf(buf, "%u\n", (regval >> 21) * 125);
}
@@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{}
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 7fa3173..3c8e328 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -520,6 +520,7 @@
#define PCI_DEVICE_ID_AMD_15H_M10H_F3 0x1403
#define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
#define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
+#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
#define PCI_DEVICE_ID_AMD_15H_NB_F0 0x1600
#define PCI_DEVICE_ID_AMD_15H_NB_F1 0x1601
#define PCI_DEVICE_ID_AMD_15H_NB_F2 0x1602
--
1.8.1.2
On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> This patch adds temperature monitoring support for F15h M60h processor.
> - Add new pci device id for the relevant processor
> - The functionality of REG_REPORTED_TEMPERATURE is moved to
> D0F0xBC_xD820_0CA4 [Reported Temperature Control]
> - So, use this to get CUR_TEMP value
> - Add Kconfig, Doc entries to indicate support for this processor.
>
> Signed-off-by: Aravind Gopalakrishnan <[email protected]>
> ---
> Documentation/hwmon/k10temp | 2 +-
> drivers/hwmon/Kconfig | 4 ++--
> drivers/hwmon/k10temp.c | 22 ++++++++++++++++++++--
> include/linux/pci_ids.h | 1 +
> 4 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
> index ee6d30e..254d2f5 100644
> --- a/Documentation/hwmon/k10temp
> +++ b/Documentation/hwmon/k10temp
> @@ -11,7 +11,7 @@ Supported chips:
> Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
> * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
> * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
> -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri"
> +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", "Carrizo"
> * AMD Family 16h processors: "Kabini", "Mullins"
>
> Prefix: 'k10temp'
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 02d3d85..57ba400 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -280,8 +280,8 @@ config SENSORS_K10TEMP
> If you say yes here you get support for the temperature
> sensor(s) inside your CPU. Supported are later revisions of
> the AMD Family 10h and all revisions of the AMD Family 11h,
> - 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri) and
> - 16h (Kabini/Mullins) microarchitectures.
> + 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri/Carrizo)
> + and 16h (Kabini/Mullins) microarchitectures.
>
> This driver can also be built as a module. If so, the module
> will be called k10temp.
> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
> index f7b46f6..5da872f 100644
> --- a/drivers/hwmon/k10temp.c
> +++ b/drivers/hwmon/k10temp.c
> @@ -51,13 +51,30 @@ MODULE_PARM_DESC(force, "force loading on processors with erratum 319");
> #define REG_NORTHBRIDGE_CAPABILITIES 0xe8
> #define NB_CAP_HTC 0x00000400
>
> +/*
> + * For F15h M60h, functionality of REG_REPORTED_TEMPERATURE
> + * has been moved to D0F0xBC_xD820_0CA4 [Reported Temperature
> + * Control]
> + */
> +#define NB_SMU_IND_ADDR 0xb8
> +#define NB_SMU_IND_DATA 0xbc
> +#define IND_ADDR_OFFSET 0xd8200ca4
> +
> static ssize_t show_temp(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> u32 regval;
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> + NB_SMU_IND_DATA, ®val);
> +
> + } else
> + pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, ®val);
>
> - pci_read_config_dword(to_pci_dev(dev),
> - REG_REPORTED_TEMPERATURE, ®val);
> return sprintf(buf, "%u\n", (regval >> 21) * 125);
> }
>
> @@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
> + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> {}
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 7fa3173..3c8e328 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -520,6 +520,7 @@
> #define PCI_DEVICE_ID_AMD_15H_M10H_F3 0x1403
> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
> +#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
I'm assuming this is used somewhere else besides k10temp.c?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 7/14/2014 2:51 PM, Borislav Petkov wrote:
> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>
>> @@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
>> + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
>> {}
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 7fa3173..3c8e328 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -520,6 +520,7 @@
>> #define PCI_DEVICE_ID_AMD_15H_M10H_F3 0x1403
>> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
>> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
>> +#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
> I'm assuming this is used somewhere else besides k10temp.c?
>
Yeah, will most likely need to add EDAC bits. But that is something I
can't test now.
So will have to do it only in due time.. :)
-Aravind.
On Mon, Jul 14, 2014 at 02:59:10PM -0500, Aravind Gopalakrishnan wrote:
> On 7/14/2014 2:51 PM, Borislav Petkov wrote:
> >On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> >>@@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
> >> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
> >> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
> >> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
> >>+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
> >> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> >> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> >> {}
> >>diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> >>index 7fa3173..3c8e328 100644
> >>--- a/include/linux/pci_ids.h
> >>+++ b/include/linux/pci_ids.h
> >>@@ -520,6 +520,7 @@
> >> #define PCI_DEVICE_ID_AMD_15H_M10H_F3 0x1403
> >> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
> >> #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
> >>+#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
> >I'm assuming this is used somewhere else besides k10temp.c?
> >
>
> Yeah, will most likely need to add EDAC bits. But that is something
> I can't test now.
>
Sorry, I can not add this to a common file unless it is used elsewhere.
I would suggest to add it locally for now. It can be moved to the
common file once it is used elsewhere.
Guenter
Borislav Petkov wrote:
> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>> + NB_SMU_IND_DATA, ®val);
How do you prevent races with any other code that accesses some indirect
register?
>> +
>> + } else
>> + pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, ®val);
Why the empty line? Also, use braces in both branches.
Regards,
Clemens
On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
> Borislav Petkov wrote:
> > On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> >> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
> >> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> >> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
> >> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> >> + NB_SMU_IND_DATA, ®val);
>
> How do you prevent races with any other code that accesses some indirect
> register?
>
I just wanted to ask exactly the same question. I think this will need
locking.
> >> +
> >> + } else
> >> + pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, ®val);
>
> Why the empty line? Also, use braces in both branches.
>
Agreed. Too bad the respective checkpatch warning was moved to --strict.
Guenter
Guenter Roeck wrote:
> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>> Borislav Petkov wrote:
>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>> + NB_SMU_IND_DATA, ®val);
>>
>> How do you prevent races with any other code that accesses some indirect
>> register?
>>
> I just wanted to ask exactly the same question. I think this will need
> locking.
If there actually is any other code; these indirect SMU registers appear
to be mostly undocumented and to be intended to be used by the BIOS.
(Which makes me wonder why the temperature sensor was moved there.)
Anyway, if a lock is needed, it looks as if it could go into a helper
function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.
Regards,
Clemens
On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
> Guenter Roeck wrote:
>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>> Borislav Petkov wrote:
>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>>> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>>> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>> + NB_SMU_IND_DATA, ®val);
>>>
>>> How do you prevent races with any other code that accesses some indirect
>>> register?
>>>
>> I just wanted to ask exactly the same question. I think this will need
>> locking.
>
> If there actually is any other code; these indirect SMU registers appear
> to be mostly undocumented and to be intended to be used by the BIOS.
> (Which makes me wonder why the temperature sensor was moved there.)
>
Scary. Does that mean there is a chance they may get used through ACPI ?
> Anyway, if a lock is needed, it looks as if it could go into a helper
> function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.
>
Yes, something like that.
Guenter
On 7/15/2014 4:03 AM, Guenter Roeck wrote:
> On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
>> Guenter Roeck wrote:
>>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>>> Borislav Petkov wrote:
>>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan
>>>>> wrote:
>>>>>> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model ==
>>>>>> 0x60) {
>>>>>> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>>> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>> + NB_SMU_IND_DATA, ®val);
>>>>
>>>> How do you prevent races with any other code that accesses some
>>>> indirect
>>>> register?
>>>>
>>> I just wanted to ask exactly the same question. I think this will need
>>> locking.
>>
>> If there actually is any other code; these indirect SMU registers appear
>> to be mostly undocumented and to be intended to be used by the BIOS.
>> (Which makes me wonder why the temperature sensor was moved there.)
>>
> Scary. Does that mean there is a chance they may get used through ACPI ?
I have been asking internally about this, and looks like it's just a
register address change.
So we probably don't have to worry about this being used elsewhere..
>
>> Anyway, if a lock is needed, it looks as if it could go into a helper
>> function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.
>>
> Yes, something like that.
>
>
Okay, I shall add the locking mechanism and re-send.
Thanks,
-Aravind.
Aravind Gopalakrishnan wrote:
> On 7/15/2014 4:03 AM, Guenter Roeck wrote:
>> On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
>>> Guenter Roeck wrote:
>>>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>>>> Borislav Petkov wrote:
>>>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>>>>> + if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>>>>> + pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>>> + NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>>>> + pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>>> + NB_SMU_IND_DATA, ®val);
>>>>>
>>>>> How do you prevent races with any other code that accesses some indirect
>>>>> register?
>>>
>>> If there actually is any other code; these indirect SMU registers appear
>>> to be mostly undocumented and to be intended to be used by the BIOS.
>>> (Which makes me wonder why the temperature sensor was moved there.)
>>
>> Scary. Does that mean there is a chance they may get used through ACPI ?
>
> I have been asking internally about this, and looks like it's just a register address change.
> So we probably don't have to worry about this being used elsewhere..
The conflict is about the SMU index register; the question is whether
_any_ of these SMU registers is used elsewhere (in a way that could
happen concurrently).
Regards,
Clemens