scmi mailbox max_rx_timeout_ms value

[Peng Fan]

Hi Sudeep,

> Subject: Re: scmi mailbox max_rx_timeout_ms value
> 
> 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

For A55 agent, it is 500 MHz
For M7 agent, it is 400M or 24M
For M33 SCMI platform,  it is 166M, normally runs at 333M.

and why 1s is
> good and right choice ?

Our firmware designers suggest agents wait for until response,
and no timeout, because if real timeout happens, linux scmi
will not recover per firmware design. And if M7 agent
has higher priority, and M7 is asking doing some time
consuming stuff, linux agent has high chance to timeout.

I could not say why 1s is good or right, actually there is no real
answer to this.  just from our current test, it is a value that
makes system work well.

But our customer could customize the firmware for any
stuff they need, so the max timeout value varies.

 Coz we may have to see if perf fast switch
> needs to be disabled if fast channels are not supported ? 

We not use fast channels per my understanding.

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.

Ah.

Saying
M7 is doing SCMI request
ATF secure world is doing SCMI request 
TEE is doing SCMI request

The linux SCMI request could only be serviced after the above done,
if above agents have higher priority. It is hard to define
an exact maximum timeout value.


Putting the 1s aside, could I post out the patches for each platform
use its own timeout value first?

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep