From: Viresh Kumar <viresh.kumar@linaro.org> To: Nicola Mazzucato <nicola.mazzucato@arm.com> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, daniel.lezcano@linaro.org, morten.rasmussen@arm.com, chris.redpath@arm.com Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Date: Thu, 8 Oct 2020 16:32:41 +0530 [thread overview] Message-ID: <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> (raw) In-Reply-To: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> On 07-10-20, 13:58, Nicola Mazzucato wrote: > Hi Viresh, > > performance controls is what is exposed by the firmware through a protocol that > is not capable of describing hardware (say SCMI). For example, the firmware can > tell that the platform has N controls, but it can't say to which hardware they > are "wired" to. This is done in dt, where, for example, we map these controls > to cpus, gpus, etc. > > Let's focus on cpus. > > Normally we would have N of performance controls (what comes from f/w) > that that correspond to hardware clock/dvfs domains. > > However, some firmware implementations might benefit from having finer > grained information about the performance requirements (e.g. > per-CPU) and therefore choose to present M performance controls to the > OS. DT would be adjusted accordingly to "wire" these controls to cpus > or set of cpus. > In this scenario, the f/w will make aggregation decisions based on the > requests it receives on these M controls. > > Here we would have M cpufreq policies which do not necessarily reflect the > underlying clock domains, thus some s/w components will underperform > (EAS and thermal, for example). > > A real example would be a platform in which the firmware describes the system > having M per-cpu control, and the cpufreq subsystem will have M policies while > in fact these cpus are "performance-dependent" each other (e.g. are in the same > clock domain). If the CPUs are in the same clock domain, they must be part of the same cpufreq policy. > This performance dependency information is essential for some > components that take information from the cpufreq policy. > > To restore functionality we can use the optional node > 'cpu-performance-dependencies' in dt which will provide such dependency > information and we can add a new cpumask 'dependency_cpus' in policy. > > Hope it gives some clarity. Some, but I am still confused :( Can you give a real example, with exact number of CPUs, how they share clocks/voltage domains and what else the firmware needs in terms of performance-domains ? That may make it easier for me to understand it. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Nicola Mazzucato <nicola.mazzucato@arm.com> Cc: devicetree@vger.kernel.org, linux-pm@vger.kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sudeep.holla@arm.com, chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Date: Thu, 8 Oct 2020 16:32:41 +0530 [thread overview] Message-ID: <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> (raw) In-Reply-To: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> On 07-10-20, 13:58, Nicola Mazzucato wrote: > Hi Viresh, > > performance controls is what is exposed by the firmware through a protocol that > is not capable of describing hardware (say SCMI). For example, the firmware can > tell that the platform has N controls, but it can't say to which hardware they > are "wired" to. This is done in dt, where, for example, we map these controls > to cpus, gpus, etc. > > Let's focus on cpus. > > Normally we would have N of performance controls (what comes from f/w) > that that correspond to hardware clock/dvfs domains. > > However, some firmware implementations might benefit from having finer > grained information about the performance requirements (e.g. > per-CPU) and therefore choose to present M performance controls to the > OS. DT would be adjusted accordingly to "wire" these controls to cpus > or set of cpus. > In this scenario, the f/w will make aggregation decisions based on the > requests it receives on these M controls. > > Here we would have M cpufreq policies which do not necessarily reflect the > underlying clock domains, thus some s/w components will underperform > (EAS and thermal, for example). > > A real example would be a platform in which the firmware describes the system > having M per-cpu control, and the cpufreq subsystem will have M policies while > in fact these cpus are "performance-dependent" each other (e.g. are in the same > clock domain). If the CPUs are in the same clock domain, they must be part of the same cpufreq policy. > This performance dependency information is essential for some > components that take information from the cpufreq policy. > > To restore functionality we can use the optional node > 'cpu-performance-dependencies' in dt which will provide such dependency > information and we can add a new cpumask 'dependency_cpus' in policy. > > Hope it gives some clarity. Some, but I am still confused :( Can you give a real example, with exact number of CPUs, how they share clocks/voltage domains and what else the firmware needs in terms of performance-domains ? That may make it easier for me to understand it. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-08 11:02 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-24 9:53 [PATCH v2 0/2] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato 2020-09-24 9:53 ` Nicola Mazzucato 2020-09-24 9:53 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato 2020-09-24 9:53 ` Nicola Mazzucato 2020-10-08 13:42 ` Ionela Voinescu 2020-10-08 13:42 ` Ionela Voinescu 2020-09-24 9:53 ` [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato 2020-09-24 9:53 ` Nicola Mazzucato 2020-10-06 7:19 ` Viresh Kumar 2020-10-06 7:19 ` Viresh Kumar 2020-10-07 12:58 ` Nicola Mazzucato 2020-10-07 12:58 ` Nicola Mazzucato 2020-10-08 11:02 ` Viresh Kumar [this message] 2020-10-08 11:02 ` Viresh Kumar 2020-10-08 15:03 ` Ionela Voinescu 2020-10-08 15:03 ` Ionela Voinescu 2020-10-08 15:57 ` Rafael J. Wysocki 2020-10-08 15:57 ` Rafael J. Wysocki 2020-10-08 17:08 ` Ionela Voinescu 2020-10-08 17:08 ` Ionela Voinescu 2020-10-12 16:06 ` Sudeep Holla 2020-10-12 16:06 ` Sudeep Holla 2020-10-08 16:00 ` Nicola Mazzucato 2020-10-08 16:00 ` Nicola Mazzucato 2020-10-09 5:39 ` Viresh Kumar 2020-10-09 5:39 ` Viresh Kumar 2020-10-09 11:10 ` Nicola Mazzucato 2020-10-09 11:10 ` Nicola Mazzucato 2020-10-09 11:17 ` Viresh Kumar 2020-10-09 11:17 ` Viresh Kumar 2020-10-09 14:01 ` Rob Herring 2020-10-09 14:01 ` Rob Herring 2020-10-09 15:28 ` Nicola Mazzucato 2020-10-09 15:28 ` Nicola Mazzucato 2020-10-12 4:19 ` Viresh Kumar 2020-10-12 4:19 ` Viresh Kumar 2020-10-12 10:22 ` Lukasz Luba 2020-10-12 10:22 ` Lukasz Luba 2020-10-12 10:50 ` Rafael J. Wysocki 2020-10-12 10:50 ` Rafael J. Wysocki 2020-10-12 11:05 ` Lukasz Luba 2020-10-12 11:05 ` Lukasz Luba 2020-10-12 10:59 ` Ionela Voinescu 2020-10-12 10:59 ` Ionela Voinescu 2020-10-12 13:48 ` Lukasz Luba 2020-10-12 13:48 ` Lukasz Luba 2020-10-12 16:30 ` Ionela Voinescu 2020-10-12 16:30 ` Ionela Voinescu 2020-10-12 18:19 ` Lukasz Luba 2020-10-12 18:19 ` Lukasz Luba 2020-10-12 22:01 ` Ionela Voinescu 2020-10-12 22:01 ` Ionela Voinescu 2020-10-13 11:53 ` Rafael J. Wysocki 2020-10-13 11:53 ` Rafael J. Wysocki 2020-10-13 12:39 ` Ionela Voinescu 2020-10-13 12:39 ` Ionela Voinescu 2020-10-15 15:56 ` Rafael J. Wysocki 2020-10-15 15:56 ` Rafael J. Wysocki 2020-10-15 18:38 ` Ionela Voinescu 2020-10-15 18:38 ` Ionela Voinescu 2020-10-12 13:59 ` Rob Herring 2020-10-12 13:59 ` Rob Herring 2020-10-12 16:02 ` Sudeep Holla 2020-10-12 16:02 ` Sudeep Holla 2020-10-12 15:54 ` Sudeep Holla 2020-10-12 15:54 ` Sudeep Holla 2020-10-12 15:49 ` Sudeep Holla 2020-10-12 15:49 ` Sudeep Holla 2020-10-12 16:52 ` Ionela Voinescu 2020-10-12 16:52 ` Ionela Voinescu 2020-10-12 17:18 ` Lukasz Luba 2020-10-12 17:18 ` Lukasz Luba 2020-10-14 4:25 ` Viresh Kumar 2020-10-14 4:25 ` Viresh Kumar 2020-10-14 9:11 ` Lukasz Luba 2020-10-14 9:11 ` Lukasz Luba 2020-10-19 8:50 ` Nicola Mazzucato 2020-10-19 8:50 ` Nicola Mazzucato 2020-10-19 9:46 ` Viresh Kumar 2020-10-19 9:46 ` Viresh Kumar 2020-10-19 13:36 ` Nicola Mazzucato 2020-10-19 13:36 ` Nicola Mazzucato 2020-10-20 10:48 ` Viresh Kumar 2020-10-20 10:48 ` Viresh Kumar 2020-10-13 13:53 ` Lukasz Luba 2020-10-13 13:53 ` Lukasz Luba 2020-10-14 4:20 ` Viresh Kumar 2020-10-14 4:20 ` Viresh Kumar
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=20201008110241.dcyxdtqqj7slwmnc@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=chris.redpath@arm.com \ --cc=daniel.lezcano@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=morten.rasmussen@arm.com \ --cc=nicola.mazzucato@arm.com \ --cc=rjw@rjwysocki.net \ --cc=robh+dt@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=vireshk@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.