linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Cedric Le Goater <clg@fr.ibm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
	lm-sensors@lm-sensors.org,
	Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
	skiboot@lists.ozlabs.org, linuxppc-dev@lists.ozlabs.org,
	Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels
Date: Tue, 07 Apr 2015 20:03:46 +0200	[thread overview]
Message-ID: <55241C02.60103@fr.ibm.com> (raw)
In-Reply-To: <20150407164439.GA4514@roeck-us.net>

Hello Guenter,

On 04/07/2015 06:44 PM, Guenter Roeck wrote:
> On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical 
>> identifier of the core in the "ibm,pir" property. The driver 
>> translates this identifier in a linux cpu number and prints out a 
>> range corresponding to the hardware threads of the core (as they
>> share the same sensor).
>>
>> The numbering gives a hint on the localization of the core in the 
>> system (which socket, which chip). 
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> Please do not send follow-up patches as reply, but as separate e-mail.

Ok. I will start a new thread when I resend this patch.

> Further comments below.
> 
>> ---
>>
>>  Changes since v1:
>>
>>  - check cpu validity before printing out the attribute label. 
>>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>>    number from a physical cpu number. 
>>
>>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> Index: linux.git/drivers/hwmon/ibmpowernv.c
>> ===================================================================
>> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
>> +++ linux.git/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>>  static void __init make_sensor_label(struct device_node *np,
>>  		    struct sensor_data *sdata, const char *label)
>>  {
>> +	u32 id;
>>  	size_t n;
>>  
>>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +	/*
>> +	 * Core temp pretty print
>> +	 */
>> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +		int i = -1;
>> +
>> +		for_each_possible_cpu(i)
>> +			if (paca[i].hw_cpu_id == id)
> 
> I think you should consider using get_hard_smp_processor_id() and avoid
> direct access to the paca array.

Yes. It will look better. Thanks.

>> +				break;
>> +
>> +		if (i != -1)
> 
> I don't think that works. i is initialized by for_each_possible_cpu(),
> either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
> it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).
> 
> You would need a second variable (which you could pre-initialize)
> to determine if the code found a matching ID or not.

gloups. I did that patch waaaay too quickly, it is completely bogus ... 
I will cook a new version. sorry for the noise. 

>> +			/*
>> +			 * The digital thermal sensors are associated
>> +			 * with a core. Let's print out the range of
>> +			 * cpu ids corresponding to the hardware
>> +			 * threads of the core.
>> +			 */
>> +			n += snprintf(sdata->label + n,
>> +				      sizeof(sdata->label) - n,
>> +				      " %d-%d", i, i+7);
> 
> I would really like to see how this looks like in practice.
> 
> The id in the devicetree entry is the physical CPU. The resulting index
> is the logical CPU number. So let's assume that the logical CPU number
> for the first physical CPU is 0. Output would be "0-7". If the second
> physical CPU matches logical CPU 1, output would be "1-8". 
> How does that make any sense ?

The logical CPU numbers on PowerPC are initialized looping on the cores
found in the device tree and then on the threads of the core. Something 
like :

	logical_cpu = core_index * max_threads_per_core + thread_index 

which gives on a P8  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3*    4*    5*    6*    7* 
	Core   1:    8*    9*   10*   11*   12*   13*   14*   15* 
	Core   2:   16*   17*   18*   19*   20*   21*   22*   23* 
	Core   3:   24*   25*   26*   27*   28*   29*   30*   31* 
	Core   4:   32*   33*   34*   35*   36*   37*   38*   39* 
	Core   5:   40*   41*   42*   43*   44*   45*   46*   47* 
	Core   6:   48*   49*   50*   51*   52*   53*   54*   55* 
	Core   7:   56*   57*   58*   59*   60*   61*   62*   63* 
	Core   8:   64*   65*   66*   67*   68*   69*   70*   71* 
	Core   9:   72*   73*   74*   75*   76*   77*   78*   79* 
	Core  10:   80*   81*   82*   83*   84*   85*   86*   87* 
	Core  11:   88*   89*   90*   91*   92*   93*   94*   95* 
	Core  12:   96*   97*   98*   99*  100*  101*  102*  103* 
	Core  13:  104*  105*  106*  107*  108*  109*  110*  111* 
	Core  14:  112*  113*  114*  115*  116*  117*  118*  119* 
	Core  15:  120*  121*  122*  123*  124*  125*  126*  127* 
	Core  16:  128*  129*  130*  131*  132*  133*  134*  135* 
	Core  17:  136*  137*  138*  139*  140*  141*  142*  143* 
	Core  18:  144*  145*  146*  147*  148*  149*  150*  151* 
	Core  19:  152*  153*  154*  155*  156*  157*  158*  159* 

on a P7  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3* 
	Core   1:    4*    5*    6*    7* 
	Core   2:    8*    9*   10*   11* 
	Core   3:   12*   13*   14*   15* 
	Core   4:   16*   17*   18*   19* 
	Core   5:   20*   21*   22*   23* 


> Also, how do you know that the range of CPU IDs is always 8 ?

This is a shortcut. The code is for the ibmpowernv platform and assumes 
that we are running on a P8 (8 hardware threads). It would be better to 
use a "maximum threads per core" variable but I am not sure this is 
available, as it is a tunable. I will look into it.

> Can you provide some resulting outputs ?

sure. 

On an Open Power system : 

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	Core 8-15:    +29.0°C  
	Core 16-23:   +29.0°C  
	Core 24-31:   +30.0°C  
	Core 32-39:   +30.0°C  
	Core 40-47:   +32.0°C  
	Core 48-55:   +29.0°C  
	Core 56-63:   +29.0°C  
	Centaur 0:    +28.0°C  
	Centaur 1:    +32.0°C  
	Centaur 4:    +28.0°C  
	Centaur 5:    +27.0°C  
	Core 0-7:     +29.0°C  

The Centaur numbering does not look as good as for the core.

On an IBM Power system :

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	fan1:         5960 RPM  (min =    0 RPM)
	fan2:         5252 RPM  (min =    0 RPM)
	fan3:         5960 RPM  (min =    0 RPM)
	fan4:         5242 RPM  (min =    0 RPM)
	fan5:         5008 RPM  (min =    0 RPM)
	fan6:         5000 RPM  (min =    0 RPM)
	fan7:         5232 RPM  (min =    0 RPM)
	fan8:         5986 RPM  (min =    0 RPM)
	fan9:         5232 RPM  (min =    0 RPM)
	fan10:        6094 RPM  (min =    0 RPM)
	fan11:        5242 RPM  (min =    0 RPM)
	fan12:        5882 RPM  (min =    0 RPM)
	fan13:        5212 RPM  (min =    0 RPM)
	fan14:        5973 RPM  (min =    0 RPM)
	Ambient:       +18.0°C  (high =  +0.0°C)
	Core 0-7:      +40.0°C  
	Core 8-15:     +39.0°C  
	Core 16-23:    +39.0°C  
	Core 24-31:    +38.0°C  
	Core 32-39:    +38.0°C  
	Core 40-47:    +37.0°C  
	Core 48-55:    +37.0°C  
	Core 56-63:    +38.0°C  
	Core 64-71:    +38.0°C  
	Core 72-79:    +39.0°C  
	Core 80-87:    +35.0°C  
	Core 88-95:    +34.0°C  
	Core 96-103:   +33.0°C  
	Core 104-111:  +34.0°C  
	Core 112-119:  +33.0°C  
	Core 120-127:  +31.0°C  
	Core 128-135:  +31.0°C  
	Core 136-143:  +39.0°C  
	Core 144-151:  +39.0°C  
	Core 152-159:  +40.0°C  
	power1:       425.00 W  

The Centaur are not exposed yet.

Thanks,

C.

  reply	other threads:[~2015-04-07 18:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1423117857-32759-1-git-send-email-clg@fr.ibm.com>
2015-02-20 15:07 ` [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-02-20 16:52   ` Guenter Roeck
2015-02-20 20:15     ` Cedric Le Goater
2015-02-20 23:52       ` Guenter Roeck
2015-02-21  7:14         ` Cedric Le Goater
2015-02-21 11:03           ` Guenter Roeck
2015-02-23 10:54             ` Cedric Le Goater
2015-02-20 15:07 ` [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist Cédric Le Goater
2015-02-20 16:53   ` Guenter Roeck
2015-02-20 20:18     ` Cedric Le Goater
2015-02-24  4:54   ` Michael Ellerman
2015-02-25 17:28     ` Cedric Le Goater
2015-02-20 15:07 ` [RFC PATCH 2/3] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Cédric Le Goater
2015-02-20 15:07 ` [RFC PATCH 3/3] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-03-18 15:47 ` [PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index Cédric Le Goater
2015-03-19  4:05   ` Guenter Roeck
2015-03-18 15:47 ` [PATCH 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP Cédric Le Goater
2015-03-18 15:47 ` [PATCH 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine Cédric Le Goater
2015-03-18 15:47 ` [PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine Cédric Le Goater
2015-03-19  3:58   ` Guenter Roeck
2015-03-18 15:47 ` [PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype Cédric Le Goater
2015-03-19  4:02   ` Guenter Roeck
2015-03-18 15:47 ` [PATCH 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index Cédric Le Goater
2015-03-20 15:26   ` Guenter Roeck
2015-03-20 16:52     ` Cedric Le Goater
2015-04-01 10:15   ` [PATCH 0/4] hwmon: (ibmpowernv) add DTS support Cédric Le Goater
2015-04-01 10:15   ` [PATCH 1/4] hwmon: (ibmpowernv) add a helper routine create_hwmon_attr Cédric Le Goater
2015-04-01 10:15   ` [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree Cédric Le Goater
2015-04-01 10:15   ` [PATCH 3/4] hwmon: (ibmpowernv) add a label attribute Cédric Le Goater
2015-04-01 10:15   ` [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels Cédric Le Goater
2015-04-03 15:49     ` Guenter Roeck
2015-04-07 14:42       ` Cedric Le Goater
2015-04-07 14:45         ` Cédric Le Goater
2015-04-07 16:44           ` Guenter Roeck
2015-04-07 18:03             ` Cedric Le Goater [this message]
2015-04-07 19:22               ` Guenter Roeck
2015-04-08  6:57                 ` Cedric Le Goater
2015-04-07 20:22               ` [Skiboot] " Benjamin Herrenschmidt
2015-03-19 17:44 ` [PATCH v2 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine Cédric Le Goater
2015-03-19 17:44 ` [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype Cédric Le Goater
2015-03-20  8:06   ` Cedric Le Goater
2015-03-20 15:27     ` Guenter Roeck
2015-03-19 17:44 ` [PATCH v2 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names Cédric Le Goater

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=55241C02.60103@fr.ibm.com \
    --to=clg@fr.ibm.com \
    --cc=jdelvare@suse.de \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=neelegup@linux.vnet.ibm.com \
    --cc=skiboot@lists.ozlabs.org \
    --cc=stewart@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).