From: Viresh Kumar <firstname.lastname@example.org> To: Nicola Mazzucato <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.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: <email@example.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 firstname.lastname@example.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-08 11:04 UTC|newest] Thread overview: 44+ 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 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato 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-10-06 7:19 ` Viresh Kumar 2020-10-07 12:58 ` Nicola Mazzucato 2020-10-08 11:02 ` Viresh Kumar [this message] 2020-10-08 15:03 ` Ionela Voinescu 2020-10-08 15:57 ` Rafael J. Wysocki 2020-10-08 17:08 ` Ionela Voinescu 2020-10-12 16:06 ` Sudeep Holla 2020-10-08 16:00 ` Nicola Mazzucato 2020-10-09 5:39 ` Viresh Kumar 2020-10-09 11:10 ` Nicola Mazzucato 2020-10-09 11:17 ` Viresh Kumar 2020-10-09 14:01 ` Rob Herring 2020-10-09 15:28 ` Nicola Mazzucato 2020-10-12 4:19 ` Viresh Kumar 2020-10-12 10:22 ` Lukasz Luba 2020-10-12 10:50 ` Rafael J. Wysocki 2020-10-12 11:05 ` Lukasz Luba 2020-10-12 10:59 ` Ionela Voinescu 2020-10-12 13:48 ` Lukasz Luba 2020-10-12 16:30 ` Ionela Voinescu 2020-10-12 18:19 ` Lukasz Luba 2020-10-12 22:01 ` Ionela Voinescu 2020-10-13 11:53 ` Rafael J. Wysocki 2020-10-13 12:39 ` Ionela Voinescu 2020-10-15 15:56 ` Rafael J. Wysocki 2020-10-15 18:38 ` Ionela Voinescu 2020-10-12 13:59 ` Rob Herring 2020-10-12 16:02 ` Sudeep Holla 2020-10-12 15:54 ` Sudeep Holla 2020-10-12 15:49 ` Sudeep Holla 2020-10-12 16:52 ` Ionela Voinescu 2020-10-12 17:18 ` Lukasz Luba 2020-10-14 4:25 ` Viresh Kumar 2020-10-14 9:11 ` Lukasz Luba 2020-10-19 8:50 ` Nicola Mazzucato 2020-10-19 9:46 ` Viresh Kumar 2020-10-19 13:36 ` Nicola Mazzucato 2020-10-20 10:48 ` Viresh Kumar 2020-10-13 13:53 ` Lukasz Luba 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies' \ /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: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).