scmi mailbox max_rx_timeout_ms value

[Sudeep Holla]

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