Re: scmi mailbox max_rx_timeout_ms value

[Sudeep Holla <sudeep.holla@arm.com>]

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

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

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