public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Cristian Marussi <cristian.marussi@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, james.quinlan@broadcom.com,
	Jonathan.Cameron@Huawei.com, etienne.carriere@linaro.org,
	vincent.guittot@linaro.org, souvik.chakravarty@arm.com,
	wleavitt@marvell.com, peter.hilber@opensynergy.com,
	nicola.mazzucato@arm.com, tarek.el-sherbiny@arm.com,
	quic_kshivnan@quicinc.com
Subject: Re: [PATCH v4 0/11] Introduce a unified API for SCMI Server testing
Date: Fri, 28 Oct 2022 19:38:25 -0700	[thread overview]
Message-ID: <fc09a68c-bd6d-0328-4052-88d40b50077d@gmail.com> (raw)
In-Reply-To: <20221019204626.3813043-1-cristian.marussi@arm.com>

Hi Christian,

On 10/19/2022 1:46 PM, Cristian Marussi wrote:
[snip]

> In V2 the runtime enable/disable switching capability has been removed
> (for now) since still not deemed to be stable/reliable enough: as a
> consequence when SCMI Raw support is compiled in, the regular SCMI stack
> drivers are now inhibited permanently for that Kernel.

For our platforms (ARCH_BRCMSTB) we would need to have the ability to 
start with the regular SCMI stack to satisfy if nothing else, all clock 
consumers otherwise it makes it fairly challenging for us to boot to a 
prompt as we purposely turn off all unnecessary peripherals to conserve 
power. We could introduce a "full on" mode to remove the clock provider 
dependency, but I suspect others on "real" silicon may suffer from the 
same short comings.

Once user-space is reached, I suppose we could find a way to unbind from 
all SCMI consumers, and/or ensure that runtime PM is disabled, cpufreq 
is in a governor that won't do any active frequency switching etc.

What do you think?
-- 
Florian

  parent reply	other threads:[~2022-10-29  2:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 20:46 [PATCH v4 0/11] Introduce a unified API for SCMI Server testing Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 01/11] firmware: arm_scmi: Refactor xfer in-flight registration routines Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 02/11] firmware: arm_scmi: Simplify chan_available transport operation Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 03/11] firmware: arm_scmi: Use dedicated devices to initialize channels Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 04/11] firmware: arm_scmi: Refactor polling helpers Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 05/11] firmware: arm_scmi: Refactor scmi_wait_for_message_response Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 06/11] firmware: arm_scmi: Add xfer raw helpers Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 07/11] firmware: arm_scmi: Move errors defs and code to common.h Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 08/11] firmware: arm_scmi: Add raw transmission support Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 09/11] firmware: arm_scmi: Add debugfs ABI documentation for Raw mode Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 10/11] firmware: arm_scmi: Reject SCMI drivers while in " Cristian Marussi
2022-10-19 20:46 ` [PATCH v4 11/11] firmware: arm_scmi: Call Raw mode hooks from the core stack Cristian Marussi
2022-10-28 14:40 ` [PATCH v4 0/11] Introduce a unified API for SCMI Server testing Vincent Guittot
2022-10-28 15:03   ` Cristian Marussi
2022-10-28 16:18     ` Vincent Guittot
2022-10-28 16:58       ` Cristian Marussi
2022-11-02  8:54         ` Vincent Guittot
2022-11-03  9:21           ` Cristian Marussi
2022-11-03 10:58             ` Vincent Guittot
2022-10-28 14:44 ` Florian Fainelli
2022-10-28 15:23   ` Cristian Marussi
2022-10-29  2:38 ` Florian Fainelli [this message]
2022-10-29 11:14   ` Cristian Marussi
2022-11-03 11:21   ` Sudeep Holla
2022-11-03 12:06     ` Cristian Marussi

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=fc09a68c-bd6d-0328-4052-88d40b50077d@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=cristian.marussi@arm.com \
    --cc=etienne.carriere@linaro.org \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicola.mazzucato@arm.com \
    --cc=peter.hilber@opensynergy.com \
    --cc=quic_kshivnan@quicinc.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tarek.el-sherbiny@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=wleavitt@marvell.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox