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