scmi mailbox max_rx_timeout_ms value

scmi mailbox max_rx_timeout_ms value

[Peng Fan]

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. 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, each platform may have its own
max timeout value depends on scmi firmware design. 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

How do you think?

Thanks,
Peng.

Re: scmi mailbox max_rx_timeout_ms value

[Sudeep Holla]

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

RE: 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

Re: 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

RE: 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