Messages in this thread | | | Date | Thu, 11 Jun 2020 09:40:14 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH] firmware: arm_scmi: fix timeout value for send_message |
| |
On Wed, Jun 10, 2020 at 09:45:55PM -0500, Jassi Brar wrote: > On Wed, Jun 10, 2020 at 10:56 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > [I admit you can write bigger posts than me, so I am not going to > write a passionate response to each of your paragraphs. > Let's keep it to the point.] > > > > > > 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. I am not saying we want that on Juno/MHU.
> 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.
-- Regards, Sudeep
| |