From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stewart Smith Subject: Re: [PATCH V2] cpuidle/powernv: Read target_residency value of idle states from DT if available Date: Thu, 29 Jan 2015 09:24:33 +1100 Message-ID: References: <20150128021044.11166.81418.stgit@preeti.in.ibm.com> <54C8B0E6.5080406@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <54C8B0E6.5080406@linux.vnet.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Preeti U Murthy , mpe@ellerman.id.au Cc: rafael.j.wysocki@intel.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org List-Id: linux-pm@vger.kernel.org UHJlZXRpIFUgTXVydGh5IDxwcmVldGlAbGludXgudm5ldC5pYm0uY29tPiB3cml0ZXM6Cj4gT24g MDEvMjgvMjAxNSAwMjo0NSBQTSwgU3Rld2FydCBTbWl0aCB3cm90ZToKPj4gUHJlZXRpIFUgTXVy dGh5IDxwcmVldGlAbGludXgudm5ldC5pYm0uY29tPiB3cml0ZXM6Cj4+PiBUaGUgZGV2aWNlIHRy ZWUgbm93IGV4cG9zZXMgdGhlIHJlc2lkZW5jeSB2YWx1ZXMgZm9yIGRpZmZlcmVudCBpZGxlIHN0 YXRlcy4gUmVhZAo+Pj4gdGhlc2UgdmFsdWVzIGluc3RlYWQgb2YgY2FsY3VsYXRpbmcgcmVzaWRl bmN5IGZyb20gdGhlIGxhdGVuY3kgdmFsdWVzLiBUaGUgdmFsdWVzCj4+PiBleHBvc2VkIGluIHRo ZSBEVCBhcmUgdmFsaWRhdGVkIGZvciBvcHRpbWFsIHBvd2VyIGVmZmljaWVuY3kuIEhvd2V2ZXIg dG8gbWFpbnRhaW4KPj4+IGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgb2xkZXIgZmlybXdhcmUgY29k ZSB3aGljaCBkb2VzIG5vdCBleHBvc2UgcmVzaWRlbmN5Cj4+PiB2YWx1ZXMsIHVzZSBkZWZhdWx0 IHZhbHVlcyBhcyBhIGZhbGxiYWNrIG1lY2hhbmlzbS4gV2hpbGUgYXQgaXQsIGhhbmRsZSBzb21l Cj4+PiBjbGVhbnVwcy4KPj4gCj4+IEZyb20gYSAiSSBqdXN0IG1lcmdlZCB0aGUgcGF0Y2ggdGhh dCBleHBvcnRzIHRoZXNlIHZhbHVlcyBmcm9tIGZpcm13YXJlIgo+PiBwb2ludCBvZiB2aWV3LCB1 c2luZyB0aGVtIGFuZCBmYWxsaW5nIGJhY2sgbG9va3MgZ29vZC4KPj4gCj4+IChJIGZpbmQgdGhl IGhhcmRjb2Rpbmcgb2Ygc25vb3plIGluIHRoZSBkcml2ZXIgYSBiaXQgb2RkLCBhcyBpcyB0aGUK Pgo+IFNub296ZSBpcyB0aGUgb25seSBzb2Z0d2FyZSBkZWZpbmVkIGlkbGUgc3RhdGUsIHRoZSBy ZXN0IGFyZSBwbGF0Zm9ybQo+IHNwZWNpZmljLiBUaGUgZmlyc3QgaWRsZSBzdGF0ZSBpcyB1c3Vh bGx5IGFzc29jaWF0ZWQgd2l0aCBzb21lIHNvcnQgb2YgYQo+IHBvbGxpbmcgb3BlcmF0aW9uIGFu ZCBlYWNoIGFyY2hpdGVjdHVyZSBoYXMgYSB2YXJpYW50IHRvIHRoaXMuIFRoaXMgaXMKPiB3aHkg d2UgZW5kIHVwIGhhcmQtY29kaW5nIHRoaXMgaWRsZSBzdGF0ZSBpbiB0aGUgZHJpdmVyIGFzIGZh ciBhcyBteQo+IHVuZGVyc3RhbmRpbmcgZ29lcy4KCkF0IGxlYXN0IGluIHRoZSBQb3dlcklTQSAy LjA3IEkgY291bGQgb25seSBzZWUgdGhhdCBsb3dlcmluZyBwcmlvcml0eQp3b3VsZCBnaXZlIHBy aW9yaXR5IHRvIG90aGVyIHRocmVhZHMgaW4gdGhlIGNvcmUsIEkgY291bGRuJ3QgZmluZAphbnl0 aGluZyBzYXlpbmcgdGhhdCBvciAzMSwzMSwzMSB3b3VsZCBlbmQgdXAgc2F2aW5nIGFueSBwb3dl ci4uLiBidXQgSQpjb3VsZCBiZSBsb29raW5nIGluIHRoZSB3cm9uZyBwbGFjZSB0b28uCgpCYXNp Y2FsbHksIEkgd2FzIHdhbnRpbmcgdG8gY2hlY2sgdGhhdCBpdCdzIGFjdHVhbGx5IHdyaXR0ZW4g ZG93biBhbmQKYXJjaGl0ZWN0ZWQgc29tZXdoZXJlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSBhbmQg aXQgaXNuJ3Qgc29tZXRoaW5nIHRvbwpQNy9QOCBzcGVjaWZpYy4KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QK TGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcKaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xp c3RpbmZvL2xpbnV4cHBjLWRldg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 31DE81A09D4 for ; Thu, 29 Jan 2015 09:24:44 +1100 (AEDT) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Jan 2015 15:24:41 -0700 Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id AB59519D801C for ; Wed, 28 Jan 2015 15:15:48 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t0SMOkkj33947760 for ; Wed, 28 Jan 2015 15:24:46 -0700 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t0SMObDO030936 for ; Wed, 28 Jan 2015 15:24:37 -0700 From: Stewart Smith To: Preeti U Murthy , mpe@ellerman.id.au Subject: Re: [PATCH V2] cpuidle/powernv: Read target_residency value of idle states from DT if available In-Reply-To: <54C8B0E6.5080406@linux.vnet.ibm.com> References: <20150128021044.11166.81418.stgit@preeti.in.ibm.com> <54C8B0E6.5080406@linux.vnet.ibm.com> Date: Thu, 29 Jan 2015 09:24:33 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rafael.j.wysocki@intel.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Preeti U Murthy writes: > On 01/28/2015 02:45 PM, Stewart Smith wrote: >> Preeti U Murthy writes: >>> The device tree now exposes the residency values for different idle states. Read >>> these values instead of calculating residency from the latency values. The values >>> exposed in the DT are validated for optimal power efficiency. However to maintain >>> compatibility with the older firmware code which does not expose residency >>> values, use default values as a fallback mechanism. While at it, handle some >>> cleanups. >> >> From a "I just merged the patch that exports these values from firmware" >> point of view, using them and falling back looks good. >> >> (I find the hardcoding of snooze in the driver a bit odd, as is the > > Snooze is the only software defined idle state, the rest are platform > specific. The first idle state is usually associated with some sort of a > polling operation and each architecture has a variant to this. This is > why we end up hard-coding this idle state in the driver as far as my > understanding goes. At least in the PowerISA 2.07 I could only see that lowering priority would give priority to other threads in the core, I couldn't find anything saying that or 31,31,31 would end up saving any power... but I could be looking in the wrong place too. Basically, I was wanting to check that it's actually written down and architected somewhere that this is the case and it isn't something too P7/P8 specific.