scmi mailbox max_rx_timeout_ms value

[Peng Fan]

> 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.

> 
> > So I am thinking to use a device tree property for this, saying
> > "mbox-rx-timeout-us", just as "atomic-threshold-us" in arm,scmi.yaml
> >
> 
> May be, I am not completely against it as we need this if some
> platforms need say 50ms instead of 30ms. Typically any sync
> command needs to be processed with few 100s of uS not even as high
> as a mS. 

Right. 
But as I said, our A55 linux agent has the lowest priority. If other
agents continuous issue SCMI request, A55 linux SCMI message has
less chance to be processed. This might be extreme corner case.
But we just wanna to avoid potential issue.

I will post out binding and driver changes if per platform timeout
is ok for you.

Thanks,
Peng.

So as I said before 1000mS needs lot of convincing. I am not
> even sure of 1s is tolerable latency in general for some of the SCMI perf
> commands.
> 
> --
> Regards,
> Sudeep