| Message ID | 20220627123038.1427067-6-cristian.marussi@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | SCMIv3.1 Powercap protocol and driver | expand |
On Mon, Jun 27, 2022 at 01:30:34PM +0100, Cristian Marussi wrote: > Add a Kernel configuration entry used to optionally disable, globally, the > usage of SCMI FastChannels even on platforms where they are available. > > Make such option default-no to preserve the original SCMI system behaviour > of using any available FC. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > v2 --> v3 > - fixed wording in Kconfig > - reverted Kconfig logic _USE_ -> _AVOID_ > --- > drivers/firmware/arm_scmi/Kconfig | 13 +++++++++++++ > drivers/firmware/arm_scmi/driver.c | 6 ++++++ > 2 files changed, 19 insertions(+) > > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig > index 1e7b7fec97d9..3fb34db01014 100644 > --- a/drivers/firmware/arm_scmi/Kconfig > +++ b/drivers/firmware/arm_scmi/Kconfig > @@ -42,6 +42,19 @@ config ARM_SCMI_HAVE_MSG > This declares whether a message passing based transport for SCMI is > available. > > +config ARM_SCMI_AVOID_FASTCHANNELS > + bool "Avoid using SCMI FastChannels even when available" Without default, won't this prompt user now ? I would have explicit default n if we are adding this. But why do we need this is my question ? This would be a quirk IMO on systems where FC is broken. I don't want people to enable this during testing and ship f/w with FC broken(or not developed yet). We can add this if some platforms really need this as a quirk in the future. Thoughts ?
On Fri, Jul 01, 2022 at 03:03:07PM +0100, Sudeep Holla wrote: > On Mon, Jun 27, 2022 at 01:30:34PM +0100, Cristian Marussi wrote: > > Add a Kernel configuration entry used to optionally disable, globally, the > > usage of SCMI FastChannels even on platforms where they are available. > > > > Make such option default-no to preserve the original SCMI system behaviour > > of using any available FC. > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > --- > > v2 --> v3 > > - fixed wording in Kconfig > > - reverted Kconfig logic _USE_ -> _AVOID_ > > --- > > drivers/firmware/arm_scmi/Kconfig | 13 +++++++++++++ > > drivers/firmware/arm_scmi/driver.c | 6 ++++++ > > 2 files changed, 19 insertions(+) > > > > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig > > index 1e7b7fec97d9..3fb34db01014 100644 > > --- a/drivers/firmware/arm_scmi/Kconfig > > +++ b/drivers/firmware/arm_scmi/Kconfig > > @@ -42,6 +42,19 @@ config ARM_SCMI_HAVE_MSG > > This declares whether a message passing based transport for SCMI is > > available. > > > > +config ARM_SCMI_AVOID_FASTCHANNELS > > + bool "Avoid using SCMI FastChannels even when available" > > Without default, won't this prompt user now ? I would have explicit default n > if we are adding this. But why do we need this is my question ? This would > be a quirk IMO on systems where FC is broken. I don't want people to enable > this during testing and ship f/w with FC broken(or not developed yet). > > We can add this if some platforms really need this as a quirk in the future. > Ah ok an explicit default no is better indeed to avoid prompting if you do not defconfig (I missed this difference between default implicit NO and explicit NO) ... ... regarding why, I am using personally this indeed for testing with or without FCs without having to change the installed FW blob, BUT the reason for upstreaming such an option is that FC support is indeed optional by the spec so I thought it would have been acceptabel that you could want to configure a platform NOT to use them even though the FW implementation you are using, maybe across multiple platforms, supports it. Thanks, Cristian
On Fri, Jul 01, 2022 at 03:47:20PM +0100, Cristian Marussi wrote: [...] > ... regarding why, I am using personally this indeed for testing with or > without FCs without having to change the installed FW blob, BUT the reason > for upstreaming such an option is that FC support is indeed optional by the > spec so I thought it would have been acceptabel that you could want to > configure a platform NOT to use them even though the FW implementation you > are using, maybe across multiple platforms, supports it. Yes it is optional. But we use only if F/W advertises that it is available, so no harm if it is not implemented right ? I don't believe it will save space in the way config is used and I don't want to push all the code under the config too.
On Fri, Jul 01, 2022 at 03:55:08PM +0100, Sudeep Holla wrote: > On Fri, Jul 01, 2022 at 03:47:20PM +0100, Cristian Marussi wrote: > > [...] > > > ... regarding why, I am using personally this indeed for testing with or > > without FCs without having to change the installed FW blob, BUT the reason > > for upstreaming such an option is that FC support is indeed optional by the > > spec so I thought it would have been acceptabel that you could want to > > configure a platform NOT to use them even though the FW implementation you > > are using, maybe across multiple platforms, supports it. > > Yes it is optional. But we use only if F/W advertises that it is available, > so no harm if it is not implemented right ? I don't believe it will save > space in the way config is used and I don't want to push all the code > under the config too. What I meant was to be able to use the same FW blob_X with valid and advertised FCs support on multiple platforms, but having the possibility to configure some of these not to use it even if advertised as available. Indeed there is no space saving at all that was ot the idea. Thanks Cristian
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig index 1e7b7fec97d9..3fb34db01014 100644 --- a/drivers/firmware/arm_scmi/Kconfig +++ b/drivers/firmware/arm_scmi/Kconfig @@ -42,6 +42,19 @@ config ARM_SCMI_HAVE_MSG This declares whether a message passing based transport for SCMI is available. +config ARM_SCMI_AVOID_FASTCHANNELS + bool "Avoid using SCMI FastChannels even when available" + help + Avoid using SCMI FastChannels even if advertised as available by + the platform. + + On systems where the SCMI platform advertises the availability of + FastChannels, supported SCMI commands can be issued triggering a + one-way FastChannel request, much more quickly than using a + regular SCMI message transfer. + When set to Y forces the OSPM to use instead regular SCMI message + transfers even if FastChannels are available. If unsure say N. + config ARM_SCMI_TRANSPORT_MAILBOX bool "SCMI transport based on Mailbox" depends on MAILBOX diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 00b7f2aff4ec..76dc82ba04b3 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -1298,6 +1298,12 @@ scmi_common_fastchannel_init(const struct scmi_protocol_handle *ph, struct scmi_msg_resp_desc_fc *resp; const struct scmi_protocol_instance *pi = ph_to_pi(ph); + if (IS_ENABLED(CONFIG_ARM_SCMI_AVOID_FASTCHANNELS)) { + dev_warn_once(ph->dev, + "FastChannels usage disabled in Kconfig.\n"); + return; + } + if (!p_addr) { ret = -EINVAL; goto err_out;
Add a Kernel configuration entry used to optionally disable, globally, the usage of SCMI FastChannels even on platforms where they are available. Make such option default-no to preserve the original SCMI system behaviour of using any available FC. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> --- v2 --> v3 - fixed wording in Kconfig - reverted Kconfig logic _USE_ -> _AVOID_ --- drivers/firmware/arm_scmi/Kconfig | 13 +++++++++++++ drivers/firmware/arm_scmi/driver.c | 6 ++++++ 2 files changed, 19 insertions(+)