From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933735AbdBQK2I (ORCPT ); Fri, 17 Feb 2017 05:28:08 -0500 Received: from foss.arm.com ([217.140.101.70]:52260 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932374AbdBQK2G (ORCPT ); Fri, 17 Feb 2017 05:28:06 -0500 Subject: Re: [PATCH 1/5] arm64: dts: Add basic DT to support Spreadtrum's SP9860G To: devicetree@vger.kernel.org, orson.zhai@spreadtrum.com, open list , linux-arm , Chunyan Zhang References: <1487063952-7113-1-git-send-email-chunyan.zhang@spreadtrum.com> <1487063952-7113-2-git-send-email-chunyan.zhang@spreadtrum.com> <20170217072839.GA8767@spreadtrum.com> Cc: Rob Herring , Mark Rutland , Greg Kroah-Hartman , Catalin Marinas , Will Deacon , Arnd Bergmann , Sudeep Holla From: Sudeep Holla Organization: ARM Message-ID: Date: Fri, 17 Feb 2017 10:28:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170217072839.GA8767@spreadtrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/02/17 07:28, Chunyan Zhang wrote: > Hi Sudeep, > > On 二, 2月 14, 2017 at 04:44:53下午 +0000, Sudeep Holla wrote: >> On Tue, Feb 14, 2017 at 9:19 AM, Chunyan Zhang >> wrote: [..] >> >>> + idle-states{ >>> + entry-method = "arm,psci"; >>> + >>> + CORE_PD: core_pd { >>> + compatible = "arm,idle-state"; >>> + entry-latency-us = <1000>; >>> + exit-latency-us = <700>; >>> + min-residency-us = <2500>; >>> + local-timer-stop; >>> + arm,psci-suspend-param = <0x00010002>; >>> + }; >>> + >>> + CLUSTER_PD: cluster_pd { >>> + compatible = "arm,idle-state"; >>> + entry-latency-us = <1000>; >>> + exit-latency-us = <1000>; >>> + min-residency-us = <3000>; >>> + local-timer-stop; >>> + arm,psci-suspend-param = <0x01010003>; >>> + }; >>> + >>> + DEEP_SLEEP: deep_sleep { >>> + compatible = "arm,idle-state"; >>> + wakeup-latency-us = <0xffffffff>; >> >> A value > 4294 seconds(i.e >1 hour) seems suspicious. >> Are you working around the firmware issue with high latency value so >> that it's never entered ? Why not remove advertising the state from DT. >> > > Haved checked with related colleagues, this node 'deep_sleep' was not for working > around any firmware issue, but was a trick utilization of idle subsystem, and that Really ? Any latency greater few milliseconds are sounds useless. I still don't understand what you mean by "trick utilization of idle subsystem". > was definitely not elegant, the author indeed intendly didn't want CPU entered this > state, I will remove this node therefore. It's quick and dirty "HACK* to retain and advertise the state but ensure it's never entered and obstruct the boot. It's not a trick to exploit any idle subsystem utilization. > >> Can you get me the dump of: >> grep "" /sys/devices/system/cpu/cpu*/cpuidle/state*/{time,usage} >> > > FYI: https://www.irccloud.com/pastebin/XyEMLzfq/ > As expected, state3(deep_sleep) is never entered. -- Regards, Sudeep