From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753525AbbCDXzG (ORCPT <rfc822;w@1wt.eu>);
	Wed, 4 Mar 2015 18:55:06 -0500
Received: from v094114.home.net.pl ([79.96.170.134]:54265 "HELO
	v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with SMTP id S1751693AbbCDXzD (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 Mar 2015 18:55:03 -0500
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: "Li, Aubrey" <aubrey.li@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>, Alan Cox <alan@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux PM list <linux-pm@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Kristen Carlson Accardi <kristen@linux.intel.com>,
        John Stultz <john.stultz@linaro.org>, Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
Date: Thu, 05 Mar 2015 01:18:38 +0100
Message-ID: <2502414.MyBzvuWGMR@vostro.rjw.lan>
User-Agent: KMail/4.11.5 (Linux/3.19.0+; KDE/4.11.5; x86_64; ; )
In-Reply-To: <54F79A42.9070801@linux.intel.com>
References: <8292243.ibkmfVtXac@vostro.rjw.lan> <25445086.IBiaGBbm1j@vostro.rjw.lan> <54F79A42.9070801@linux.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote:
> On 2015/2/13 0:24, Rafael J. Wysocki wrote:
> > On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
> >>
> >> Why bother with enter_freeze() for any but the deepest state (C6 in this
> >> case)?
> > 
> > User space may disable the deepest one (and any of them in general) via sysfs
> > and there's no good reason to ignore its choice in this particular case while
> > we're honoring it otherwise.
> > 
> > So the logic is basically "find the deepest one which isn't disabled" and
> > setting the pointers costs us nothing really.
> > 
> 
> If the user has chance to disable C6 via /sys, that means c6 works?
> Shouldn't we ignore user space setting during freeze? Otherwise, we will
> lost S0ix?

We can't ignore it, because we don't know the reason why the state was
disabled.

It may just not work reliably enough on the given platform.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.