From: Sudeep Holla <sudeep.holla@arm.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: "cristian.marussi@arm.com" <cristian.marussi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"robh@kernel.org" <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: scmi mailbox max_rx_timeout_ms value
Date: Tue, 18 Jun 2024 11:07:16 +0100 [thread overview]
Message-ID: <20240618100716.wlgf4wc6afzjlutu@bogus> (raw)
In-Reply-To: <AM6PR04MB594170DF514A3B168E35FBA688CE2@AM6PR04MB5941.eurprd04.prod.outlook.com>
On Tue, Jun 18, 2024 at 02:12:06AM +0000, Peng Fan wrote:
> > Subject: Re: scmi mailbox max_rx_timeout_ms value
> >
> > On Mon, Jun 17, 2024 at 09:17:11AM +0000, Peng Fan wrote:
> > > Hi Sudeep, Cristian and DT maintainers
> > >
> > > In drivers/firmware/arm_scmi/mailbox.c, current
> > max_rx_timeout_ms is
> > > 30ms, we wanna to enlarge the value.
> >
> > Care to provide the reason for the same ? Few possible bottle-
> > neck/issues:
> > 1. Transport
> > 2. Firmware implementation
> > 3. Processing capability of co-processor implementing SCMI
>
> We have M7 and A55 and even more SCMI agents in future,
> A55 linux agent has the lowest priority.
>
> In normal case, we not see issue using 30ms, but in extreme
> corner case, A55 linux may not get response in long time
> if other higher priority agents have heavy SCMI requests.
>
> >
> > > NXP downstream value is set to 1000ms, but for upstream I think it
> > may
> > > not be a good solution that just enlarge it for all scmi users,
> >
> > I think it may not be good solution on any modern platform to have
> > such high latency for P2A or A2P communication. Even Juno(a decade
> > old platform copes well with 30ms with SCP running at 50MHz(IIRC). So
> > I am interesting in getting more info about i.MX before we can decide
> > on the right path to progress here.
> >
> > > Each platform may have its own max timeout value depends on scmi
> > > firmware design.
> >
> > Fair enough, but 30ms to 1000ms just seems wrong to me to start with.
> > I simple need more information to get convinced here.
>
> It is just based on i.MX8QM/QXP SCU experience. We thought 30ms
> might be not enough, so chose a large value 1s here.
Well why 1s ? Why not 100ms or 50ms or 200ms ? 30ms was initially set
as mailbox initially didn't use HR timers and we wanted to set at least
2-3 jiffies on a 100 HZ system. It can be and must be lower than that but
left it there as worst case value.
So can you elaborate as how slow A55 and M7 can run and why 1s is good
and right choice ? Coz we may have to see if perf fast switch needs to be
disabled if fast channels are not supported ? It may have other implications.
It can't be just any random number like 1s as some developer felt like
testing to overcome the issues seen on this platform.
--
Regards,
Sudeep
next prev parent reply other threads:[~2024-06-18 10:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 9:17 scmi mailbox max_rx_timeout_ms value Peng Fan
2024-06-17 13:28 ` Sudeep Holla
2024-06-18 2:12 ` Peng Fan
2024-06-18 10:07 ` Sudeep Holla [this message]
2024-06-18 13:01 ` Peng Fan
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=20240618100716.wlgf4wc6afzjlutu@bogus \
--to=sudeep.holla@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=peng.fan@nxp.com \
--cc=robh@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: 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