Messages in this thread | | | From | Jassi Brar <> | Date | Thu, 11 Jun 2020 10:19:12 -0500 | Subject | Re: [PATCH] firmware: arm_scmi: fix timeout value for send_message |
| |
On Thu, Jun 11, 2020 at 3:40 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > > > > > > if (xfer->hdr.poll_completion) { > > > > > > - ktime_t stop = ktime_add_ns(ktime_get(), SCMI_MAX_POLL_TO_NS); > > > > > > + ktime_t stop = ktime_add_ns(ktime_get(), 500 * 1000 * NSEC_PER_USEC); > > > > > > > > > > > > > > > > This is unacceptable delay for schedutil fast_switch. So no for this one. > > > > > > > > > Increasing timeout does not increase latency. > > > > > > Agreed, but worst case you may be stuck here for 500ms which is not > > > acceptable. > > > > > Not acceptable to who, you or the kernel? :) Now that you said you > > are fixing the scmi's fast_switch implementation. > > > Sorry, I meant to disable it for single channel implementation. > The single-channel platform may have only cpufreq as the user, or only users that respond quickly ~3us. So maybe we leave the decision, to enable fast_switch, totally to the platform. But of course, this discussion is for another thread.
> > Even though I don't think 500ms would ruin our lives, but ok, I will > > make it 30ms - same as you did in the 'else' block. And drop the other > > change. > > I am fine if cpufreq maintainers allow that in the fast switch path that > happens in the fast path. > Thanks, let me respin the patch and include some cpufreq folks.
Cheers!
| |