All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Huang <wei.huang2@amd.com>
To: Guenter Roeck <linux@roeck-us.net>,
	Gabriel C <nix.or.die@googlemail.com>
Cc: linux-hwmon@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: k10temp: ZEN3 readings are broken
Date: Mon, 21 Dec 2020 22:33:07 -0600	[thread overview]
Message-ID: <9d551bb4-0bd8-937c-f1c1-f6a86a24898f@amd.com> (raw)
In-Reply-To: <9d621d34-e5ce-301a-1b89-92c0791fe348@roeck-us.net>



On 12/21/20 9:58 PM, Guenter Roeck wrote:
> Hi,
> 
> On 12/21/20 5:45 PM, Gabriel C wrote:
>> Hello Guenter,
>>
>> while trying to add ZEN3 support for zenpower out of tree modules, I find out
>> the in-kernel k10temp driver is broken with ZEN3 ( and partially ZEN2 even ).
>>
>> commit 55163a1c00fcb526e2aa9f7f952fb38d3543da5e added:
>>
>> case 0x0 ... 0x1:       /* Zen3 */
>>
>> however, this is wrong, we look for a model which is 0x21 for ZEN3,
>> these seem to
>> be steppings?

These are model numbers for server CPUs. I believe 0x21 is for desktop 
CPUs. In other words, current upstream code doesn't support your CPUs. 
You are welcomed to add support for 0x21, but it is wrong to remove 
support for 0x00/0x01.

>>
>> Also, PLANE0/1 are wrong too, Icore has zero readouts even when fixing
>> the model.
>>
>> Looking at these ( there is something missing for 0x71 ZEN2 Ryzens
>> also ) that should be:
>>
>> PLANE0  (ZEN_SVI_BASE + 0x10)
>> PLANE1  (ZEN_SVI_BASE + 0xc)

Same problem here with model 0x71. 0x31 is for server CPUs.

>>
>> Which is the same as for ZEN2 >= 0x71. Since this is not really
>> documented and I have some
>> confirmations of these numbers from *somewhere* :-) I created a demo patch only.
>>
>> I would like AMD people to really have a look at the driver and
>> confirm the changes, since
>> getting information from *somewhere*,  dosen't mean they are 100%
>> correct. However, the driver
>> is working with these changes.
>>
>> In any way the model needs changing to 0x21 even if we let the other
>> readings broken.
>>
>> There is my demo patch:
>>
>> https://crazy.dev.frugalware.org/fix-ZEN2-ZEN3-test1.patch

For family 19h, the patch should look like. But this might not matter 
anymore as suggested by Guenter below.

  /* F19h thermal registers through SMN */
#define F19H_M01_SVI_TEL_PLANE0			(ZEN_SVI_BASE + 0x14)
#define F19H_M01_SVI_TEL_PLANE1			(ZEN_SVI_BASE + 0x10)
+/* Zen3 Ryzen */
+#define F19H_M21H_SVI_TEL_PLANE0		(ZEN_SVI_BASE + 0x10)
+#define F19H_M21H_SVI_TEL_PLANE1		(ZEN_SVI_BASE + 0xc)

Then add the following change:

  		switch (boot_cpu_data.x86_model) {
		case 0x0 ... 0x1:	/* Zen3 */
  			data->show_current = true;
			data->svi_addr[0] = F19H_M01_SVI_TEL_PLANE0;
			data->svi_addr[1] = F19H_M01_SVI_TEL_PLANE1;
  			data->cfactor[0] = F19H_M01H_CFACTOR_ICORE;
  			data->cfactor[1] = F19H_M01H_CFACTOR_ISOC;
  			k10temp_get_ccd_support(pdev, data, 8);
+		case 0x21:	/* Zen3 */
+ 			data->show_current = true;
+			data->svi_addr[0] = F19H_M21H_SVI_TEL_PLANE0;
+			data->svi_addr[1] = F19H_M21H_SVI_TEL_PLANE1;
+ 			data->cfactor[0] = F19H_M01H_CFACTOR_ICORE;
+ 			data->cfactor[1] = F19H_M01H_CFACTOR_ISOC;
+ 			k10temp_get_ccd_support(pdev, data, 8);

>>
>> Also, there is some discuss and testing for both drivers:
>>
>> https://github.com/ocerman/zenpower/issues/39
>>
> 
> Thanks for the information. However, since I do not have time to actively maintain
> the driver, since each chip variant seems to use different addresses and scales,
> and since the information about voltages and currents is unpublished by AMD,
> I'll remove support for voltage/current readings from the upstream driver.
> I plan to send the patch doing that to Linus shortly after the commit window
> closes (or even before that).

I believe Guenter is talking about 
https://www.spinics.net/lists/linux-hwmon/msg10252.html.

> 
> Thanks,
> Guenter
> 

  reply	other threads:[~2020-12-22  4:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-22  1:45 k10temp: ZEN3 readings are broken Gabriel C
2020-12-22  3:58 ` Guenter Roeck
2020-12-22  4:33   ` Wei Huang [this message]
2020-12-22  5:09     ` Gabriel C
2020-12-22  6:08       ` Wei Huang
2020-12-22  4:33   ` Gabriel C
2020-12-22  6:07     ` Guenter Roeck
2020-12-22  6:16     ` Guenter Roeck
2020-12-22 15:26       ` Gabriel C
2020-12-22 15:51         ` Guenter Roeck
2020-12-23 10:41   ` Jan Engelhardt
2020-12-23 11:22     ` Gabriel C
2020-12-23 11:27     ` Gabriel C
2020-12-23 14:25     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d551bb4-0bd8-937c-f1c1-f6a86a24898f@amd.com \
    --to=wei.huang2@amd.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=nix.or.die@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.