From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition Date: Wed, 31 May 2017 18:40:37 +0200 Message-ID: <77df6298-945b-7663-0cb9-cd24fa583c6a@linaro.org> References: <1495212343-24873-1-git-send-email-daniel.lezcano@linaro.org> <850fab54-d6e6-7b4c-631a-f4ee658c96fa@arm.com> <45754d0a-6a98-2987-74ed-429926d89cbc@arm.com> <3ce7048e-6d9d-9e46-a6fb-4d3263231536@arm.com> <8c5b46d1-8b34-2ced-e27d-4d76f80953c6@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from mail-wm0-f51.google.com ([74.125.82.51]:36574 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbdEaQkl (ORCPT ); Wed, 31 May 2017 12:40:41 -0400 Received: by mail-wm0-f51.google.com with SMTP id 7so125515939wmo.1 for ; Wed, 31 May 2017 09:40:40 -0700 (PDT) In-Reply-To: <8c5b46d1-8b34-2ced-e27d-4d76f80953c6@arm.com> Content-Language: en-US Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Sudeep Holla Cc: rjw@rjwysocki.net, lorenzo.pieralisi@arm.com, leo.yan@linaro.org, "open list:CPUIDLE DRIVERS" , open list On 22/05/2017 17:02, Sudeep Holla wrote: > > > On 22/05/17 15:48, Daniel Lezcano wrote: >> On 22/05/2017 15:02, Sudeep Holla wrote: >> >> [ ... ] >> >>>>>>>> + drv->cpumask = &cpu_topology[cpu].core_sibling; >>>>>>>> + >>>>>>> >>>>>>> This is not always true and not architecturally guaranteed. So instead >>>>>>> of introducing this broken dependency, better to extract information >>>>>>> from the device tree. >>>>>> >>>>>> Can you give an example of a broken dependency ? >>>>>> >>>>>> The cpu topology information is extracted from the device tree. So >>>>>> if the topology is broken, the DT is broken also. Otherwise, the >>>>>> topology code must fix the broken dependency from the DT. >>>>>> >>>>> >>>>> No, I meant there's no guarantee that all designs must follow this rule. >>>>> I don't mean CPU topology code or binding is broken. What I meant is >>>>> linking CPU topology to CPU power domains is wrong. We should make use >>>>> of DT you infer this information as it's already there. Topology bindings >>>>> makes no reference to power and hence you simply can't infer that >>>>> information from it. >>>> >>>> Ok, I will have a look how power domains can fit in this. >>>> >>>> However I'm curious to know a platform with a cluster idle state >>>> powering down only a subset of CPUs belonging to the cluster. >>>> >>> >>> We can't reuse CPU topology for power domains: >>> 1. As I mentioned earlier for sure, it won't be same with ARM DynamIQ. >>> 2. Topology bindings strictly restrict themselves with topology and not >>> connected with power-domains. We also have separate power domain >>> bindings. >> >> Yes, the theory is valid, but practically nowadays I don't see where we >> have a cluster defined by a topology with a different cluster power domain. >> > > While I agree that it's true in current practice, but in past we have > seen "innovative designs". We initially had 2 clusters(big and little) > then we saw 3 cluster(big little and tiny or whatever you what to call) > So as it's not architecturally guaranteed, it's not nice to make this > assumption in a generic driver. > >> By the way, if you have any pointer to documentation for DynamIQ PM and >> design? I would be interested to have a look. >> > > I don't have anything in detail. Excerpts from the link I sent earlier > indicate that it's possible and highly likely. > > "DynamIQ supports multiple, configurable, performance domains within a > single cluster. These domains, consisting of single or multiple ARM > CPUs, can scale in performance and power with finer granularity than > previous quad-core clusters." > >>> We need to separate topology and power domains. We have some dependency >>> like this in big little drivers(both CPUfreq and CPUIdle) but that >>> dependencies must be removed as they are not architecturally guaranteed. >>> Lorenzo had a patch[1] to solve this issue, I can post the latest >>> version of it again and continue the discussion after some basic >>> rebase/testing. >> >> Actually, I am not convinced by the approach proposed in this patch. >> >> Let me have a look at the idle power domain before, I do believe we can >> do something much more simple. >> > > OK, if you think so. Hi Sudeep, Lorenzo, I have been thinking and looking at the domain-idle-state and I don't see an obvious connection between what is describing the power domain, the cpu idle driver and what we are trying to achieve. I would like to suggest something much more simple, register a cpuidle driver per cpu, so every cpu can have its own idle definitions, that should work for dynamiQ, smp and hmp. The impact on the driver will be minimal. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog