From: Nicola Mazzucato <nicola.mazzucato@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, cristian.marussi@arm.com Cc: morten.rasmussen@arm.com, chris.redpath@arm.com, ionela.voinescu@arm.com, nicola.mazzucato@arm.com Subject: [PATCH v7 0/3] CPUFreq: Add support for opp-sharing cpus Date: Mon, 15 Feb 2021 07:51:36 +0000 [thread overview] Message-ID: <20210215075139.30772-1-nicola.mazzucato@arm.com> (raw) Hi Viresh, In this V7 posting I have reworked the CPUFreq scmi driver in a different way as suggested in v6. Essentially I believe it is more efficient to keep the support for opp-shared in the _init() stage, rather than moving everything to _probe(), storing whatever is required and reuse it only once in _init(). The reasons for this are: - scmi-cpufreq has no init cases that would require a deferred probe. - therefore, moving the all the cpus initialisation to probe, whilst possible, will result in a waste of memory, since we need to store cpumask and freq_table only for them to be reused just once later on at init. - it does not appear to be functional justification for moving the init code to probe, which results in unnecessary overhead for both coding and review. - this change is much smaller and only one patch required (1 file changed, 52 insertions, 20 deletions) compared to a version where we first move init code to _probe and later add support for opp-v2 (2 patches, 1 file changed, 194+34 insertions, 44+9 deletions, version with a linked list). - this v7 implementation is much easier to maintain. Many thanks, Nicola [v7] * Bring back common stuff for CPUs from _init stage to _probe * Remove patch "scmi-cpufreq: Move CPU initialisation to probe" This v7 is based on Linux 5.11-rc6 [v6] * Remove deferred probe, not occurring * Move common stuff for CPUs from _init stage to _probe This V6 is rebased on next-20210111 [v5] * Rework documentation of opp-shared within OPP node * Register EM only for the first CPU within cpumask in driver * Add check for nr_opp in driver before registering EM * Add comments on both dev_pm_opp_get_opp_count in driver * Remove redundant ret=0 in driver This v5 is rebased on top of: next-20201208 + Lukasz Luba's patches [1] [v4] * Remove unconditional set of opp_table->shared_opp to exclusive * Add implementation for scmi-cpufreq * Change subject These patches are on top of: next-20201201 + Lukasz Luba's patches (waiting for Rafael) [1] [v3] * Remove proposal for new 'cpu-performance-dependencies' as we instead can reuse the opp table. * Update documentation for devicetree/bindings/opp * Minor changes within opp to support empty opp table * Rework the RFC by adding a second proposal [v2] * Fix errors when running make dt_binding_check * Improve commit message description for the dt-binding * Add RFC for implementation in cpufreq-core and one of its drivers. Nicola Mazzucato (2): scmi-cpufreq: Remove deferred probe scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM Sudeep Holla (1): cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev drivers/cpufreq/cpufreq-dt-platdev.c | 2 + drivers/cpufreq/scmi-cpufreq.c | 70 +++++++++++++++++++++------- 2 files changed, 54 insertions(+), 18 deletions(-) -- 2.27.0
WARNING: multiple messages have this Message-ID (diff)
From: Nicola Mazzucato <nicola.mazzucato@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, cristian.marussi@arm.com Cc: chris.redpath@arm.com, ionela.voinescu@arm.com, morten.rasmussen@arm.com, nicola.mazzucato@arm.com Subject: [PATCH v7 0/3] CPUFreq: Add support for opp-sharing cpus Date: Mon, 15 Feb 2021 07:51:36 +0000 [thread overview] Message-ID: <20210215075139.30772-1-nicola.mazzucato@arm.com> (raw) Hi Viresh, In this V7 posting I have reworked the CPUFreq scmi driver in a different way as suggested in v6. Essentially I believe it is more efficient to keep the support for opp-shared in the _init() stage, rather than moving everything to _probe(), storing whatever is required and reuse it only once in _init(). The reasons for this are: - scmi-cpufreq has no init cases that would require a deferred probe. - therefore, moving the all the cpus initialisation to probe, whilst possible, will result in a waste of memory, since we need to store cpumask and freq_table only for them to be reused just once later on at init. - it does not appear to be functional justification for moving the init code to probe, which results in unnecessary overhead for both coding and review. - this change is much smaller and only one patch required (1 file changed, 52 insertions, 20 deletions) compared to a version where we first move init code to _probe and later add support for opp-v2 (2 patches, 1 file changed, 194+34 insertions, 44+9 deletions, version with a linked list). - this v7 implementation is much easier to maintain. Many thanks, Nicola [v7] * Bring back common stuff for CPUs from _init stage to _probe * Remove patch "scmi-cpufreq: Move CPU initialisation to probe" This v7 is based on Linux 5.11-rc6 [v6] * Remove deferred probe, not occurring * Move common stuff for CPUs from _init stage to _probe This V6 is rebased on next-20210111 [v5] * Rework documentation of opp-shared within OPP node * Register EM only for the first CPU within cpumask in driver * Add check for nr_opp in driver before registering EM * Add comments on both dev_pm_opp_get_opp_count in driver * Remove redundant ret=0 in driver This v5 is rebased on top of: next-20201208 + Lukasz Luba's patches [1] [v4] * Remove unconditional set of opp_table->shared_opp to exclusive * Add implementation for scmi-cpufreq * Change subject These patches are on top of: next-20201201 + Lukasz Luba's patches (waiting for Rafael) [1] [v3] * Remove proposal for new 'cpu-performance-dependencies' as we instead can reuse the opp table. * Update documentation for devicetree/bindings/opp * Minor changes within opp to support empty opp table * Rework the RFC by adding a second proposal [v2] * Fix errors when running make dt_binding_check * Improve commit message description for the dt-binding * Add RFC for implementation in cpufreq-core and one of its drivers. Nicola Mazzucato (2): scmi-cpufreq: Remove deferred probe scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM Sudeep Holla (1): cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev drivers/cpufreq/cpufreq-dt-platdev.c | 2 + drivers/cpufreq/scmi-cpufreq.c | 70 +++++++++++++++++++++------- 2 files changed, 54 insertions(+), 18 deletions(-) -- 2.27.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2021-02-15 7:50 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-15 7:51 Nicola Mazzucato [this message] 2021-02-15 7:51 ` [PATCH v7 0/3] CPUFreq: Add support for opp-sharing cpus Nicola Mazzucato 2021-02-15 7:51 ` [PATCH v7 1/3] scmi-cpufreq: Remove deferred probe Nicola Mazzucato 2021-02-15 7:51 ` Nicola Mazzucato 2021-02-18 10:35 ` Viresh Kumar 2021-02-18 10:35 ` Viresh Kumar 2021-02-18 13:01 ` Nicola Mazzucato 2021-02-18 13:01 ` Nicola Mazzucato 2021-02-15 7:51 ` [PATCH v7 2/3] scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM Nicola Mazzucato 2021-02-15 7:51 ` Nicola Mazzucato 2021-02-18 11:00 ` Viresh Kumar 2021-02-18 11:00 ` Viresh Kumar 2021-02-18 13:02 ` Nicola Mazzucato 2021-02-18 13:02 ` Nicola Mazzucato 2021-02-15 7:51 ` [PATCH v7 3/3] cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev Nicola Mazzucato 2021-02-15 7:51 ` Nicola Mazzucato
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=20210215075139.30772-1-nicola.mazzucato@arm.com \ --to=nicola.mazzucato@arm.com \ --cc=chris.redpath@arm.com \ --cc=cristian.marussi@arm.com \ --cc=ionela.voinescu@arm.com \ --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=rjw@rjwysocki.net \ --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.